[OpenAFS] Network becomes terribly slow when cache manager flushes
updates over xDSL
Douglas E. Engert
Tue, 07 Jul 2009 13:24:00 -0500
>> My feeling is that #define RX_MAX_FRAG 1 instead of 4 does make
>> behave better if there is packet loss to be expected.
> I'll try this. I noticed by searching about this field the existence of=
a "jumbo" flag : I suppose it is not in official releases yet, since /sb=
in/afsd -help doesn't mention it? (and using it gives an error...)
>> About xDSL:
>> It might be the case that the throttling of TCP compared to the
>> of rx (over UDP) looses when xDSL is involved. That is very difficult
>> predict without actually monitoring the packets on the wire in
>> Another guess: It might be that your xDSL allways behaves shitty
>> gets very long latency) when it gets near full. It might be that your
>> provicer tunnels your xDSL over some other transport somewhere.
> I had the same problem with 2 different providers (one in a large city,=
one in in landscape), but I'll try some upload benchmarks...
It could also be the MTU over DSL is smaller then you think, and so many/=
are getting fragmented. A mod is being added in 1.4.11 to add -rxmaxmtu =
N to afsd
that can work on MAC or any Unix system. Set this to 56 bytes less then t=
MTU being used. Use ping with the don't fragment options to test at what=
ping -M do -s nnnn ...
The Windows version already has a registry setting to do the same thing.
> Thanks again for your help.
> Fr=C3=A9d=C3=A9ric Grelot.
> OpenAFS-info mailing list
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439