* [LARTC] [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
@ 2006-06-15 9:00 ` Russell Stuart
0 siblings, 0 replies; 6+ messages in thread
From: Russell Stuart @ 2006-06-15 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
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 chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discussion start about what we need to change to
get this upstream?
We see this as a feature enhancement, as such hope that
it can be queued in davem's net-2.6.18.git tree.
--
Regards
Russell Stuart and Jesper Brouer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
@ 2006-06-15 9:00 ` Russell Stuart
0 siblings, 0 replies; 6+ messages in thread
From: Russell Stuart @ 2006-06-15 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
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 chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discussion start about what we need to change to
get this upstream?
We see this as a feature enhancement, as such hope that
it can be queued in davem's net-2.6.18.git tree.
--
Regards
Russell Stuart and Jesper Brouer
^ permalink raw reply [flat|nested] 6+ messages in thread
* [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS
2006-06-15 9:00 ` Russell Stuart
@ 2006-06-15 9:49 ` Martin Devera
-1 siblings, 0 replies; 6+ messages in thread
From: Martin Devera @ 2006-06-15 9:49 UTC (permalink / raw)
To: Russell Stuart
Cc: Jamal Hadi Salim, Stephen Hemminger, netdev, lartc,
Jesper Dangaard Brouer
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 chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
> thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
> HTB's CPU usage on modern machines using broadband links
> is minimal. Currently HYSTERESIS is on by default, and
> requires a kernel re-compile to change. Altering it to
> be a runtime option will make life easier for the bulk of
> its users.
At time of HTB implementation I needed to reach 100MBit speed on
relatively slow box. The hysteresis was a way. On other side I used
hand-made TSC based measure tool to compute exact (15%) performance
gain. Today I'd measure it using oprofile.
When rethinking it again I'd suggest to re-measure real performance
impact for both flat and deep class hierarchy and consider switching the
hysteresis off by default (or even to remove the code if the gain is
negligible). If it is the case then it is the cleanest solution IMHO.
On other side I see no problem with attached patches. Have you tested
patched kernel with old "tc" tool ?
thanks for your effort,
Martin
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
@ 2006-06-15 9:49 ` Martin Devera
0 siblings, 0 replies; 6+ messages in thread
From: Martin Devera @ 2006-06-15 9:49 UTC (permalink / raw)
To: Russell Stuart
Cc: Jamal Hadi Salim, Stephen Hemminger, netdev, lartc,
Jesper Dangaard Brouer
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 chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
> thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
> HTB's CPU usage on modern machines using broadband links
> is minimal. Currently HYSTERESIS is on by default, and
> requires a kernel re-compile to change. Altering it to
> be a runtime option will make life easier for the bulk of
> its users.
At time of HTB implementation I needed to reach 100MBit speed on
relatively slow box. The hysteresis was a way. On other side I used
hand-made TSC based measure tool to compute exact (15%) performance
gain. Today I'd measure it using oprofile.
When rethinking it again I'd suggest to re-measure real performance
impact for both flat and deep class hierarchy and consider switching the
hysteresis off by default (or even to remove the code if the gain is
negligible). If it is the case then it is the cleanest solution IMHO.
On other side I see no problem with attached patches. Have you tested
patched kernel with old "tc" tool ?
thanks for your effort,
Martin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's
2006-06-15 9:49 ` [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option Martin Devera
@ 2006-06-20 23:13 ` Russell Stuart
-1 siblings, 0 replies; 6+ messages in thread
From: Russell Stuart @ 2006-06-20 23:13 UTC (permalink / raw)
To: Martin Devera; +Cc: Jesper Dangaard Brouer, netdev, Jamal Hadi Salim, lartc
On Thu, 2006-06-15 at 11:49 +0200, Martin Devera wrote:
> At time of HTB implementation I needed to reach 100MBit speed on
> relatively slow box. The hysteresis was a way. On other side I used
> hand-made TSC based measure tool to compute exact (15%) performance
> gain. Today I'd measure it using oprofile.
>
> When rethinking it again I'd suggest to re-measure real performance
> impact for both flat and deep class hierarchy and consider switching the
> hysteresis off by default (or even to remove the code if the gain is
> negligible). If it is the case then it is the cleanest solution IMHO.
I attended LCA 2006 this year. There was a presentation by
a group in New Zealand using Debian running on a embedded
box to bring the Internet to rural communities. Some of
these communities didn't have power or telephone, so the
setup ran over 802.11 over distances of up to 23Km using
solar cells for power. I don't recall exactly, but I think
the embedded box was using a 486 equivalent. I think they
had around 40 of these things up and going.
The point of the story is there are people out there who
use Linux on small processors, and often do imaginative
things with them. We would be doing them a disservice by
ripping out the code.
> On other side I see no problem with attached patches. Have you tested
> patched kernel with old "tc" tool ?
Yes.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
@ 2006-06-20 23:13 ` Russell Stuart
0 siblings, 0 replies; 6+ messages in thread
From: Russell Stuart @ 2006-06-20 23:13 UTC (permalink / raw)
To: Martin Devera; +Cc: Jesper Dangaard Brouer, netdev, Jamal Hadi Salim, lartc
On Thu, 2006-06-15 at 11:49 +0200, Martin Devera wrote:
> At time of HTB implementation I needed to reach 100MBit speed on
> relatively slow box. The hysteresis was a way. On other side I used
> hand-made TSC based measure tool to compute exact (15%) performance
> gain. Today I'd measure it using oprofile.
>
> When rethinking it again I'd suggest to re-measure real performance
> impact for both flat and deep class hierarchy and consider switching the
> hysteresis off by default (or even to remove the code if the gain is
> negligible). If it is the case then it is the cleanest solution IMHO.
I attended LCA 2006 this year. There was a presentation by
a group in New Zealand using Debian running on a embedded
box to bring the Internet to rural communities. Some of
these communities didn't have power or telephone, so the
setup ran over 802.11 over distances of up to 23Km using
solar cells for power. I don't recall exactly, but I think
the embedded box was using a 486 equivalent. I think they
had around 40 of these things up and going.
The point of the story is there are people out there who
use Linux on small processors, and often do imaginative
things with them. We would be doing them a disservice by
ripping out the code.
> On other side I see no problem with attached patches. Have you tested
> patched kernel with old "tc" tool ?
Yes.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-06-20 23:13 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-15 9:00 [LARTC] [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option Russell Stuart
2006-06-15 9:00 ` Russell Stuart
2006-06-15 9:49 ` [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS Martin Devera
2006-06-15 9:49 ` [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option Martin Devera
2006-06-20 23:13 ` [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's Russell Stuart
2006-06-20 23:13 ` [LARTC] Re: [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option Russell Stuart
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.