Thread (1 message) 1 message, 1 author, 2012-07-17

Re: [PATCH] netem: fix rate extension and drop accounting

From: Eric Dumazet <hidden>
Date: 2012-07-17 17:39:38

Please Mark :

1) Dont top post on netdev

2) Dont write HTML mails on netdev (your mail never went to netdev,
   only to CCed people). Only text mails are allowed.

On Tue, 2012-07-17 at 10:20 -0700, Mark Gordon wrote:
Even the static delay case seems wrong with the new patch.  Assume all
packets have the same sched_time.  Then if you spam packets that get
processed at the same time by netem they will all get scheduled with
the same time_to_send because the first packet will get time_to_send
of [1] = clock_time + sched_time.  Then packet n compute 'now' as
[n-1] and delay as sched_time - (clock_time - [1]) = 0 so that [n] =
[n-1].  Therefore every packet gets scheduled at the same time.


The above modification seems to fix the issue when latency/jitter is 0
but suffers from a missing non-linearity when delay is present.  Is
there a technical reason I'm missing that prevents us from doing rate
and latency here?  Why wouldn't the 'official' patch have correct
rate?
Because delay is variable (jitter)

netem as is is not working correctly if you have both a rate limit and
delay.

Hagen is working on a solution, but there is no easy fix.

The right solution is to have :

1) A rate stage, using a child qdisc (that you can graft to install your
own qdisc hierarchy if needed, say if you want codel or fq_codel ;))

  Thats basically a TBF...

2) skb orphan

3) drops/reorders/corrupt/additional delay (variable delay)
   using an internal tfifo, to mimic real networks behavior.

Thats the reverse of how its currently done.

Alternatively, this could be implemented as a special network device,
like bonding, instead of a qdisc.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help