In message <[EMAIL PROTECTED]>,Default writes:
>1. try again with 3.6 - rx is summat different now.
i dont believe there is a different. openafs clients talking to my modified
afs servers dont use every use a packet size bigger than ~5700.
>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.
well you wont exactly see a performance difference. the real bottleneck
is really the cache. however, i would like to see my mtu size put to use.
eventually we will take care of the cache speed problem. we are looking
into a 'cache bypass' for 'certain' files. its certainly more efficient to
recv 1 packet instead of 2.
>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.
however MAX_FRAGS isnt large enough to ever take advantage of the PACKET_SIZE
with a value of 4, the biggest packet you will ever see if something like
~5700. clients and server negotiate the size of packets to be used (based
on the interface mtu among other things) MAX_FRAGS seems to limit the
upper end of packet sizes.
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo.cgi/openafs-devel
