I understand that the live version will inevitably be slower than a local copy. However, considering my system specs and bandwidth, the amount of latency experienced seems far too disproportionate to be attributed to (solely) just that.
My system specs and speed test are as follows:
The lag occurs at all times regardless of network load, and seems to be present for all utilities — even, in fact, just launching explorer.exe to the SysInternals UNC directory alone displays significant load time (and no, system is not under any significant load/stress).
The only thing left I can think of is perhaps the issue stems from server-side, but I don't want to simply make that assumption. Is there any method to definitively determine the root cause (and hopefully implement a corrective/preventative action)?
Best Answer
It has nothing to do with your system specs or bandwidth.
UNC paths do not denote the protocol, so Windows attempts to connect through several protocols it knows. On most systems it uses SMB and WebDAV in that order.1
live.sysinternals.com is a HTTP/WebDAV server and doesn't speak SMB, but worse than that, it doesn't even respond to attempts to make an SMB connection.2 When Windows attempts to connect first on TCP port 445 (modern SMB) and then port 139 (NetBIOS), it doesn't even receive a refusal – it just sits there waiting until the timeout counts down.
Several seconds later, the Windows network client gives up with SMB and attempts WebDAV (over port 80), which succeeds but by now the delay has occured. And if you access the server directly through a UNC path (not a mapped drive letter), this procedure likely repeats for every file operation as Windows doesn't seem to remember the server's type for long and just keeps retrying SMB again.
And there's also the issue that 1) the server may be physically far away from you, adding latency even to successful requests; 2) WebDAV itself is a verbose XML-based protocol with no batching. Both contribute to the total latency.
1 (Historically, when Windows started using UNC paths, there were many LAN protocol suites. A short non-DNS name like
\\mypccould have meant SMB/NetBIOS in no less than three different ways – over IPv4 or IPX or NBFrames – but it could also have been NetWare NCP, or AppleTalk AFP, or possibly VINES and DECnet and other weird stuff.)2 (Actually, even if the server was correctly configured to immediately refuse connections to unsupported ports, there would be another problem: some ISPs block connections to SMB-related ports, to reduce the potential for malware spread.)