4 ms·

> you still wouldn't use OpenBSD (or anything other > than Linux) for QoS. Is this still the case? Especially in regards to OpenBSD managing a fast resident

by dfc 11y ago

> you still wouldn't use OpenBSD (or anything other > than Linux) for QoS. Is this still the case? Especially in regards to OpenBSD managing a fast residential cable connection? I thought 5.6 yanked out the slow ALTQ code and brought OBSD close to linux QoS performance, especially for residential traffic management.

wtallis 11y ago
From a quick skim of the manpages and a few google searches, it looks like pf is a really poor substitute for tc. Without CoDel and friends, OpenBSD can at best implement half of a good QoS system.
- dfc 11y ago
  Your categorical rejection of openbsd+pf is based on a cursory google search and man page comparison? I have not seen any QoS comparisons of OpenBSD 5.6 versus Linux. Did you find any?
  - wtallis 11y ago
    There's nothing to compare. OpenBSD just plain doesn't have any active queue management. They used to have RED in the altq module, but it's been removed and I haven't found any mention of any other form of support for any of the common AQM algorithms. If it supports anything more advanced than classifying packets into a fixed set of priority queues with fixed packet count limits, it's well-hidden. What functionality is exposed and advertised through their man pages is simply not enough to put together a fully functional QoS system, regardless of how efficient it is with CPU time. There isn't even the theoretical possibility of OpenBSD doing good QoS unless they've got a large amount of complexity hidden and misleadingly glossed over by their documentation. In this case, running a dumb algorithm arbitrarily fast can never compete with the smarter algorithms.
- wglb 11y ago
  Might I suggest that you try it out before making such a firm statement?
  - wtallis 11y ago
    Try what? The pf.conf man page section for queuing describes only functionality that is effectively equivalent to HTB or possibly HFSC on Linux. That algorithm on its own fundamentally cannot keep latency low because it has no mechanism to restrict queue length without crippling bandwidth. If OpenBSD's current HTB-equivalent is much more efficient than it used to be, that's an improvement but it's still only one of several required components and cannot get the job done on its own.
    - ben_bai 11y ago
      I second that motion. Try it (OpenBSD with pf). I have not played with traffic shaping for myself but as always with OpenBSD I guess i would be surprised how well it works. set prio, set queue and set tos seems to be the "tools" to use.
      - wtallis 11y ago
        Why should I expect OpenBSD to not suffer from the universal problems of overly large queues when they haven't documented any mitigation techniques? I can't even find out how to get OpenBSD to do ECN marking without the now-removed altq module.
        wglb 11y ago
        Does this help https://calomel.org/pf_config.html https://calomel.org/pf_config.html?

by dfc 11y ago

wtallis 11y ago

From a quick skim of the manpages and a few google searches, it looks like pf is a really poor substitute for tc. Without CoDel and friends, OpenBSD can at best implement half of a good QoS system.

dfc 11y ago
Your categorical rejection of openbsd+pf is based on a cursory google search and man page comparison? I have not seen any QoS comparisons of OpenBSD 5.6 versus Linux. Did you find any?
- wtallis 11y ago
  There's nothing to compare. OpenBSD just plain doesn't have any active queue management. They used to have RED in the altq module, but it's been removed and I haven't found any mention of any other form of support for any of the common AQM algorithms. If it supports anything more advanced than classifying packets into a fixed set of priority queues with fixed packet count limits, it's well-hidden. What functionality is exposed and advertised through their man pages is simply not enough to put together a fully functional QoS system, regardless of how efficient it is with CPU time. There isn't even the theoretical possibility of OpenBSD doing good QoS unless they've got a large amount of complexity hidden and misleadingly glossed over by their documentation. In this case, running a dumb algorithm arbitrarily fast can never compete with the smarter algorithms.
wglb 11y ago
Might I suggest that you try it out before making such a firm statement?
- wtallis 11y ago
  Try what? The pf.conf man page section for queuing describes only functionality that is effectively equivalent to HTB or possibly HFSC on Linux. That algorithm on its own fundamentally cannot keep latency low because it has no mechanism to restrict queue length without crippling bandwidth. If OpenBSD's current HTB-equivalent is much more efficient than it used to be, that's an improvement but it's still only one of several required components and cannot get the job done on its own.
  - ben_bai 11y ago
    I second that motion. Try it (OpenBSD with pf). I have not played with traffic shaping for myself but as always with OpenBSD I guess i would be surprised how well it works. set prio, set queue and set tos seems to be the "tools" to use.
    - wtallis 11y ago
      Why should I expect OpenBSD to not suffer from the universal problems of overly large queues when they haven't documented any mitigation techniques? I can't even find out how to get OpenBSD to do ECN marking without the now-removed altq module.
      - wglb 11y ago
        Does this help https://calomel.org/pf_config.html https://calomel.org/pf_config.html?