[OpenAFS-devel] Vos dump "performance"

[Harald Barth]

> 1444 is the number of octets after subtracting the ip/ip6 and udp/udp6
> headers for a network with MTU of 1500.

Yes but here I was on localhost and that has a loopback does have an
MTU of 16436. If the MTU detection code does the right thing(TM).

> Remember that Rx takes
> advantage of larger network MTUs via the use of Jumbograms which combine
> multiple Rx packets into one UDP message.

> Also remember that jumbo
> grams are disabled by default because of the negative impact that occurs
> when using them over the public Internet.

I think there are two mechanisms which may interact:

1. packing multiple RX packets into one UDP packet (mostly a good
   thing unless high packet drop)

2. making UDP packets bigger than MTU (only a good thing if one knows
   that there is almost no packet drop and reassembly is cheap.

> The biggest cause of the performance problems you are seeing is Rx.

My newest measurements make me believe that that's actually not the
case because my numbers are equally bad when using voldump or tar
after forcibly throwing away the buffer cache. No rx involved at all.
But when I use tar multiple times buffer cache seems to help. When
using voldump not so. I'll have to confirm my measurements by more
runs (which take each approx 2.5h). Some of my numbers I get from
strace feel fishy, so I have to confirm them again.

> The
> window size is small and every time that the sender doesn't have data to
> send the connection stalls.

True.

> Every time the reader performs disk i/o it
> stops reading from the stream and the Rx connection stalls.

Does not seem to be a problem in my case because even when I write to
/dev/null the numbers are the same.

> Volume moves, releases and dumps are some of the operations in which the
> AuriStor Rx stack performance changes are quite noticeable.

;-)

Harald.