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.
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 /sbin/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
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.
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/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 the
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.
Frédéric Grelot.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
