Issue Summary:
High latency experienced on LAN when running a Storage Migration Service job -- copy share data from one DC to another. Latency drops considerably when using a simple robo script.
Detail:
Traditionally, I've used robo scripts, which works like a charm. I have been testing Windows Admin Center on a Hyper-V VM running 2019 Server OS. In particular, I've been focusing on Storage Migration Service.
Environment:
DC-02: Windows Server 2019 with SMS installed.
WAC (Windows Admin Center VM): 2019 OS with WAC installed and running.
DC-01: 2008 R2 with all company shares.
The transfer that runs via SMS from DC-01 --> DC-02 brings the LAN to a crawl. Conversely, when I run a robo of all directories, there is largely no impact. I ran a few persistent pings to add color.
The following test shows a clear distinction between no SMS job running v. a job running:
Pinging servername.local [IP] with 32 bytes of data:
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=13ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time=6ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=3ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=132ms TTL=128
Reply from IP: bytes=32 time=210ms TTL=128
Reply from IP: bytes=32 time=214ms TTL=128
Request timed out.
Reply from IP: bytes=32 time=191ms TTL=128
Reply from IP: bytes=32 time=239ms TTL=128
Reply from IP: bytes=32 time=11ms TTL=128
Reply from IP: bytes=32 time=206ms TTL=128
Reply from IP: bytes=32 time=208ms TTL=128
Reply from IP: bytes=32 time=192ms TTL=128
Reply from IP: bytes=32 time=214ms TTL=128
Reply from IP: bytes=32 time=211ms TTL=128
Reply from IP: bytes=32 time=209ms TTL=128
Reply from IP: bytes=32 time=213ms TTL=128
Reply from IP: bytes=32 time=210ms TTL=128
Reply from IP: bytes=32 time=228ms TTL=128
Reply from IP: bytes=32 time=224ms TTL=128
Reply from IP: bytes=32 time=138ms TTL=128
Reply from IP: bytes=32 time=217ms TTL=128
Reply from IP: bytes=32 time=225ms TTL=128
Reply from IP: bytes=32 time=194ms TTL=128
Reply from IP: bytes=32 time=169ms TTL=128
Reply from IP: bytes=32 time=226ms TTL=128
Reply from IP: bytes=32 time=223ms TTL=128
Reply from IP: bytes=32 time=255ms TTL=128
Reply from IP: bytes=32 time=203ms TTL=128
Reply from IP: bytes=32 time=215ms TTL=128
Reply from IP: bytes=32 time=229ms TTL=128
Reply from IP: bytes=32 time=224ms TTL=128
Reply from IP: bytes=32 time=208ms TTL=128
Reply from IP: bytes=32 time=91ms TTL=128
Reply from IP: bytes=32 time=193ms TTL=128
Not shown in the above is latency later reaching 800ms+. Condensed the results.
The following shows the difference between a robo job running v. a job not running:
Pinging servername.local [IP] with 32 bytes of data:
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=2ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=8ms TTL=128
Reply from IP: bytes=32 time=74ms TTL=128
Reply from IP: bytes=32 time=9ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=19ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=11ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=4ms TTL=128
Reply from IP: bytes=32 time=96ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=104ms TTL=128
Reply from IP: bytes=32 time=37ms TTL=128
Reply from IP: bytes=32 time=40ms TTL=128
Reply from IP: bytes=32 time=23ms TTL=128
Reply from IP: bytes=32 time=6ms TTL=128
Reply from IP: bytes=32 time=7ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=17ms TTL=128
Reply from IP: bytes=32 time=48ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time=1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=55ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time<1ms TTL=128
Reply from IP: bytes=32 time=27ms TTL=128
Reply from IP: bytes=32 time=28ms TTL=128
Reply from IP: bytes=32 time=13ms TTL=128
There are not any obvious indicators as to what may be causing the problem. I've read through their KB and relevant hundred plus page documentation. I am in need of a second pair of eyes.
Any thoughts? I prefer Robo, but if SMS goes beyond file migration, which they say it will, it would be nice to use it without bringing everything to a halt.
