[OpenAFS] Network becomes terribly slow when cache manager flushes updates over xDSL

[Douglas E. Engert]

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