Hi.. I''ve tried both (HTB & CBQ) the queuing descpliens and I think HTB is more efficient than CBQ. But i think HTB is still in beta. I just want to know if I can go for HTB right away. I mean, is it stable? I''m trying to implement it in my company and thus stability and performance is big issue in this case. Please correct me if i''m wrong. Thank you very much, Bikrant _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Sunday 29 September 2002 07:40, brt_informatics@wlink.com.np wrote:> Hi.. > I''ve tried both (HTB & CBQ) the queuing descpliens and I think HTB is > more efficient than CBQ. But i think HTB is still in beta. I just want > to know if I can go for HTB right away. I mean, is it stable? I''m > trying to implement it in my company and thus stability and performance > is big issue in this case. > Please correct me if i''m wrong.It''s not because cbq is in the kernel for a long time that it is stable. I know more bugs/problems with cbq then with htb. I think htb is better because : - design - less obscure options - actively maintained - faster - included in kernel 2.4.20 :) Just my 2¢ Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef, Please can you detail the arguments to use CBQ and HTB? Why HTB is better than CBQ? Which are the weakness of CBQ implementation which solved by HTB? Thank you, R. --- Stef Coene <stef.coene@docum.org> wrote:> On Sunday 29 September 2002 07:40, > brt_informatics@wlink.com.np wrote: > > Hi.. > > I''ve tried both (HTB & CBQ) the queuing descpliens > and I think HTB is > > more efficient than CBQ. But i think HTB is still > in beta. I just want > > to know if I can go for HTB right away. I mean, is > it stable? I''m > > trying to implement it in my company and thus > stability and performance > > is big issue in this case. > > Please correct me if i''m wrong. > It''s not because cbq is in the kernel for a long > time that it is stable. I > know more bugs/problems with cbq then with htb. > > I think htb is better because : > - design > - less obscure options > - actively maintained > - faster > - included in kernel 2.4.20 :) > > Just my 2 > > Stef > > -- > > stef.coene@docum.org > "Using Linux as bandwidth manager" > http://www.docum.org/ > #lartc @ irc.oftc.net > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:http://lartc.org/ __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 30 September 2002 12:52, SERBAN Rares wrote:> Hi Stef, > > Please can you detail the arguments to use CBQ and > HTB? Why HTB is better than CBQ? Which are the > weakness of CBQ implementation which solved by HTB?For the performance difference, take a look at the htb homepage. Devik did some tests with both htb2, htb3 and cbq. Cbq has a weak theory background. It works by calculating the idle time of the link. But the only input we have to calculate this is the number of packets the NIC send. So you have to know your NIC bandwidth, the average packet size, and some other obscure options (allot). If you have different packet size or a changing NIC bandwidth (pppoe, pptp), you can get strange results with cbq. Htb on the other hand is based on tbf. It does not need to know NIC bandwidth, nor average packet size. It has a total different approach to do traffic shaping. I refer to the htb homepage for more info about the theory background of htb. And one of the mose convincing arguments to me : htb is actively maintained. If there is a bug or performance problem, it will get fixed. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Stef Coene wrote:>And one of the mose convincing arguments to me : htb is actively maintained. >If there is a bug or performance problem, it will get fixed. > >And, being newer code that many of us have looked at, patches / fixes will probably flow to the maintainer faster than CBQ ones. BTW, how many people are using the patched SFQ (ESFQ?) these days, and how stable is it? -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 30 September 2002 17:26, Michael T. Babcock wrote:> Stef Coene wrote: > >And one of the mose convincing arguments to me : htb is actively > > maintained. If there is a bug or performance problem, it will get fixed. > > And, being newer code that many of us have looked at, patches / fixes > will probably flow to the maintainer faster than CBQ ones. > > BTW, how many people are using the patched SFQ (ESFQ?) these days, and > how stable is it?I used it and it was stable. I''m going to switch over to kernel 2.5. Will the efsq patch apply? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Vladimír Trebický wrote:>I use ESFQ and it''s stable and functional ;-) Really. Read my article about >not setting perturb too small. > >Yes, I saw that; its a good hint for SFQ as well (and it fixed some neat oddities too). Anyone else seen this one? ping -n {remote host} { 6 second delay } 64 bytes from 216.168.105.33: icmp_seq=0 ttl=255 time=6sec 64 bytes from 216.168.105.33: icmp_seq=1 ttl=255 time=5sec 64 bytes from 216.168.105.33: icmp_seq=2 ttl=255 time=4sec 64 bytes from 216.168.105.33: icmp_seq=3 ttl=255 time=3sec 64 bytes from 216.168.105.33: icmp_seq=4 ttl=255 time=2sec 64 bytes from 216.168.105.33: icmp_seq=5 ttl=255 time=1sec 64 bytes from 216.168.105.33: icmp_seq=6 ttl=255 time=242usec 64 bytes from 216.168.105.33: icmp_seq=7 ttl=255 time=250usec ... -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> Anyone else seen this one? > > ping -n {remote host} > { 6 second delay } > 64 bytes from 216.168.105.33: icmp_seq=0 ttl=255 time=6sec > 64 bytes from 216.168.105.33: icmp_seq=1 ttl=255 time=5sec > 64 bytes from 216.168.105.33: icmp_seq=2 ttl=255 time=4sec > 64 bytes from 216.168.105.33: icmp_seq=3 ttl=255 time=3sec > 64 bytes from 216.168.105.33: icmp_seq=4 ttl=255 time=2sec > 64 bytes from 216.168.105.33: icmp_seq=5 ttl=255 time=1sec > 64 bytes from 216.168.105.33: icmp_seq=6 ttl=255 time=242usec > 64 bytes from 216.168.105.33: icmp_seq=7 ttl=255 time=250usec > ...suse linux? if so, reverse lookup doesn''t work, for that ip. - -- Regards, Robert - ---------------- Robert Penz robert.penz AT outertech.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9mZ7y8tTsQqJDUBMRAs+5AJ9lWrTDyCN8RA1MWwWXPazCoxkSrACgnrhC xh2G6e1NzgmDzQlJI2qOfjs=ryCz -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Robert Penz wrote:>suse linux? if so, reverse lookup doesn''t work, for that ip. > >Note the ''ping -n'' -- no reverse lookup being done. -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/