[OpenAFS] Heavy performance loss on gigabit ethernet

[Derrick J Brashear]

On Tue, 17 Aug 2004, Systems Administration wrote:

nn>> The problem is in the calculation of the rtt (round trip time) and
>> retransmit timeout. If the rtt is 0, then it is considered not initialized,
>> and the timeout is set to 2 or 3 seconds (depending on whether the server
>> is considered 'local' to the client), whereas if the rtt is low, but
>> non-zero, the timeout can drop as low as 0.35 seconds. You can examine the
>> rtt and timeout values of an rx server or client using the -peers switch of
>> the rxdebug command.
>
> Hmmm, so unless there is enough latency in the loop the client goes deaf 
> effectively when a frame gets dropped by the ethernet media-to-media 
> conversion (fiber to copper) - because the rtt was indistinguishable from 0 
> the timeout is set so high that the server and client get out of synch?

no. that would be a serious problem. this one is only annoying.

>
> Another interesting point - can I assume that the output of rxdebug is 
> reporting MTU which is the tcp MTU - if so how does the AFS binary think it 
> can send MTUs of 5692 when the interface is declared to have an MTU of 1500 - 
> I know the client cannot handle that large an MTU because the intermediate 
> hops on the ethernet connection are not gigabit capable.  Could the server be 
> trying to send a bogus packet with 5692 data octets which are getting dropped 
> on the floor due to an invalid MTU size?

well, it's not tcp mtu, but it's probably confused and i can't just guess 
why.