4 ms·

With this scale of attack the Linux kernel is not enough for us. We must work around it. ...Or you could just use an operating system substrate based on illumo

by Annatar 10y ago

With this scale of attack the Linux kernel is not enough for us. We must work around it. ...Or you could just use an operating system substrate based on illumos which utilizes the FireEngine, like for instance SmartOS, instead of having to invent workarounds or use one's own TCP/IP stack implementations: http://www.baylisa.org/library/slides/2005/august2005.pdf http://www.baylisa.org/library/slides/2005/august2005.pdf https://sunaytripathi.wordpress.com/2010/03/25/solaris-10-networking-the-magic-revealed/ https://sunaytripathi.wordpress.com/2010/03/25/solaris-10-ne... this technology has been available for over ten years now; designed from the ground up to scale across multiple hardware threads for high performance, by the experts in the problem domain.

quitspamming 10y ago
Quit spamming about stupid SmartOS, you try to shoehorn it in to every topic. You're like a Mormon Missionary for SmartOS and it is super annoying.
- oddsignals 10y ago
  I found his comment relevant and interesting enough, and judging by his posting history SmartOS is far from the only thing he comments about. It certainly added more to the discussion than yours did.
  - cyphar 10y ago
    An incredibly large percentage of Annatar's posting history is a misunderstanding of something about GNU/Linux, followed by a pitch about SmartOS. It's not the only thing they talk a out, but it's the only posts that stick in my mind. While I find the history of free operating systems fascinating, it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain".
    - Annatar 10y ago
      Misunderstanding? I develop on Linux day in and day out. Care to qualify that assertion? it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain". As one of the principal kernel engineers of the FireEngine, yeah I think Sunay is the expert in the problem domain, having invented parallel enqueuing or what he terms "fanout", and Radia Perlman, who I believe collaborated with him on it invented the spanning tree protocol. If that doesn't make them the subject matter experts in the TCP/IP stack domain, then I have nothing more to add. And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago. Solaris had large enterprises as paying customers throughout the nineties of the past century, and those customers both demanded and paid huge sums of money to have these types of problems solved, so in some cases illumos has up to 25 years of a headstart, and by the time GNU/Linux catches up, illumos will already be ahead, as the development is not standing still and it has professional kernel engineers working on the code base.
      - cyphar 10y ago
        > Care to qualify that assertion? The most recent example I can think of is you posting about containers on GNU/Linux[1], claiming that they were implemented primarily using cgroups (and that the main purpose was resource restrictions). That is not true, and hasn't been true for a long time (if ever). Yes, the very first upstream "container" primitive was cgroups -- but that was very quickly replaced with namespaces and cgroups took on the resource restriction role. What most people call "containers" was always about virtualization (ie isolation), and the isolation primitive in the Linux kernel is namespaces. There are almost certainly more examples, but I don't feel like going through any more of your comment history at the moment. > And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago. Believe it or not, but constraints have changed in the past 20 years. I'm not saying that illumos doesn't have awesome technology (it does), but it is not a panacea. I get it, you're an advocate for alternative free operating systems. Good for you. Solaris does have a 25 year headstart -- on solving problems 25 years old. Modern computing has many more problems that weren't even concieved 25 years ago (cloud and distributed computing being the main ones, as well as embedded devices which is something that Solaris can't put a candle to GNU/Linux on). So it's very dismissive to claim that Solaris has solved all problems that may face GNU/Linux. Both operating systems have problems they need to fix. > and it has professional kernel engineers working on the code base So does Linux, I'm missing your point here. [1] https://news.ycombinator.com/item?id=11944847 https://news.ycombinator.com/item?id=11944847
- Annatar 10y ago
  No, I'm just sick and tired of Linux and want my favorite OS to finally hit the mainstream, so there would be some job opportunities. (Linux became popular the same way, for those of you with a short memory.) Now that Linux is finally hitting scale, people are getting busted by the shoddy programming, hence discussions about in- or out of kernel TCP/IP stack, which is preposterous, since the OS is supposed to provide an interface to the hardware. And I make no apologies for being a SmartOS advocate, just to set the record straight.
DblPlusUngood 10y ago
It would be great if you could provide specific reasons why FireEngine is able to avoid the overheads which other projects avoid via kernel bypass.
- Annatar 10y ago
  The main reason being that the packets are put into queues bound to hardware threads (VCPU's), which the illumos kernel treats as processors. Sunay, the principal author of the FireEngine explains it in detail in the second link I cited. Long story short, on illumos based systems network performance scales linearly with available processors, and on systems where the NIC's PHY would be faster, a kernel tunable, ip_squeue_fanout (edittable via /etc/system), enables one to change the packet processing methodology. One of the techniques which enable the FireEngine to provide high network performance is eschewing mutex locks in favor of multiple parallel queues and parallel queue drainage. Should I also explain how mutex locks function, and why they are detrimental to performance as opposed to enqueueing?
  - wmf 10y ago
    This sounds pretty similar to RSS/RPS/RFS in Linux. Granted, that functionality was added more recently and may have even been inspired/copied from Solaris for all I know, but the past is a sunk cost. None of your "back in the day" comments convince me that Solaris today has any advantages over Linux today.

by Annatar 10y ago

quitspamming 10y ago

Quit spamming about stupid SmartOS, you try to shoehorn it in to every topic. You're like a Mormon Missionary for SmartOS and it is super annoying.

oddsignals 10y ago
I found his comment relevant and interesting enough, and judging by his posting history SmartOS is far from the only thing he comments about. It certainly added more to the discussion than yours did.
- cyphar 10y ago
  An incredibly large percentage of Annatar's posting history is a misunderstanding of something about GNU/Linux, followed by a pitch about SmartOS. It's not the only thing they talk a out, but it's the only posts that stick in my mind. While I find the history of free operating systems fascinating, it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain".
  - Annatar 10y ago
    Misunderstanding? I develop on Linux day in and day out. Care to qualify that assertion? it's quite dismissive to pretend that all possible problems that GNU/Linux faces today were solved "10+ years ago by experts in the problem domain". As one of the principal kernel engineers of the FireEngine, yeah I think Sunay is the expert in the problem domain, having invented parallel enqueuing or what he terms "fanout", and Radia Perlman, who I believe collaborated with him on it invented the spanning tree protocol. If that doesn't make them the subject matter experts in the TCP/IP stack domain, then I have nothing more to add. And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago. Solaris had large enterprises as paying customers throughout the nineties of the past century, and those customers both demanded and paid huge sums of money to have these types of problems solved, so in some cases illumos has up to 25 years of a headstart, and by the time GNU/Linux catches up, illumos will already be ahead, as the development is not standing still and it has professional kernel engineers working on the code base.
    - cyphar 10y ago
      > Care to qualify that assertion? The most recent example I can think of is you posting about containers on GNU/Linux[1], claiming that they were implemented primarily using cgroups (and that the main purpose was resource restrictions). That is not true, and hasn't been true for a long time (if ever). Yes, the very first upstream "container" primitive was cgroups -- but that was very quickly replaced with namespaces and cgroups took on the resource restriction role. What most people call "containers" was always about virtualization (ie isolation), and the isolation primitive in the Linux kernel is namespaces. There are almost certainly more examples, but I don't feel like going through any more of your comment history at the moment. > And yes, some or the problems GNU/Linux is hitting today have been solved on Solaris more than ten, others more than twenty years ago. Believe it or not, but constraints have changed in the past 20 years. I'm not saying that illumos doesn't have awesome technology (it does), but it is not a panacea. I get it, you're an advocate for alternative free operating systems. Good for you. Solaris does have a 25 year headstart -- on solving problems 25 years old. Modern computing has many more problems that weren't even concieved 25 years ago (cloud and distributed computing being the main ones, as well as embedded devices which is something that Solaris can't put a candle to GNU/Linux on). So it's very dismissive to claim that Solaris has solved all problems that may face GNU/Linux. Both operating systems have problems they need to fix. > and it has professional kernel engineers working on the code base So does Linux, I'm missing your point here. [1] https://news.ycombinator.com/item?id=11944847 https://news.ycombinator.com/item?id=11944847
Annatar 10y ago
No, I'm just sick and tired of Linux and want my favorite OS to finally hit the mainstream, so there would be some job opportunities. (Linux became popular the same way, for those of you with a short memory.) Now that Linux is finally hitting scale, people are getting busted by the shoddy programming, hence discussions about in- or out of kernel TCP/IP stack, which is preposterous, since the OS is supposed to provide an interface to the hardware. And I make no apologies for being a SmartOS advocate, just to set the record straight.

DblPlusUngood 10y ago

It would be great if you could provide specific reasons why FireEngine is able to avoid the overheads which other projects avoid via kernel bypass.

Annatar 10y ago
The main reason being that the packets are put into queues bound to hardware threads (VCPU's), which the illumos kernel treats as processors. Sunay, the principal author of the FireEngine explains it in detail in the second link I cited. Long story short, on illumos based systems network performance scales linearly with available processors, and on systems where the NIC's PHY would be faster, a kernel tunable, ip_squeue_fanout (edittable via /etc/system), enables one to change the packet processing methodology. One of the techniques which enable the FireEngine to provide high network performance is eschewing mutex locks in favor of multiple parallel queues and parallel queue drainage. Should I also explain how mutex locks function, and why they are detrimental to performance as opposed to enqueueing?
- wmf 10y ago
  This sounds pretty similar to RSS/RPS/RFS in Linux. Granted, that functionality was added more recently and may have even been inspired/copied from Solaris for all I know, but the past is a sunk cost. None of your "back in the day" comments convince me that Solaris today has any advantages over Linux today.