There is no current BBR stack for Windows that I am aware of without getting into userland transports. Windows' default congestion control is either a hybrid called Compound TCP that should do better than traditional loss-based CC in environments where they fall down or CUBIC depending on version, however this sounds like a nearly perfect situation of server-class hardware on each end (realistically no need to bound send/receive windows) on a terrestrial line (close to zero channel loss). The sender side TCP stack and congestion control will dictate the performance in this scenario for any reasonably modern receiver stack of the past 20 years.
Make sure you have datacenter-class switches on each side so you aren't dropping packets on the floor on the easy part of the journey, crank the send and receive buffers way up to match the BDP, and try switching between Windows CTCP and CUBIC for a comparison, enabling more aggressive window scaling (https://blogs.technet.microsoft.com/netgeeks/2018/05/21/a-word-about-autotuninglevel-tcp-receive-auto-tuning-level-explained/) Regards, Kevin On Mon, Sep 17, 2018 at 2:11 PM 'Carl Mastrangelo' via mechanical-sympathy <[email protected]> wrote: > > +1 to BBR. Reports I have seen shows it maintains a much higher throughput > in lossy environments. It should easy to turn on in a recent kernel. > > https://reproducingnetworkresearch.wordpress.com/2017/06/05/rebbr/ > > On Thursday, September 13, 2018 at 10:04:54 AM UTC-7, Todd L. Montgomery > wrote: >> >> Hi Jay. >> >> Going to assume Robocopy uses TCP.... >> >> As you had no real issues with things without a WAN, I would assume the TCP >> window sizes, etc. are all good for the rates you need. >> >> Latency will play a role, but more likely loss is a more impactful factor as >> congestion control will be more of a throttle than flow control. With TCP >> (low loss rate), RTT scales linearly with throughput. Well, as RTT goes up, >> throughput goes down, but it is linear. With loss, even low loss, throughput >> scales with sqrt(loss rate). After about 5%, TCP-Reno goes into >> stop-and-wait. 1 MSS per RTT. This scale is non-linear and in the < 5% loss >> rate area is really painful on throughput. >> >> In short, WANs will slow down with loss quite a lot. Latency will also have >> an impact, though. Just not as much potential. >> >> Running multiple TCP connections over the same path will mean that they will >> fight with one another via congestion control trying to find a fairness >> point that jumps around and can end up underutilizing the bandwidth at >> times. This is where things like TCP BBR can be helpful. But still, loss >> will cause quite a slow down. >> >> What can you do? Well, it depends on what your links between the areas >> actually are..... terrestrial vs. satellite, etc. Lots of options. >> >> On Thu, Sep 13, 2018 at 9:41 AM Jay Askren <[email protected]> wrote: >>> >>> We need to push 40 TB of images per day from our scanning department in >>> Utah to our storage servers in Virginia and then we download about 4 TB of >>> processed images per day back to Utah. In our previous process we had no >>> problem getting the throughput we needed by using Robocopy which comes with >>> Windows, but our old storage servers were here in Utah. We can get >>> Robocopy to work across the WAN but we have to run 3 or 4 Robocopy >>> processes under different Windows users which is somewhat fragile and feels >>> like a bad hack. The files here in Utah are on a Windows server because of >>> the proprietary software needed to run the scanner. All of our servers in >>> Virginia run Centos. >>> >>> Any thoughts on how to transfer files over long distance and still get high >>> throughput? I believe the issue we are running into is high latency. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "mechanical-sympathy" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
