[OpenAFS-devel] datagrams really arent big enough?

Default aeneous@speakeasy.org
Tue, 07 Nov 2000 07:27:04 -0500


> during some other testing a while ago (cira afs 3.5) i noticed a problem
> with datagram size.  my packet size always seemed to be limited to 5688
> while the mtu size of our network is 9218 (yes, it atm)

1. try again with 3.6 - rx is summat different now.
2. did you measure performance before and after?  I wouldn't think you'd see 
much more than a couple of percent better transfer rates.
3. ISTR that the intention of that code was in fact to permit changing that 
value by using adb on the binaries if necessary, so you didn't do anything 
gravely wrong, either.
4. kicking up the max packet size also increases the max receive window, I 
think, increases the memory requirements of the server, and increases the 
amount of data that must be resent in the event of a packet loss, so you might 
(probably not, but maybe) have actually reduced performance slightly.

> natMTU is 1444 (i guess this is the 'natural mtu size of an rx packet'),
> which means the max tSize will ever be is 5776--signicantly less
> than my interface mtu size.
> 
> at the time i increased RX_MAX_FRAGS to 6 to get afs to fill out the
> send/recv buffers.  its what has been running on our afs servers for
> a while now (over a year) and i havent seen a problem.  of course only
> the afs clients with the 'fixed' code use the bigger packets.  possibly
> tSize shouldnt be computed using the peer's natMTU? since RX_MAX_PACKET_SIZE
> is 16384, i would think RX_MAX_FRAGS would need to be a bit larger?

The reason PACKET_SIZE is apparently "too large" is to permit changing 
MAX_FRAGS on the fly, and still be compatible with all the other clients & 
servers in your network.  It wasn't an oversight.