summaryrefslogtreecommitdiffstats
path: root/COPYING
diff options
context:
space:
mode:
authorJohannes Naab <jn@stusta.de>2013-01-23 11:36:51 +0000
committerDavid S. Miller <davem@davemloft.net>2013-01-29 15:43:02 -0500
commita13d3104710184ecc43edc35a25ae8092058463f (patch)
treebc42471ee734a697dfa684f03d80589ceadefa84 /COPYING
parent80d84ef3ff1ddc7a829c58980a9dd566a8af5203 (diff)
netem: fix delay calculation in rate extension
The delay calculation with the rate extension introduces in v3.3 does not properly work, if other packets are still queued for transmission. For the delay calculation to work, both delay types (latency and delay introduces by rate limitation) have to be handled differently. The latency delay for a packet can overlap with the delay of other packets. The delay introduced by the rate however is separate, and can only start, once all other rate-introduced delays finished. Latency delay is from same distribution for each packet, rate delay depends on the packet size. .: latency delay -: rate delay x: additional delay we have to wait since another packet is currently transmitted .....---- Packet 1 .....xx------ Packet 2 .....------ Packet 3 ^^^^^ latency stacks ^^ rate delay doesn't stack ^^ latency stacks -----> time When a packet is enqueued, we first consider the latency delay. If other packets are already queued, we can reduce the latency delay until the last packet in the queue is send, however the latency delay cannot be <0, since this would mean that the rate is overcommitted. The new reference point is the time at which the last packet will be send. To find the time, when the packet should be send, the rate introduces delay has to be added on top of that. Signed-off-by: Johannes Naab <jn@stusta.de> Acked-by: Hagen Paul Pfeifer <hagen@jauu.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions