Live data from Hacker News

OpenBSD: PF queues break the 4 Gbps barrier

undeadly.org

61–70 of 74 posts

Re: OpenBSD: PF queues break the 4 Gbps barrier

#61

In the days when even cheap consumer hardware ships with 2.5G ports, this number seems weirdly low. Does this mean that basically nobody is currently using OpenBSD in the datacentre or anywhere that might be expecting to handle 10G or higher per port, or is it just filtering that's an issue? I'm not surprised that the issue exists as even 10 years ago these speeds were uncommon outside of the datacentre, I'm just sur…

AFAIK performance is not a priority for OpenBSD project - security is (and other related qualities like code which is easy to understand and maintain). FreeBSD (at least when I followed it several years ago) had better performance both for ipfw and its own PF fork (not fully compatible with OpenBSD one).

> not fully compatible with OpenBSD one

The OpenBSD NAT and scrub syntax, and af-to are available in FreeBSD 15.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#62
post #38
post #32

Earlier quoted context omitted.

Yeah, that's pretty appalling. Regardless of how good the philosophy of something is, if it's as niche and manpower constrained as OpenBSD is then it's going to accumulate problems like this.

I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux. That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation. This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes…

Code size would balloon if you try to format verbose error messages. I often look at the binaries of old EPROMs. I notice that 1) the amount of ASCII text is a big fraction of the binary 2) still just categories (“Illegal operation”). For the 1970s, we’re talking user programs that fit in 2K.

I write really verbose diagnostic messages in my modern code.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#63
post #38
post #32

Earlier quoted context omitted.

Yeah, that's pretty appalling. Regardless of how good the philosophy of something is, if it's as niche and manpower constrained as OpenBSD is then it's going to accumulate problems like this.

I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux. That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation. This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes…

> That attitude may seem out of place today

That attitude was out of place at every point. Now it was excusable when RAM and disk space was sparse, it isn't today, it have entirely drawbacks

Re: OpenBSD: PF queues break the 4 Gbps barrier

#64

In the days when even cheap consumer hardware ships with 2.5G ports, this number seems weirdly low. Does this mean that basically nobody is currently using OpenBSD in the datacentre or anywhere that might be expecting to handle 10G or higher per port, or is it just filtering that's an issue? I'm not surprised that the issue exists as even 10 years ago these speeds were uncommon outside of the datacentre, I'm just sur…

There is no reason to use OpenBSD (aside "we have OpenBSD nerds in staff" or I guess "we don't want to GPL our changes"), we had it ages ago (for the first of mentioned reasons) but even they dumped it once new server hardware wasn't supported.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#65
post #9

Can pf actually shape at speeds above 4 gbps?

With 7.9, shaping (read: bandwidth rate limiting) no longer tops out at 4 Gbps. PF could always process/transfer beyond 4 Gbps, presuming you had fast enough hardware to handle such bandwidth. The discussed limit was specific only to queues, when using such to shape traffic.

If you're asking about OpenBSD/PF's general network performance, it is finally performing acceptably since a couple of years back. You can easily saturate a 2.5 GbE interface with low-end hardware.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#68

In the days when even cheap consumer hardware ships with 2.5G ports, this number seems weirdly low. Does this mean that basically nobody is currently using OpenBSD in the datacentre or anywhere that might be expecting to handle 10G or higher per port, or is it just filtering that's an issue? I'm not surprised that the issue exists as even 10 years ago these speeds were uncommon outside of the datacentre, I'm just sur…

OpenBSD was a great OS back in the late 90s and even early 2000s. In some cases it was competing neck to neck with Linux. Since then, well, Linux grew a lot and OpenBSD not so much. There are multiple causes for this, I will go only through a few: Linux has more support from the big companies; the huge difference in userbase numbers; Linux is more welcoming to new users. And the difference is only growing.

> Linux is more welcoming to new users. And the difference is only growing.

Unless you want documentation. :) Linux documentation is ALL over the place, and it's hard to know if X docs apply to your particular mess.

On OpenBSD it's `man ` and you get your docs. Yes man exists on Linux, but lots of tools, especially "new" stuff or linux specific stuff doesn't come with man pages and those that do have man pages, can be missing lots of stuff.

Systemd docs tend to be somewhat useless, missing all sorts of stuff. Troubleshooting systemd by reading the docs is usually a waste of time. Reading the source code or getting lucky with a web search is usually your only hope.

On FreeBSD you get `man ` AND you get the FreeBSD handbook: https://docs.freebsd.org/en/books/handbook/

Re: OpenBSD: PF queues break the 4 Gbps barrier

#69
post #38

Earlier quoted context omitted.

I actually think this isn't even surprising from OpenBSD philosophically. They still subscribe to the Unix philosophy of old, moreso than FreeBSD and much much more than Linux. That is, "worse is better" and it's okay to accept a somewhat leaky abstraction or less helpful diagnostics if it simplifies the implementation. This is why `ed` doesn't bother to say anything but "?" to erroneous commands. If the user messes…

Code size would balloon if you try to format verbose error messages. I often look at the binaries of old EPROMs. I notice that 1) the amount of ASCII text is a big fraction of the binary 2) still just categories (“Illegal operation”). For the 1970s, we’re talking user programs that fit in 2K. I write really verbose diagnostic messages in my modern code.

There was also an implicit saving back then that an error message could be looked up in some other system (typically, a printed manual). You didn't need to write 200 chars to the screen if you could display something much shorter, like SYS-3175, and be confident that the user could look that up in the manual and understand what they're being told and what to do about it.

IBM were experts at this, right up to the OS/2 days. And as machines got more powerful, it was easy to put in code to display the extra text by a lookup in a separate file/resource. Plus it made internationalization very easy.

Re: OpenBSD: PF queues break the 4 Gbps barrier

#70

Earlier quoted context omitted.

It's widely used as a router, that's one of its primary uses. But not sure to what scale, likely at small orgs not at major ISPs. But, OpenBSD is a project by and for its developers. They use it and develop it to do what they want; they don't really care what anyone else does or doesn't do with it.

Do people actually use OpenBSD over FreeBSD for use as a router ?

Yes, lots of large providers really want defense in depth at the router/firewall/important services level.

They want separate OS's in case a giant CVE or bug comes out for platform X but isn't on platform Y. So multi-platform core services is a key component of systems that need to stay up and alive long-term. Things like Routers, Firewalls, DNS, BGP, etc. Use different software and hardware stacks.

We use FreeBSD and Debian @ work, though we are playing around with Nix and Guix now to maybe replace the Debian someday.

Post reply on HN