Announcement

Collapse
No announcement yet.

Facebook Is Hiring To Make Linux Networking Better Than FreeBSD

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by BSDude View Post
    Gets hired to improve the Linux network stack, ends up migrating all servers to FreeBSD
    Side effect: FB would no longer need to work on btrfs because FreeBSD has great ZFS support out of the box.

    Comment


    • #12
      Originally posted by Awesomeness View Post
      Side effect: FB would no longer need to work on btrfs because FreeBSD has great ZFS support out of the box.
      They can contribute here: http://zfsonlinux.org

      Comment


      • #13
        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


        • #14
          Originally posted by kaprikawn View Post
          Genuine question, what's so good about BSDs network stack (i.e. what makes it so superior to Linux)?
          Back in the early '90s I worked at University of California, and had a lot of hands on with FreeBSD, NetBSD and Linux. At that time, the BSDs were like well oiled machines, firing on all cylinders, and Linux was pretty rough around the edges. But I remember thinking, even at the time, that there was just the faintest hint of a musty smell around the old BSDs, and Linux, though rough in comparison, was profoundly vital, growing and pulsing with life and possibility.

          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.

          Comment


          • #15
            Originally posted by Almindor View Post
            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.
            This is the internet, man. Tribalism always trumps logic.

            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


            • #16
              But I thought..

              I thought BSD and Facebook were dead?

              Comment


              • #17
                Originally posted by Almindor View Post
                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.
                Who 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?

                Comment


                • #18
                  Originally posted by MartinN View Post
                  Who 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?
                  Linux could copy kQueue I think there shouldn't be major obstacles to it. The reason why it makes so much difference is that each syscall/gateway (program waiting for kernel response) is 10-100x slower than your typical function call. It gets even slower when the system is busy because of network transfers for example.

                  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


                  • #19
                    Originally posted by MartinN View Post
                    Who 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?
                    If 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.

                    Comment


                    • #20
                      Originally posted by Michael_S View Post
                      If 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

                      Working...
                      X