On Mon, 15 Mar 1999 jaharkes_at_cs.cmu.edu wrote:

> 
> Many months ago (9/16/1998), Troy Benjegerdes said:
> 
> | Untarring linux-2.1.121 on nfs:
> | 4.18user 3.97system 1:14.74elapsed 10%CPU (0avgtext+0avgdata 0maxresident)k
> | 0inputs+0outputs (3163major+9197minor)pagefaults 0swaps
> |
> | Untarring linux-2.1.121 on coda:
> | 4.44user 2.84system 1:00:55elapsed 0%CPU (0avgtext+0avgdata
> | 0maxresident)k 0inputs+0outputs (206major+9197minor)pagefaults 0swaps
> 
> And just now I tried:
> 
> Untarring linux-2.1.122 on coda:
> 4.71user 3.07system 28:16.12elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (3185major+9204minor)pagefaults 0swaps
> 
> I guess the difference is probably related to the fact that my machine 
> has a PII-400 processor, and a 100B-T ethernet connection to the server. 
>

heh, if I remember right, that benchmark was on a PII-450 connected via
fast-ether to another PII-450. I have another time which shows much
improvement (using the latest coda release)

This was with linux-2.2, to a volume replicated on two servers.

25.87user 4.75system 8:01.96elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (726major+10674minor)pagefaults 0swaps 
 
> We have not been concentrating on improving the speed, but mostly on
> improving the overall stability of the system. First of all, there are
> still about 3 RPC's for each created file, and when the write disconnected
> operations, or it's extension writeback caching, get really stable there
> will be only 
> 1 RPC for about 100 file creations.

Write disconnected operation is definitely faster, but still has bugs in
it.. I've ended up reinitializeing servers twice because of it. ;)

> Now that will ofcourse not give a 300 fold speed increase, because we
> are not just blocking on the RPC calls, but it should become a bit faster 
> for the client-server traffic and a lot faster for what the user observes.
> 
> i.e. here are some actual measurements in write-disconnected mode:
> 
> Untarring linux-2.1.122 on coda:
> 4.83user 3.35system 2:36.85elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (3200major+9204minor)pagefaults 0swaps
> 
> And then about 12 minutes while the changes are being trickled back to the
> server, but the user isn't forced to wait for this.

Have you ever checked load on the server? When doing something like
reintegration or untarring a kernel, the load on my server(s), codasrv
takes around 40-50% CPU. (this is on a PII-450, and from only one active
client!)
 
Another strange thing.. The SCM machine seemed to have a consistently
higher CPU load from codasrv by about 10%.. The servers are pretty much
identical also. Can anyone think of reasons for this, other than possibly
one disk being slower?

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy_at_microux.com     |    hozer_at_drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------