Running BSDs on AMD Ryzen 5000 Series – FreeBSD/Linux Benchmarks

https://www.phoronix.com/scan.php?page=article&item=amd-5900x-bsd

by vermaden • 6 years ago

83 52 6 years ago

webmobdev2• 6 years ago

I've always preferred FreeBSD over Linux, especially for servers, but the lack of hardware support has always been a hurdle. And Linux has, overtime managed to reach a kind of feature parity with it and even outperform it as many of these tests show.

thijsvandien• 6 years ago

The BSD's best feature that Linux won't rival is how boring they are (in a good way).

Koshkin2• 6 years ago

Slackware is comparably boring.

elric2• 6 years ago

Linux's decentralization is both its major strength and its major weakness. The differences between distros can be so large that you might as well be talking about two entirely different operating system. There is little consistency in design of tools. Many tools used to follow the UNIX Philosophy ("do one thing well"), but that no longer seems to be the case.

We (as in Linux users) used to make fun of Windows for how stupid everything was. You need a GUI for configuration because many options are hidden away in some kind of cryptic registry, deploying services is a PITA etc. Now we have somehow (d)evolved to that same mess. For instance, SystemD and SELinux are such a pain to work with (each for different reasons) that it feels like I have to fight my OS. Wanting an OS that works for me, instead of against me, was one of the major reasons why I switched from Windows to BSD and then Linux back in the 90s.

There's definitely something to be said for *BSD's boring, predictable simplicity. But perhaps there's some kind of force that automatically drives operating systems to bewildering compelxity as their user base grows?

sandworm101• 6 years ago

Boring is a feature. For an OS it is THE feature. An OS is a necessary evil. It doesn't actually complete any user tasks, much like a car's engine doesn't do the actual driving. An OS should take the low-level tasks assigned to it, complete them without issue, not do anything unexpected, and generally stay out of the user's way. A car engine's job is to start and stop when asked, not to organize the driver's inbox. BSD has remained true to this while Linux has moved away in recent years.

On the flip side it windows. That OS doesn't hide in the background, rather it screams for attention 24/7, inserting itself in every little task even when specifically told to back off.

brobdingnagians• 6 years ago

There are some cases where squeezing every ounce of performance out of the hardware matters, but for most use cases there is a reasonable "good enough"; and these results show that BSD and Linux are comparable. I think the killer feature that the BSDs have, which Linux can't match, is how well designed, integrated, predictable, and simple they are. That is why I run more BSD servers than Linux servers. I do run Linux servers for some cases, and they work well for those cases, but I much prefer working with BSD.

webmobdev2• 6 years ago

how well designed, integrated, predictable, and simple they are.

Yeah, and the good documentation. Wish more open source projects had these.

lordgroff2• 6 years ago

I like the BSD simplicity, but it's not just hardware, it's software. I want to spin up an X stack in docker? Can't do that, docker doesn't work. There's jails but without any image repositories I'm trading a lot of convenience for simplicity.

There's also software like dotnetcore which will just not build. The situation in the desktop is even more problematic. I wish it wasn't so, I like the separation of concerns quite a bit with FreeBSD but it's not something that unfortunately fits my use cases.

GordonS• 6 years ago

I tried to install Dragonfly BSD in a Hyper-V VM recently - didn't matter what configuration I used, the install wouldn't start due to some kind of hardware issue with the virtual disk. Oh well, I'll stick with Linux.

blinkingled• 6 years ago

Btw, DragonFly runs fine under either of ESXi or Linux/KVM/Virtio.

I used it under ESXi with physical disks attached as a backup server with hammer/hammer2 recently. Worked great and it was the only FS that offered effective offline dedup.

segfaultbuserr2• 6 years ago

+1. It's also my recent experience of running FreeBSD on AMD Ryzen, several features are missing. And so far this is a list of problems I've encountered.

1. No ECC driver for AMD Ryzen, and no ECC support in memory management.

While you don't need any OS support to use ECC, it's much better to have it.

* Linux has an ECC kernel driver for AMD CPUs that accurately reports the ECC status, this is extremely helpful given the uncertainty of ECC in consumer-grade hardware. On FreeBSD, it's not possible to tell whether ECC is enabled due to the lack of driver. Also, if ECC is not initialized properly by the firmware, the Linux ECC driver will also detect it and try reenabling ECC and memory scrubbing. On FreeBSD, better to check whether your BIOS is broken.

* When an ECC error occurs, a Machine Check Exception is generated by the CPU. On Linux, it will be correctly decoded and recorded. But on FreeBSD, so far there's no decoder, leaving you a mysterious MCA error in dmesg. For example, a correctable DRAM ECC error will be reported as "L3 cache error" (which made many people to falsely believe that Ryzen's ECC was not working on FreeBSD).

