On Fri, 2006-03-03 at 02:23 +0100, Markus Schulz wrote:
> The second rate table is 100% equivalent to realtime calc. But the
> static version differs for some ip-length values from it. And i don't
> understand why.
> Perhaps someone can point me to the difference?
> The program is only for testing rate tables calculations.
>
> It would be nice to do it without a htb or other qdisc module patch. And
> i think it should be possible :)
It is not possible.
The basic operation performed by the kernel is, in
pseudo code:
time_to_send_packet = rate_table[packet_length(packet)]
However, rate_table is always exactly 256 entries long.
An MTU is around 1500 bytes, so a large packet this
would index past the end of the table. This means the
packet length must be scaled back to a value that fits
within 0..255. Divisions are not allowed within the
kernel, so the scaling is done using a right shift. In
effect, for typical MTU's, the packet_length is divided
by 8. That is, 8 is the multiple of two (ie 8 = 2^N)
such that (1500 / 8 < 256).
So the rate table really looks like this:
packet_length 0..7 = rate_table[0]
packet_length 8..15 = rate_table[1]
packet_length 16..23 = rate_table[2]
packet_length 14..31 = rate_table[3]
packet_length 32..39 = rate_table[4]
packet_length 40..47 = rate_table[5]
packet_length 48..55 = rate_table[6]
:
Now by pure luck, this works with an ATM cell, if we
know the packet length accurately. It works because
the boundary 40..47/48..55 is exactly where we want
it to be - on a cell boundary. This is because 48
is evenly divisible by 16, and so our luck would
continue up to MTU's of 4095 (= 256 * 16 - 1).
Now consider what happens if we include an overhead
the kernel doesn't know about. Lets say 2 bytes.
Now our rate table looks like this:
packet_length 2..9 = rate_table[0]
packet_length 10..17 = rate_table[1]
packet_length 18..25 = rate_table[2]
packet_length 16..33 = rate_table[3]
packet_length 35..41 = rate_table[4]
packet_length 42..49 = rate_table[5]
packet_length 50..57 = rate_table[6]
:
Now the cell boundary occurs within a single rate
table entry, 42..49. There is no way that single
rate table table entry can be correct for both
42..48, and 49, so it all falls in a heap.
The simplest solution appears to be to make the kernel
aware of the overhead. That way it can always compute
the correct packet length before computing the atm
cell overhead, and we are back to the original case
where the atm payload length changed between rate
table cells, and all is good again. That of course
requires a patch to the kernel.
But even without the patch you are still better off with
having tc include the atm cell overhead in the rate
table. It will be wrong about 10% of the time (4 packet
lengths in 48), as opposed to being wrong all of the
time.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
