Just for the record, the TCP Quantum value apparently controls how
much data AFP sends or receives in a single OS call; this would be
analogous to the "buffer length" iperf argument (-l). Here is the
actual description we got from Brad Suinn at Apple:
The TCP Quantum Size is the maximum sized block of data that can be
read/write to/from the server in one AFP transaction. So, if I
issue a read, then maximum amount of data that can be read for that
particular request is one quantum size.
For example, if the quantum size is at the default of 256Kb, and a
process makes a 1Mb read, then the read gets broken down into 4 AFP
Read requests each asking for 256Kb. If you increase the quantum
size to be 1 Mb, then only 1 AFP Read request is done getting the
entire 1 Mb.
FWIW, I'll echo Steve's suggestion that trying to tune AFP is a dead
end, especially since you seem to have isolated the problem to poor
network performance, with AFP out of the picture.
The HP response sounds like a brush-off to me.
Jim.
On Sep 23, 2005, at 10:14 AM, Steve Modica wrote:
Hi Chris,
I never did geta good answer on the TCP Quantum value. It was a
while ago, but I believe ktraces didn't show any difference in the
AFP transfer sizes regardless of how I set that parameter. I have
not tried again with 10.4.
Jim knows a lot more about send/recv space and how Mac OS X deals
with them. I'll let him answer that.
We more or less gave up on AFP because it just can't go fast enough
to enable high bandwidth cards. We've been working on our own
remote filesystem called "Blaze".
Steve
Chris McFarling wrote:
Steve,
I know you guys probably have better things to do than to give me
free tech
support, but if you do get a chance I have a quick question.
I came accross a post from you several months back on the
Macnetworkprog
list regarding the TCPQuantum param of OS X's AFP server. Did you
ever find
any info out about what exactly that setting does and how to
change it? I'm
guessing it's some sort of memory buffer or something????
Unfortunately the
only documentation that I can find says that the TCPQuantum
settings is used
to change the TCP quantum. (Not overly helpful)
When I left off on this thread, I was leaning toward a problem
with the HP
switch. So far HP doesn't agree...
Chris:
I'm sorry I missed your call. I left you a voicemail, but decided to
write you as well. I am not allowed to go into much detail on
testing
done here, except for the purposes of troubleshooting a real problem.
Unfortunately, test results of a freeware program run on a
computer do
not count as a real problem, especially when those results vary from
platform to platform. At any rate, such an application is not an
acceptable measurement of switch performance, basically for the
reasons
I mentioned yesterday. Vendors submit their products to be tested
and
certified. One such organization is Tolly Group, and you can read
about
their test of the Procurve 4108 at http://www.tolly.com/DocDetail.aspx?DocNumber=201138 . If you
want some
idea of what an Ixia device can do, then read this page: http://www.pcmag.com/article2/0,1759,6894,00.asp (they also
have a
summarized assessment of the 4108).
Sincerely,
Keith
Networking Hardware Support
Hewlett Packard
The freeware he's refering to is iperf. Anyway, I'm still plugging
away at
finding a solution on the OS end. Another odd thing that I see is
that
Finder copies, as well as dd copies (when used as pointed out by
Jim in an
earlier post on this thread) apparently use a TCP window size of
32768 while
iperf transfers use a window of 65535 (when all is set to default)
It was my
understanding that the OS will automatically use a window size of
65535,
regardless of what net.inet.tcp.recvspace is set to as long as
socket count
is lower than net.inet.tcp.sockthreshold. I wonder if the AFP server
circumvents this mechanism?
In any event, may main quaestion has to do with the TCPQuantum.
Any help is
greatly appreciated.
Chris
================================
Jim Hunter - Small Tree Communications
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
