Most the performance will be dictated by the sender side. As others have said make sure the send buffer and reccive buffer are large enough for the BDP.
You can try experimenting with CUBIC: https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/ Multiplatform makes this a bit more challenging so If you really need it to work optimally you might want to get a copy of something like Aspera. On Thu, Sep 13, 2018 at 1:15 PM Jay Askren <[email protected]> wrote: > Correct, robocopy uses TCP. We have a 10 Gbps terrestrial line and are > working on getting a second line for redundancy. > > > > On Thursday, September 13, 2018 at 11:04:54 AM UTC-6, 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.
