[OpenAFS] Network becomes terribly slow when cache manager flushes
updates over xDSL
Douglas E. Engert
deengert@anl.gov
Tue, 07 Jul 2009 13:24:00 -0500
Goulou wrote:
>> My feeling is that #define RX_MAX_FRAG 1 instead of 4 does make
>> things
>> behave better if there is packet loss to be expected.
>=20
> 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...)
>=20
>> About xDSL:
>>
>> It might be the case that the throttling of TCP compared to the
>> throttling
>> of rx (over UDP) looses when xDSL is involved. That is very difficult
>> to
>> predict without actually monitoring the packets on the wire in
>> question.
>>
>> Another guess: It might be that your xDSL allways behaves shitty
>> (like
>> gets very long latency) when it gets near full. It might be that your
>> provicer tunnels your xDSL over some other transport somewhere.
>=20
> 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...
>=20
It could also be the MTU over DSL is smaller then you think, and so many/=
most packets
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=
he actual
MTU being used. Use ping with the don't fragment options to test at what=
size fragmentation
occurs.
ping -M do -s nnnn ...
The Windows version already has a registry setting to do the same thing.
> Thanks again for your help.
>=20
> Fr=C3=A9d=C3=A9ric Grelot.
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
>=20
--=20
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444