Originally posted by BSDude
View Post
Announcement
Collapse
No announcement yet.
Facebook Is Hiring To Make Linux Networking Better Than FreeBSD
Collapse
X
-
It's true
FreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.
Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).
kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.
epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.
This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.
Comment
-
Originally posted by kaprikawn View PostGenuine question, what's so good about BSDs network stack (i.e. what makes it so superior to Linux)?
If you compared Linux to FreeBSD at the time, Linux just didn't match up, and those comparisons are no doubt still in the back of people's minds. As they say, you only get one chance to make a first impression.
Since then, Linux has steadily gained features, performance and stability, taken over the data center, the super-computing world, and mobile devices. But if there are pieces of the FreeBSD network stack where they still have a better algorithm, then IMHO there's no shame in leveraging their knowledge.
- Likes 1
Comment
-
Originally posted by Almindor View PostFreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.
Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).
kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.
epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.
This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.
This article seems to back up your argument, though I only skimmed it: http://www.eecs.berkeley.edu/~sangji...vs-kqueue.html
I'm a Linux fanboy, but I'll take any branch of open source software over proprietary any day. So as long as Windows or QNX or HP-UX or something else proprietary do not start winning the server wars, I'm satisfied.
Comment
-
Originally posted by Almindor View PostFreeBSD is better on the network stack. I should know since I coded a networking library to use the best possible non-blocking mechanism on various OSes.
Just for a specific comparison, freeBSD has kQueue where Linux has epoll mechanism. Both are replacements for the ancient select call which is extremely inefficient when there's a huge amount of connections (see C10k problem).
kQueue is very smart in how it reports events happening on sockets and gives you the full list of "read" and "write" events in one go. That means one syscall/gateway per report batch in a scheduled slice.
epoll on the other hand can only report reads or writes in one syscall/gateway. The way to have "one" event reporting point with epoll is to epoll two epolls on top one for reads one for writes, which means it can go up to 3 syscalls. That IS 3x slower on linux, I have tested this.
This is just one part of the problem, I'm guessing they have other, deeper issues. I think it'd help if fanboys who know nothing of the systems stopped being so defensive.
If in fact you are correct, which I don't know, then why not just imitate what FreeBSD does? How much better can it get anyway?
Comment
-
Originally posted by MartinN View PostWho has done benchmarking that would demonstrate the overall (performance) impact under high load of what you just said here? I'd be interested in seeing it.
If in fact you are correct, which I don't know, then why not just imitate what FreeBSD does? How much better can it get anyway?
So every syscall you can avoid can get you quite a performance boost. This can impact actual throughput since it's the kernel that does the buffering, but your app has to keep up with it for it to continue at max speed.
Comment
-
Originally posted by MartinN View PostWho has done benchmarking that would demonstrate the overall (performance) impact under high load of what you just said here? I'd be interested in seeing it.
If in fact you are correct, which I don't know, then why not just imitate what FreeBSD does? How much better can it get anyway?
Anybody can fake an infographic, but if this is accurate then it's significant: http://daemonforums.org/showthread.php?t=2124
I assume Facebook is specifically trying to hire people to add kqueue or something almost identical to kqueue to the Linux kernel.
- Likes 1
Comment
-
Originally posted by Michael_S View PostIf you read the article I linked, it states that the Linux kernel epoll supports one update per call. If 100 sockets get new data, then you have to call epoll 100 times to get all of the sockets that need the next read or write. For kqueue, your system can be informed of all 100 sockets that are ready for the next read or write from one kqueue call.
Anybody can fake an infographic, but if this is accurate then it's significant: http://daemonforums.org/showthread.php?t=2124
I assume Facebook is specifically trying to hire people to add kqueue or something almost identical to kqueue to the Linux kernel.
thanks for the link. totally overlooked it.
Comment
Comment