Re: New queueing system and HZ value limits
On 2014-08-22, Henning Brauer hb-open...@ml.bsws.de wrote: * Stuart Henderson s...@spacehopper.org [2014-08-22 13:51]: On 2014-08-22, Henning Brauer hb-open...@ml.bsws.de wrote: * Federico Giannici giann...@neomedia.it [2014-08-22 09:51]: On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? kinda obvious: BW measurement and go/holdoff decision is (at most) once per tick. ticks @ HZ, aka 100 ticks per second with HZ=100. If the NIC can transfer too much data within one tick, the bw shaping becomes inaccurate. Obviously worse the bigger the difference between interface speed and desired queue speed is. Any idea why this was so much less of a problem with altq? it wasn't... the hfsc core was the same, and cbq worked exactly the same way too. People might not have paid as much attention? I dunno. If anything I'd expect altq to be less accurate as IIRC it used getmicrouptime rather than microuptime But somehow, my setup with 512K-1Mb queues (pppoe with pppoedev on em0, 100Mb link on a 1Gb nic) worked ok with altq with default HZ.
Re: New queueing system and HZ value limits
Henning Brauer [hb-open...@ml.bsws.de] wrote: Any idea why this was so much less of a problem with altq? it wasn't... the hfsc core was the same, and cbq worked exactly the same way too. People might not have paid as much attention? I dunno. Raising HZ was frowned upon when I ported altq because it sped up _everything_ for the benefit of a potentially unused subsystem. I bet there is a technique to be learned from tickless kernels here.
Re: New queueing system and HZ value limits
* Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: New queueing system and HZ value limits
On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? Thanks.
Re: New queueing system and HZ value limits
* Federico Giannici giann...@neomedia.it [2014-08-22 09:51]: On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? kinda obvious: BW measurement and go/holdoff decision is (at most) once per tick. ticks @ HZ, aka 100 ticks per second with HZ=100. If the NIC can transfer too much data within one tick, the bw shaping becomes inaccurate. Obviously worse the bigger the difference between interface speed and desired queue speed is. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: New queueing system and HZ value limits
On Fri, Aug 22, 2014 at 10:05 AM, Henning Brauer hb-open...@ml.bsws.de wrote: * Federico Giannici giann...@neomedia.it [2014-08-22 09:51]: On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? kinda obvious: BW measurement and go/holdoff decision is (at most) once per tick. ticks @ HZ, aka 100 ticks per second with HZ=100. If the NIC can transfer too much data within one tick, the bw shaping becomes inaccurate. Obviously worse the bigger the difference between interface speed and desired queue speed is. FWIW, HZ in Linux defaults to 1000.
Re: New queueing system and HZ value limits
On 2014-08-22, Henning Brauer hb-open...@ml.bsws.de wrote: * Federico Giannici giann...@neomedia.it [2014-08-22 09:51]: On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? kinda obvious: BW measurement and go/holdoff decision is (at most) once per tick. ticks @ HZ, aka 100 ticks per second with HZ=100. If the NIC can transfer too much data within one tick, the bw shaping becomes inaccurate. Obviously worse the bigger the difference between interface speed and desired queue speed is. Any idea why this was so much less of a problem with altq?
Re: New queueing system and HZ value limits
* Stuart Henderson s...@spacehopper.org [2014-08-22 13:51]: On 2014-08-22, Henning Brauer hb-open...@ml.bsws.de wrote: * Federico Giannici giann...@neomedia.it [2014-08-22 09:51]: On 08/22/14 08:22, Henning Brauer wrote: * Adam Thompson athom...@athompso.net [2014-08-21 19:13]: Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? pretty much. I can imagine that it could be rather complicated to give the exact numbers, but can you give me an idea where the problem comes from, and maybe where I can find more info about it? kinda obvious: BW measurement and go/holdoff decision is (at most) once per tick. ticks @ HZ, aka 100 ticks per second with HZ=100. If the NIC can transfer too much data within one tick, the bw shaping becomes inaccurate. Obviously worse the bigger the difference between interface speed and desired queue speed is. Any idea why this was so much less of a problem with altq? it wasn't... the hfsc core was the same, and cbq worked exactly the same way too. People might not have paid as much attention? I dunno. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: New queueing system and HZ value limits
On 22-08-2014 08:58, Henning Brauer wrote: it wasn't... the hfsc core was the same, and cbq worked exactly the same way too. People might not have paid as much attention? I dunno. I believe it also has something to do with the network cards getting better and also the internet links speeds getting bigger over the years. I had problems with ALTQ using very small queues. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: New queueing system and HZ value limits
On 2014-08-21, Federico Giannici giann...@neomedia.it wrote: We are using a firewall/qos server with a lot of HFSC queues. We have just switched to the new queueing system of 5.5. We'd like to get rid of custom kernels because now there is no longer the limit of 64 HFSC classes, but I have recently read that there are still limits to the efficacy of the queueing system with the standard 100 HZ in systems with high speed connections. Is this still true? If so, is there some way to calculate, or at least have an idea, of the minimum HZ value required for a given output speed and queues parameters? Thanks. Queues with the default HZ are OK with high speed connections. The problem is with *low* speed connections. I don't know how to calculate values though.
Re: New queueing system and HZ value limits
Unless I've mis-understood all the emails and reports about this, it affects low-bandwidth queues, not low-bandwidth interfaces. In other words, limiting traffic to 50Mbps on a 1Gb link will work fine, limiting it to 50kbps on the same link will not. Yes/no? -Adam On August 21, 2014 12:03:12 PM CDT, Stuart Henderson s...@spacehopper.org wrote: On 2014-08-21, Federico Giannici giann...@neomedia.it wrote: We are using a firewall/qos server with a lot of HFSC queues. We have just switched to the new queueing system of 5.5. We'd like to get rid of custom kernels because now there is no longer the limit of 64 HFSC classes, but I have recently read that there are still limits to the efficacy of the queueing system with the standard 100 HZ in systems with high speed connections. Is this still true? If so, is there some way to calculate, or at least have an idea, of the minimum HZ value required for a given output speed and queues parameters? Thanks. Queues with the default HZ are OK with high speed connections. The problem is with *low* speed connections. I don't know how to calculate values though. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: New queueing system and HZ value limits
On 08/21/14 19:03, Stuart Henderson wrote: On 2014-08-21, Federico Giannici giann...@neomedia.it wrote: We are using a firewall/qos server with a lot of HFSC queues. We have just switched to the new queueing system of 5.5. We'd like to get rid of custom kernels because now there is no longer the limit of 64 HFSC classes, but I have recently read that there are still limits to the efficacy of the queueing system with the standard 100 HZ in systems with high speed connections. Is this still true? If so, is there some way to calculate, or at least have an idea, of the minimum HZ value required for a given output speed and queues parameters? Thanks. Queues with the default HZ are OK with high speed connections. The problem is with *low* speed connections. I don't know how to calculate values though. We have many slow speed queues (most of them from 2Mbps to 12Mbps and a few with higher speeds) with a relatively high speed output interface (currently 500Mbps). Any idea of HZ required in this situation? Thanks.
Re: New queueing system and HZ value limits
On 2014-08-21, Federico Giannici giann...@neomedia.it wrote: On 08/21/14 19:03, Stuart Henderson wrote: On 2014-08-21, Federico Giannici giann...@neomedia.it wrote: We are using a firewall/qos server with a lot of HFSC queues. We have just switched to the new queueing system of 5.5. We'd like to get rid of custom kernels because now there is no longer the limit of 64 HFSC classes, but I have recently read that there are still limits to the efficacy of the queueing system with the standard 100 HZ in systems with high speed connections. Is this still true? If so, is there some way to calculate, or at least have an idea, of the minimum HZ value required for a given output speed and queues parameters? Thanks. Queues with the default HZ are OK with high speed connections. The problem is with *low* speed connections. I don't know how to calculate values though. We have many slow speed queues (most of them from 2Mbps to 12Mbps and a few with higher speeds) with a relatively high speed output interface (currently 500Mbps). 500Mbps still sounds like a queue, since interfaces are 10Mb, 100Mb, 1Gb, 10Gb ... Any idea of HZ required in this situation? I don't - experimentation is probably required.
