Well not anymore… I spent a little time to add new labels, and move stuff around. Who did not find an umbrella, was sent to archive. Now everything is fast. After doing that I realised that what was probably making my gmail interface slow were the “Multiple inboxes” on top. (You may activate them under settings). When opening the inbox, the “Multiple inboxes” boxes are doing a search based on the criteria in the definition. Anyway, they are still searching in the archive, but now my mailbox is responsive like before…

trying to copy with dd from /dev/urandom to the flash card it takes 4 seconds, if there is no framebuffer activity. If just doing some resizes during the copy, the times are in range of 15 to 30 seconds.

It is slow, but I found out the reason… However in order to avoid this slowness, I will must not use an important feature of the operating system.

Since the upgrade to 9.04, I noticed that the hard disk led was blinking long minutes. Updating software took long minutes, however downloading was quit fast. Tried to investigate with atop, tried to kill processes that appeared to access the hard disk etc. No real improvement. Often the system seemed to be freezing…

But after investigating few hours, the unexpected result came out. It was difficult to find the cause because the bad was not always happening. And finally I remarked that the difference was between rebooting and restarting from suspend! And the hdparm test hast confirmed it:

sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads:   1978 MB in  2.00 seconds = 988.92 MB/sec
Timing buffered disk reads:  162 MB in  3.08 seconds =  52.64 MB/sec
misi@kaktusz:~$ sudo hdparm -tT /dev/sda

/dev/sda:
Timing cached reads:   1072 MB in  2.00 seconds = 536.09 MB/sec
Timing buffered disk reads:    4 MB in  5.50 seconds = 744.96 kB/sec

The funny thing is that the rest of the hard disks were behaving normally after suspend, so only the root filesystems hard disk was the evil…

So… is this a bug in kernel (2.6.28-11-generic)?

Anyway, for me the solution is to avoid suspend, shut down, and boot when needed, but wait 50000 seconds for boot

After months of fight and frustration with nfs4 on Ubuntu, I switched to nfs3. And finally I can see the  light at the end of the tunnel! As I was describing here, I made some measurement about copy speed of small files towards nfs server and back. Copying to the server was almost 10 times slower with nfs4 than copying from the server (same harddisk type both on server and client).

Now with nfs3 the speeds are the same in both directions!!!

I am using vim to edit/view large files (> 600MB). Unfortunately, it looks like opening such large files even on a Pentium 3.4Ghz with PATA disk takes quite some time (17sec)(ubuntu, kernel 2.6.22-14). I know that vim
creates some internal tree representation of the file, but I wonder if something could be tuned, so that such loading times decrease, even if memory usage would increase.

I tried to open a 767.187.800 bytes file (I created this file by cat-ing all vim src files 100 times ) :

time vim -u ./.vimrc –noplugin -c”:q” ../all3.c

the result is:

real 0m17.670s

user 0m15.457s

sys 0m1.428s

the .vimrc contains only

set noswapfile

I profiled vim, and opening the same file I got the results below….

So the question would be, is it possible to tune sthg. to open faster
these files??

here is the gprof head

XXXXX$ head -40 no_swap

Flat profile:

Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
46.12 1.96 1.96 1 1.96 4.22 readfile
23.53 2.96 1.00 31025600 0.00 0.00 ml_append_int
12.94 3.51 0.55 31025601 0.00 0.00 ml_updatechunk
8.24 3.86 0.35 31361959 0.00 0.00 ml_find_line
4.94 4.07 0.21 31025600 0.00 0.00 ml_append
0.47 4.09 0.02 1876672 0.00 0.00 mf_put
0.47 4.11 0.02 1655954 0.00 0.00 mf_find_hash
0.47 4.13 0.02 1655954 0.00 0.00 mf_get

opening the same file with grep or with the script below takes on the same machine around 0.25 seconds

#include <unistd.h>
#include <fcntl.h>
int main(int argc, char ** argv)
{
if(argc < 1) {
printf(”file name not provided..\n”);
return -1;
}
int fd = open(argv[1], O_RDONLY);
if(fd < 0) {
printf(”cannot open file %s”, argv[1]);
return -1;
}
int chunk_size = 1000;
if(argc > 2) {
chunk_size = atoi(argv[2]);
}
char *buffer = (char * )malloc(chunk_size);
int res, count = 0;
while( (res = read(fd, buffer, chunk_size) ) > 0) {
count ++;
}
printf(”total read %d*%d=%d”, count, chunk_size, count*chunk_size);
}

By having more and more devices around at home, it makes sense to keep all data in one place. I have a server for longer time, that runs a samba server, nfs file server and is acting as host for VirtualBox and Xen virtual machines. I had finally time to complete another phase of this “move everything to server”, by using a central home directory for all the clients.

The experiment was so far not completely successful as the writing speed towards the server is horribly low. I made the following experiments

1. Measured the ip speed with iperf in both directions between the client and server.

on the server:

xxx@yyyyyyyyy:~$ iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————
[ 4] local 192.168.12.5 port 5001 connected with 192.168.12.11 port 56444
[ 4] 0.0-10.0 sec 753 MBytes 630 Mbits/sec

on the client

uuuuu@qqq:~$ iperf -c 192.168.12.5
————————————————————
Client connecting to 192.168.12.5, TCP port 5001
TCP window size: 16.0 KByte (default)
————————————————————
[ 3] local 192.168.12.11 port 56444 connected with 192.168.12.5 port 5001
[ 3] 0.0-10.0 sec 753 MBytes 631 Mbits/sec

so the transfer rate is quite good (630Mbits/sec) for a Gbit card on both side as the server has a slower PCI.

2. Copied a 100MByte file from the server to the client, it took 1.6 sec

3. copied a the same 100MByte file from the client and it took 60sec!!! so 10 times slower!!! Cannot beleive….

Here is the line from /etc/fstab for the /home folder

192.168.12.5:/XXXXXX/home /home nfs4 auto,rw,nodev,sync,_netdev,noatime,proto=tcp,retry=10,rsize=32768,wsize=32768,hard,intr 0

4. By changing the sync parameter to async there was some significant improvement, but still far from perfect… copying from the server remained 1.6 sec, and copy to the server dropped to 3.6 sec. The same copy on the server, locally takes 1.7 sec.

This means that copying through nfs is twice slower than a local copy without having network bottleneck.

4. Copying 1000 files of 100kbyte from server to client took ~3sec, but back to the server 45secs!!!!! This is really painful. This made it clear, why programs like firefox slowed down since the nfs home. Firefox writes several small files quite often, so …

5. And now some comparison about (half) alternatives. Copying with scp the same 1000 files to the server took 12secs, so almost a quarter of the time spent with nfs.

Important to mention that there is no router between the computers, they are connected with a cat6 cable (gigabit ethernet).

Any suggestion if this copy time could be decreased?