There are a number of points on the file copying. I have been troubleshooting a VPN for a customer who insists that the remote office should "be able to work in exactly the same way as though they are in the main office". Never mind that the VPN bandwidth (before contention) is 256k v 100M i.e 1/400th!
The real problem in this situation is XP Pro to Windows 2003 server (SBS 2003). Copying a few megabytes of files usually fails, but is mostly fine using FTP (before a Windows server security patch stopped the FTP server authenticating correctly).
So I did a lot of digging around. File copy on Windows is actually built on top of SMB (Server Messaging Block) and this appears to have a keep-alive that must happen in a 1 second window after 32 seconds i.e. betweem 32 and 33 second intervals. Of course, latency goes up as the bandwidth can no longer handle these files, and as the latency climbs, guess what - the keep-alive is missed and Windows Explorer believes that it has lost the networked disk drive.
What does it do then? Well, it starts scanning to see what disks it has, and rebuilds the directory structure, thus adding to the traffic that caused the problem in the first place.
There are special expensive hardware boxes you can buy that fake the keep-alives to allow files structures across higher latency networks, but most of us are not in that league.
Does this relate to the Vista problem?
1) Vista uses an IPv6 native TCP stack (IPv6 is an option to install on XP and 2003)
2) How integrated are the local and remote file operations? Where does the system determine that it is local rather than over the network? If this is done at a lower level, then is SMB effectively being used even for local file operations?
If there is any level of integration, then the change to IPv6 may have something to do with the problem.
3) I had a customer where I build them a really fast machine; worked a treat, network and all. Then they sent it back, complaining it was real slow. But it wasn't - they had put a poor wireless USB stick into it with not the correct version of the drivers. Take this out, and the performance was back.
Is it possible to test some of this?
One test is to try disabling your network - safe mode would be the best - and see if the copy is fast then.
My own suspicion is that the generation of all the extra metadata is slowing the system down, and thus causing timing problems within the file operations, and the integration of local and network file operations is then compounding the problem.
This may be a wild guess, but is probably more productive than slagging Vista off. I suppose it depends if you want a solution.
By the way, anyone loving old systems - try running them under Virtual PC or Virtual server - they may be fast, but I had great difficulty trying to remember how to actually use Windows 3, and it was the only OS that gave me problems under Virtual server.
Slashdot Mirror
There are a number of points on the file copying. I have been troubleshooting a VPN for a customer who insists that the remote office should "be able to work in exactly the same way as though they are in the main office". Never mind that the VPN bandwidth (before contention) is 256k v 100M i.e 1/400th!
The real problem in this situation is XP Pro to Windows 2003 server (SBS 2003). Copying a few megabytes of files usually fails, but is mostly fine using FTP (before a Windows server security patch stopped the FTP server authenticating correctly).
So I did a lot of digging around. File copy on Windows is actually built on top of SMB (Server Messaging Block) and this appears to have a keep-alive that must happen in a 1 second window after 32 seconds i.e. betweem 32 and 33 second intervals. Of course, latency goes up as the bandwidth can no longer handle these files, and as the latency climbs, guess what - the keep-alive is missed and Windows Explorer believes that it has lost the networked disk drive.
What does it do then? Well, it starts scanning to see what disks it has, and rebuilds the directory structure, thus adding to the traffic that caused the problem in the first place.
There are special expensive hardware boxes you can buy that fake the keep-alives to allow files structures across higher latency networks, but most of us are not in that league.
Does this relate to the Vista problem?
1) Vista uses an IPv6 native TCP stack (IPv6 is an option to install on XP and 2003)
2) How integrated are the local and remote file operations? Where does the system determine that it is local rather than over the network? If this is done at a lower level, then is SMB effectively being used even for local file operations?
If there is any level of integration, then the change to IPv6 may have something to do with the problem.
3) I had a customer where I build them a really fast machine; worked a treat, network and all. Then they sent it back, complaining it was real slow. But it wasn't - they had put a poor wireless USB stick into it with not the correct version of the drivers. Take this out, and the performance was back.
Is it possible to test some of this?
One test is to try disabling your network - safe mode would be the best - and see if the copy is fast then.
My own suspicion is that the generation of all the extra metadata is slowing the system down, and thus causing timing problems within the file operations, and the integration of local and network file operations is then compounding the problem.
This may be a wild guess, but is probably more productive than slagging Vista off. I suppose it depends if you want a solution.
By the way, anyone loving old systems - try running them under Virtual PC or Virtual server - they may be fast, but I had great difficulty trying to remember how to actually use Windows 3, and it was the only OS that gave me problems under Virtual server.