Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation

David Miller wrote: From: Martin Devera <[EMAIL PROTECTED]> Date: Mon, 18 Feb 2008 09:03:52 +0100 aha, ok, I'm not so informed about crossplatform issues. I was also thining about looking at jiffies value and stop once it is startjiffy+2, but with NO_HZ introduction, are ji

Re: [PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation

up to single jiffy interval and then delay remainder to other jiffy. Signed-off-by: Martin Devera <[EMAIL PROTECTED]> I think we would be wise to use something other than loops_per_jiffy. Depending upon the loop calibration method used by a particular architecture it can me one o

[PATCH 2.6.24 1/1] sch_htb: fix "too many events" situation

From: Martin Devera <[EMAIL PROTECTED]> HTB is event driven algorithm and part of its work is to apply scheduled events at proper times. It tried to defend itself from livelock by processing only limited number of events per dequeue. Because of faster computers some users already hi

Re: Not understand some in htb_do_events function

So this was meant to protect against endless loops? We want way to smooth big burst of events over more dequeue invocations in order to not slow dequeue too much. Constant 500 is max. allowed "slowdown" of dequeue. Any bright idea how to do it more elegant, Patrick ? Unfortunately not, but I

Re: Not understand some in htb_do_events function

Badalian Vyacheslav wrote: Martin Devera пишет: Patrick McHardy wrote: Badalian Vyacheslav wrote: Hello all. I have many messages like "htb: too many events !" in dmesg. Try to see code and find that function try do 500 events at call. Hm... may anyone ask why 500? Why its not dyn

Re: Not understand some in htb_do_events function

Patrick McHardy wrote: Badalian Vyacheslav wrote: Hello all. I have many messages like "htb: too many events !" in dmesg. Try to see code and find that function try do 500 events at call. Hm... may anyone ask why 500? Why its not dynamic value based on performance of PC? Thats a good questi

[Fwd: [NET_SCHED 09/10]: sch_htb: use hrtimer based watchdog]

[NET_SCHED]: sch_htb: use hrtimer based watchdog Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Acked-by: Martin Devera <[EMAIL PROTECTED]> --- commit a5eaa252c5da48fef25a308ebc99b4020dad7f64 tree a609ff508f5ec9a93df1ace8f814aa0a71a5ff97 parent 2d548d3ea10cb1b49db8913fbab3

Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option

Russell Stuart wrote: The HTB qdisc has a compile time option, HTB_HYSTERESIS, that trades accuracy of traffic classification for CPU time. These patches change hysteresis to be a runtime option under the control of "tc". The effects of HYSTERESIS on HTB's accuracy are significant (see chap