alt Hacker NewsRan a FreeBSD colocated server for about a decade that went through generations of hardware. I really want to like the OS, except it's most touted feature, the network stack, was consistently unreliable for me using Intel NICs on Supermicro servers. They would go offline usually after some load due to mbuf resource exhaustion. I never got to the bottom of it even though I posted to the bugs database and would diligently follow up and perform experiments. This also happened on different incarnations of server hardware, so it wasn't the same physical NIC having the issue, but different varieties.
Anyways had enough of the random downtime, I just switched to Linux which didn't have these issues.
I'd say the best part of FreeBSD though is freebsd-update which was a game changer from the previous make world shenanigans.
Replies
I do not believe that your problems are typical for FreeBSD servers.
I have been using FreeBSD servers for around 30 years. Most of them had Intel NICs and I have used at least 5 or 6 different kinds of Supermicro motherboards, both with Xeon and with Epyc.
Most servers have worked 24/7, without being rebooted for years and without having any minute of downtime except when I did some hardware upgrade or kernel upgrade.
I do not doubt that you had the problems described, but there must be some very unusual circumstances that have caused this. I would not be surprised if there was some problem with the version of Supermicro BIOS of your motherboards, and not with FreeBSD, because I have seen many bugs in Supermicro firmware. Or perhaps you had some buggy version of Intel NICs.
There is one advantage of Linux over FreeBSD, which is not widely known. Linux has a huge database of known bugs in various peripheral devices, including Ethernet NICs, and when one of those is recognized it applies workarounds for the bugs.
Like any other operating system, FreeBSD also implements workarounds for peripheral interfaces with known bugs, but because it has a much smaller user base also its database of bugs includes much fewer bugs, typically only those that had been reported by FreeBSD users. Because of this, I have seen cases when some hardware devices did not work well in FreeBSD, while they worked well in Linux, and the reason was always because Linux knew that they must not be used in the standard way, but it applied the corresponding workaround for their bugs.
Only Windows is shielded from the problems caused by bugs, because the hardware vendors write themselves the Windows device drivers and include in them any required workarounds for their bugs.
I colocate all my servers that all run FreeBSD.
Myself has been through generational hardware, and had had zero issues with any apart from when the raid card failed.
Network has been solid. ZFS has just worked. Not sure what your issues were however colocating since FreeBSD 8, and now colocating 16-CURRENT on my the server. FreeBSD has been rock stable in my books.
2x Dell R630 and 1x Cisco U220 M5
doublerabbit@cookie:~ $ uname -a && uptime
FreeBSD cookie.server 12.2-BETA1 FreeBSD 12.2-BETA1 r365618 GENERIC amd64
10:39PM up 1752 days, 1:31, 1 user, load averages: 0.64, 1.30, 1.31
Intel has had a somewhat awkward relationship with FreeBSD forever. While they are forced to support it (for $reasons) they never have properly covered it.
I would say as of FreeBSD 12-13 most major issues are addressed from 1gig up to current 100g. There is an odd bug in 2.5g igc where some users have interface stalls whilst others like Netgate are shipping large numbers without issue, waiting to hear if this is firmware or not.
Source: I maintain several of the Intel drivers on a volunteer basis and used to send several Tbit/s to the Internet over them professionally.