ROBOCOPY IPG setting

[edavid3001]

I am attempting to script downloads of files to various remote
locations using ROBOCOPY and /IPG: setting.

When I run a batch files with /IPG:9000, the 128k links do not even
show my traffic.

However, when I run this at the clients, the pipe fills up to 128k and
stays that way. I believe this to be /IPG:9000 over 10 clients
results in delays of 9 seconds, which means 100% utilization.

I have even tried /IPG:239000 -- but it still hits at 100% utilization
on these pipes when I have many clients trying to download.

My question is, is there a maximum value to /IPG: ? I am not finding
much information on this.


Edwin Davidson



(I have many remote locations, some with 1 or 2 stations, some with 10
or 20. I am using client side software to automate patch
installation, and don't want to get into funky IF IP == 192.168.220.20
and subnet == 255.255.255.240 then copy from 192.168.220.21, if failure
try .22... type programming.)

 

[edavid3001]

To answer my own question, IPG: sends 64kilobyte's, then delays.

64 kilobytes is 512kilobits (524288 bits.)

This means that my 128kilobit pipe with 12 clients downloading at the
same time will download for ((512k*12)/128k) 48 seconds, pause for IPG
ms (9000 is 9 seconds) then all download again.

This means latency related items such as Client Access TN5250 (telnet)
or Citrix will be slow for 48 seconds, then fast for 9, then slow.
More likely, these downloads will fire off at different times,
resulting in the pipe being 100% utilized. Even with 2 minute delays
between packets, I will have 4 second periods of slowness (512/128)
using robocopy.

So while Robocopy makes the MRTG graphs look nice, it doesn't work on
latency applications. It's a killer for video games too Looking
at WGET,. It has the same issues, but more along 1.5kbytes versus
64kbytes. Even when throttled to 1B, the http server sends a full
packet (burst) to the client. The client simply reads through this
packet slower. Resulting in bursts every time the buffer emptys. Also
resulting in additional ACK's and keepalives. But those are much less
bandwidth intensive than RPC is.


Posted in the hopes this helps someone else.

Packeteer seems like the real solution here.