[Tmrg] Round table: Buffer sizes

[John Heffner]

Lachlan Andrew wrote:
> Greetings John,
> 
> On 25/09/2007, John Heffner <jheffner at psc.edu> wrote:
>> Lachlan Andrew wrote:
>>> suitable buffer sizes for this core set of tests?
>>
>> Given the relatively wide range of buffer sizes in hardware out there at
>> any given speed, and the significant effect buffer size can have on
>> congestion control, it seems like this should be an extra dimension
>> rather than fixed per link type.
> 
> Absolutely.  As Sally suggests, it would be good to have some tests
> specifically along this dimension.  That leaves open what value(s?) to
> use for this parameter for tests along other dimensions.
> 
>> Maybe select a couple different sizes based on a set of drain times?
>> Say, {1 ms, 10 ms, 100 ms, 1 sec}?  Convert this to bytes or packets by
>> dividing by the link byte or MTU packet rate.
> 
> Sounds good.  As I pointed out, converting delay to packets isn't as
> simple as dividing by MTU packet rate, because we have reverse ACKs
> which aren't full sized.  If we have an equal number of forward and
> backward flows every second ACK is delayed, we need a buffer of
> roughly  (3/2)(drain_time/MTU_rate)  packets.  Without delayed ACKs,
> it becomes  rougly  2(drain_time/MTU_rate).

What I was talking about was for a byte buffer, use 
(drain_time/byte_rate); for a packet buffer, (drain_time/packet_rate).

Some devices use packet buffers, and others use byte buffers.  I'm not 
sure there's a significant majority either way.  As you say, their 
behavior is definitely different when not all packets are the same size 
(mixed-MTU or bi-directional traffic).  I'm not sure if this effect is 
strong enough that you need to do both, but it couldn't hurt.  I'll 
admit I haven't been following this group closely enough to know exactly 
what the objective is for the "core" set of tests.


> In my limited experience, buffer sizes are typically powers of 2.  I
> propose that all "core" tests use buffers with a limit (in packets)
> equal to a power of 2.  Do others agree?

Hm, that's not really my experience.  Linux, for instance, uses a 
default of 100 or 1000 packets with most ethernet drivers.  Especially 
when talking about packets rather than bytes, a power of two seems kind 
of arbitrary.  I think a lot of older Fast/Gig switches used 64k 
buffers, or 42-43 packets at 1500 bytes.  OTOH, I don't think there's 
anything bad about using a power of two if it's convenient.

   -John