I recently did some testing of the BBR congestion control algorithm. We currently license Aspera to speed up downloads for our users, it is a ridiculously expensive solution. (6 figure $ for only 3 years). Aspera uses UDP and its own congestion control algorithms to better utilize the network. We will be dropping Aspera and implementing BBR on our download servers when our Aspera license is up.
BBR is a game changer and any system without it will be considered a non-solution for anything that is serving data on the web in the future. BBR is BSD licensed so it will make it into production Linux and Windows servers pretty easily. If it's not on the radar of anyone working on Illumos in the near future it should be. Without it, Illumos will lose its competitiveness. Here are some tests I did between St.Louis, Missouri, EC2 in Virginia and EC2 in Sidney, Australia. Keep in mind the system tested with has a 10Gb/s connection to the internet and addition downloads going on at around 2 Gb/s total. * From EC2 in Virginia to St. Louis, kernel 4.4 with CUBIC algorithm, 1 GB file scp - 190 Mb/s rsync - 150 Mb/s ascp - 518 Mb/s (Aspera client) After update to kernel 4.9 and enable BBR: scp - 390 Mb/s rsync - 436 Mb/s ascp - 400 Mb/s * From EC2 in Sydney to St. Louis, kernel 4.4 with CUBIC algorithm, 1 GB file scp - 64 Mb/s rsync - 68 Mb/s ascp - 220 Mb/s After update to 4.10-rc1 and enable BBR scp - 76 Mb/s rsync - 76 Mb/s ascp - 220 Mb/s 3 parallel streams scp - 188 Mb/s ascp - 192 Mb/s 5 parallel streams scp - 312 Mb/s ascp - 188 Mb/s 8 parallel streams scp - 302 Mb/s ascp - 192 Mb/s -Chip On Thu, Dec 22, 2016 at 9:58 AM, Dan McDonald <[email protected]> wrote: > > > On Dec 22, 2016, at 8:05 AM, G B via smartos-discuss < > [email protected]> wrote: > > > > From what I've read, Google's BBR congestion control algorithm will be > in the Linux 4.9 kernel and FreeBSD has it slated for later (possibly 11 > Stable or 12 Current). Will this be making it into illumos and what would > be the timeline? > > The optimal approach to this is to get TCP to accept pluggable congestion > algorithms. This was in-progress at Snoracle prior to the > barn-door-closing of 2010. After that, putting in new ones SHOULD be > straightforward. > > People who could work on this are likely swamped with other things > currently. I imagine pluggable algorithms would be a months-long project, > especially given the testing involved (you REALLY don't want to break TCP, > or worse, have it become a bad congestion citizen). After that, a specific > replacement would be fewer months than the original setup. > > Sorry I can't be of more immediate assistance, > Dan > ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
