Subject: Re: [netatalk-admins] Trash problems
From: a sun (asun@saul1.u.washington.edu)
Date: Mon Sep 28 1998 - 14:31:06 EDT
> Adrian: on another note, what sort of performance improvement
> areas would you think are best pursued. I seem to get very high
> transfer rates (with inferior os's like Windows NT) with SAMBA -
> but with netatalk, I get no more than about 600-650k/sec with
> netatalk. Would read-ahead/prediction code help? Larger i/o
> buffers perhaps? Or perhaps read/write overlapping technology
I know someone who's been doing some fairly serious performance testing,
mostly to see why web servers do better file throughput on NT than they do
on unix. The reason is that NT allows for one system call to transfer an
entire file out of a socket. Which means that the entire transfer is done
with only one system call, and everything else is handled in the kernel.
Unix handles all files in (usually) 8K blocks, which means that for every
8K, there's a system call. They're not that expensive, but for large
files, they add up significantly. But, that's most of the reason that NT
does better than unix when handling file throughput... For those who
care. :)
well, i can usually saturate 10BaseT in at least one direction in my
current setup. having g3's really helps here. unfortunately, i only
get about 4.5MB/s max throughput w/ 100BaseT in my setup and have
annoying slowdowns in a linux -> g3 running os 8.1 direction. i
actually suspect the current mac os of being the culprit, but i need
to load linux on the g3 to be sure.
currently, there's an inherent tradeoff between interactive response
and transfer speed. the appleshare client actually doesn't request the
entire file. it asks for it in fairly small pieces and intersperses it
every so often with FPEnumerate calls. as a result, you won't get
maximal throughput do to all the chatter. on my part, i would like to
separate the "data conversion on the fly path" more from the "no
conversion necessary" path. i've already dealt with parts of it, but
it still needs some work. that would allow a sendfile() case in the
future if apple's appleshare client were ever to handle that kind of
thing. as things stand now, though, it's a bit premature.
i would also like to make the FPEnumerate call faster as well as it's
probably one of the slowest calls that exist in afpd. given how the
appleshare client works, improving it should actually improve apparent
file transfer speed.
beyond that, i would look at the hardware/os setup a bit. afpd depends
upon the underlying os' fs structure for read-ahead/write-behind
buffering. in addition, i've noticed that non-dma capable ide drives
screw things up a lot as they fight with the ethernet card. when i do
performance testing of just file transfer performance, i usually use
something like helios lantest and compare it against a direct ftp
transfer. in most cases, the lantest throughput and the ftp throughput
match up pretty well.
-a
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:19 EST