* On Linux, if an unrecoverable multibit ECC error is detected in userspace memory, the process will be killed by a SIGBUS (my username checks out?). If the error occurs in kernel memory, it triggers a kernel panic. On FreeBSD, as far as I know, none of the features is supported by the kernel, it increases the risk of data corruption, and it's not a Ryzen or MCE-specific problem. Also, Linux also supports memory offlining, which can be used to temporarily remove bad memory pages from the system after an ECC error, which is not found in FreeBSD.

Fortunately the ECC-enabled flag is easy to check (I plan to make a contribution to the FreeBSD kernel), and a MCE decoder in userspace should also be easy. But implementing the rest is not trivial, the lack of ECC support in memory management is a problem. It's unfortunately that these features are not supported in a server-grade OS like FreeBSD (I guess FreeBSD runs on "real" servers, which implements all of those ECC features in the management firmware, so "real" FreeBSD users don't really need them...)

2. No USB serial system console and netconsole support. On FreeBSD, although tty login via USB serial is supported (just run a getty on it), it seems that there's no way to redirect all dmesg to a serial port (perhaps someone can correct me), FreeBSD's comconsole requires a real physical serial port, not USB, on the other hand Linux's CONFIG_USB_SERIAL_CONSOLE supports USB natively. On Linux, there's also a kernel-space netconsole that redirects all demsg via UDP/IP, this feature is not found in FreeBSD although there was an attempt in 2012.

toast02• 6 years ago

I ran thousands of FreeBSD servers, with ECC, and the memory management layer features would have been nice, but unrecoverable failures were rare enough that it wasn't a big deal; anyway our application ran as a single OS process using almost all the ram, so 95% chance the faulty address was OS or our application. Offlining would have been nice though; had a couple faulty addresses that were busy, so all the MCE interrupts made the system really slow, and caused a ton of application congestion.

For USB serial console, I think part of the issue there is that the serial console can interface with the kernel debugger, which might be tricky if it's USB (but I guess USB keyboards probably work in the kernel debugger, so maybe there's a chance?).

Thanks for working on Ryzen ECC. I don't work with a server farm anymore, and I'm too cheap to buy ECC for home use, but someday I might use that support.

adrian_b3• 6 years ago

Yes, unfortunately FreeBSD has much better support for Intel CPUs and for Intel networking, than for alternatives.

On servers with Intel CPUs, FreeBSD warned me promptly, by e-mail, about some corrected ECC errors.

The errors appeared suddenly after many years of use and they kept recurring, pointing to a probable failure in the near future, but being promptly notified, I have replaced the offending DIMM and all went back to normal.

So yes, you are right, for FreeBSD it is better to stick to Intel, unless you have time to change yourself the sources, to add the missing hardware support, which is somewhat easier than attempting to make changes in the Linux kernel.

There are also examples of hardware for which FreeBSD has better support than Linux, but those belong to classes of hardware less likely to be encountered by non-professional users.

For example FreeBSD has better support for magnetic tapes.

stevenhuang• 6 years ago

I hear about the elegance of BSD design often but have only worked deeply with Linux.

Does anyone have some good LWN-type articles that goes deep into the differences between BSD vs Linux internels (also common user land traits in downstream distros)?

rwaksmunski4• 6 years ago

My favorite comparison is epoll vs kqueue.

https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-...

https://people.freebsd.org/~jlemon/papers/kqueue.pdf

markjdb• 6 years ago

as many of these tests show

The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.

rwaksmunski4• 6 years ago

According to the benchmarks when using the same compiler (LLVM) and the same file system (OpenZFS) FreeBSD performance is 98% of Linux performance. 2% performance penalty is a bargain in exchange for Dtrace, kqueue, pf, jails, ports, outstanding documentation, simplicity and cohesiveness of a FreeBSD system.

toast02• 6 years ago

Looking through the benchmarks, there's a huge variation here. For some tests, FreeBSD was much faster, and for some it was much slower.

So, it depends on what you're doing. A lot of the tests where FreeBSD was much slower were media related; it makes me wonder if some CPU acceleration didn't get enabled; which could be FreeBSD (or Clang) missing a feature, or a benchmark issue or something else.

rwaksmunski4• 6 years ago

For media encoding you are essentially benchmarking the compiler. Sometimes makefiles force -O2 on BSDs vs -O3 on Linux, which should explain performance differences when using the same compiler.

Running BSDs on AMD Ryzen 5000 Series – FreeBSD/Linux Benchmarks

Related Stories