Thread (13 messages) 13 messages, 3 authors, 2005-05-25

Re: [PATCH] netem: fix logic bug in reorder conditional

From: Stephen Hemminger <hidden>
Date: 2005-05-24 16:57:07

On Tue, 24 May 2005 12:41:11 -0300
Julio Kriger [off-list ref] wrote:
quoted
quoted
2) If I set latency = 50ms and a jitter = 300ms, tabledist can give me
a negative number. This value is addes to cb->time_to_send, so it
could change it to a negative value. Should we only accept positives
number before add it to cb->time_to_send? or will
q->qdisc->enqueue(skb, q->qdisc) put the package on the queue in a
special way so it will be handled "before" other packages alrealy on
the queue but with gretaer time_to_send?
probably should bound the value to 0 before the addition, to avoid large
wraparound problems, but since enqueue checks for for time it will work
as long as delta less than 2^32/2.
I think the value should be restricted to be positive and greater than
zero. Becuase if a negative number is allowed we will be "losing"
packages to be reordered, hence we will not be reordering, say 25%, of
packages instead we will be reordering about 15%.
In other words, packages that should be reordered will not be
reordered because its new time to send will be the same as the old
time to send.
Regards,
Julio
The problem is that the user specification (latency 50ms +/- 300ms with reordering) 
is problematic. Just like specifying reordering without delay (and a fast connection).

I chose to keep the original method of reordering by putting things at front of the
queue. Another alternative would be to keep a side-stack of packets to wait for
reordering. The problem with that is that if no following packet arrives, we end up
holding onto the last packet forever; and that would be bad.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help