Slow network file transfer between Windows 7 and XP

[Saab Dastard]

Has anyone else come across this on their network - file transfer between XP and Win 7 PCs is ridiculously slow?

And more to the point, have they found a cast-iron solution to it?

There have been lots of complaints on various forums, but thus far I haven't come across a real solution - nor even a real explanation as to why it is so bad (apart from knowing that MS re-wrote the TCP/IP stack "from the ground up" for Server 2008 & win7 - go figure!).

Oh, and also why does Win 7 complain about USB storage devices being corrupted when they manifestly are not?

Win 7 seems more and more like "smoke and mirrors" and less about real improvement to me after a I've been working with it for a few months.

SD

[BOAC]

I have no experience with W7 but I recall that when No1 son was running an early version in his company to assess it over XP he was informed that a particular (moderately-sized) file transfer via the server would take '286 days'. I believe this issue was sorted by an OS change, but perhaps you have hit another? Has MS been asked?

[Guest 112233]

Reply to SD

Saab, I suspect the you have already answered your own question - Re the TCP/IP Stack question. I'm not sure if the problem is symetrical ? Have you had the chance to try W7 to W7 or XP to XP transfers: as well as W7 to XP and vi ser versa.

I do not know about your Network Topology. Are the MTU Values optmised ?
Is there an anti Virus checking the packets on either or both PC's.

Have microsoft made changes in W7, re the packet handeling - Re member the brooha over "Raw sockets" as to whether the packet addres data and the packet contents were handeled, is there a bottleneck in the packet protocols.

On a more benign level - I had "Great fun" with a Belkin PC Network Card - In the advanced Network settings in XP - There was a power mizer function and it took several seconds for the card to reach its full data through put.

Just a few snippits fron the totally uninitiated.

CAT III

PS Saab there's an article on the web site of a "Well Known Mag" re the long term performance of W7 64 Bit - Think of a Spherical lump of the Stuff that Bees make.- I have not read it yet but wil do - It might provide some ideas

.

[Spurlash2]

Link HERE.

...and an abstract from the thread below.

Specifically, my problem was that file transfers FROM Windows 7 to XP were slow, measured by seeing network utilization in the Task Manager at about 1%. Transfers from XP to Windows 7 typically used 80-99% of the network bandwidth. These results were achieved whether the transfer was "push" or "pull".

What worked for me: I went to Local Area Network properties, Configure, Advanced Tab, and disabled Large Send Offload v2. The advice to disable autotuning, RSS, set Speed & Duplex to a specific value, remove from homegroup, did nothing. Ultimately, the settings which worked on my Dell XPS 8100 Windows 7 Pro 64-bit workstation were as follows:

ARP Offload - Enable
Ethernet@WireSpeed -Enable
Flow Control - Auto
Interrupt Modulation - Enable
IPv4 Checksum Offload - Rx & Tx Enabled
Large Send Offload (IPv4) - Enable
Large Send Offload v2 (IPv4) - Disable
Large Send Offload v2 (IPv6) - Disable
Network Address - Not present (radio button)
NS Offload - Enable
Priority & VLAN - Priority & VLAN Enabled
Receive Side Scaling - Enable
RSS Queues - RSS 4 Queues
Speed & Duplex - Auto
TCP & UDP Checksum Offload (IPv4) - Rx & Tx Enabled
TCP & UDP Checksum Offload (IPv6) - Rx & Tx Enabled
VLAN ID - 0
Wake Up Capabilities - Both
WOL Speed - Lowest Speed Advertised

Hope this proves helpful to someone else.

[Spurlash2]

The USB thing can sometimes be resolved by removing your computer from its power source completely. So switch off and unplug. Remove all USB devices. Pause several marching paces then boot. It resets the USB controller, apparently.

[Mike-Bracknell]

Originally Posted by CATIII-NDB

I do not know about your Network Topology. Are the MTU Values optmised ?

I really really wish people hadn't been made aware of MTU values, as it gets trotted out so many times when it's not relevant.

FYI, the MTU (or Maximum Transmission Unit) is the maximum size a data packet can be forwarded onwards, and is used when deciding whether to fragment packets into smaller ones or not for transmission over routers etc. XP to 7 in a home environment is 99.99999% likely to be over a single LAN segment where the default will be 1500 bytes.

Much more likely in SD's case is going to be duplex issues, causing runts and shorts (retransmissions) when a NIC set to autonegotiate is unable to negotiate a safe pairing of transmission speeds and duplexing between it and the other end of the RJ45 (i.e. the switch), and ensuring that this was set to a specific value rather than "auto" in the NIC would go a long way towards troubleshooting this issue. The reason for which is that the RFC governing this portion of networking is/was always ambiguous, and so certain manufacturers make kit that negotiates one way, and other manufacturers make kit that negotiates another way, and ne'er the twain shall meet (unless you use gigabit which is ONLY full duplex, which is why it's quite useful!). A clear example of this is when you connect a Netgear switch to a 3com switch or a Broadcom NIC (although in the latter case the interpretation of the RFC is closer and so you get an intermittent slowdown rather than a flat 'no').

Once the above issue is out of the way, the next thing to tackle is the firewall, as that's the next thing sitting in the way of the network packets and their transmission (aside from the network cable itself - but then we assume that SD has that under control already). A quick test of disabling both firewalls and checking speed would enable you to see whether speed was being affected by this component or not.

Finally, the security component of where the file's coming from and going to are to be considered, since the filesystem needs to be able to read the SIDs and gain access to the relevant filestore on the receiving system, but this is unlikely to be the cause of the slowdown (and would only ever manifest itself in a single slowdown at the start or end of the transmission, and not for each file etc).

Hope that helps?

Mike.

[mixture]

Saab Dastard,

Have you checked / played with the chimney settings ?

netsh interface tcp show global

and play with those settings a bit (not forgetting to make a note of original settings).

May or may not work, but I've seen Vista <-> XP issues in the past where tweaking those did the trick.

[Saab Dastard]

I have looked at all the areas that have been suggested, and more. No joy.

XP - XP is fast on my home network - I have yet to try Win7 - Win7. Not sure I want to commit another PC to Win7 until the bugs are out!

Mike - speed and duplex are set to 100/Full on all devices. Interestingly the RFC for gigabit ethernet mandates auto-negotiation at both ends, for a proper implementation - fixing it is allowed, but does not handle errors and exceptions correctly.

Security is not an issue either, as I have (temporarily) disabled AV and any local firewalls for testing.

Homegroups are not involved.

I have tried tweaking every parameter in NIC settings, no effect.

I have also looked at the version of SMB, but that hasn't made any difference either.

Oh well, just have to wait for MS to admit they have a bug (actually several) and fix it.

SD

[Mike-Bracknell]

Originally Posted by Saab Dastard

Mike - speed and duplex are set to 100/Full on all devices. Interestingly the RFC for gigabit ethernet mandates auto-negotiation at both ends, for a proper implementation - fixing it is allowed, but does not handle errors and exceptions correctly.

Yup. What I was trying to say (albeit in my brief style) is that there's no such thing as gigabit-half-duplex, so if you have a gigabit NIC and switch it becomes plug & play (thankfully) versus the pain of trying to find a workable match between 10/half, 10/full, 100/half, 100/full.

Anyway....a question we possibly haven't touched on - exactly HOW slow is slow in this instance?

(and have you sniffed the network to see what's going on?)

[mixture]

Not sure I want to commit another PC to Win7 until the bugs are out!

It's called VMWare and the Windows 7 grace period.

[Saab Dastard]

Anyway....a question we possibly haven't touched on - exactly HOW slow is slow in this instance?

Transferring 9.9 GB data - 19 hours! I abandoned it after about 8 (overnight, less than half complete).

Same transfer XP - XP about 38 minutes (and that's over wifi).

Ridiculous.

I might well have to break out my old Etherpeek probe!

SD

[mixture]

Had a quick speed read back through your posts, can't see you mentioning trying a crossover cable ? (or just straight between two Gb NICs) ?

What NICs are you using ? What switch ?

Happy sniffing !

[Mike-Bracknell]

Wireshark would do for sniffing since it'd be running on the device in question.

Crossover cable's a good idea.

[mixture]

One other thing SB. If you're using the GUI "flying files" copy mode, can you try a robocopy ? (I'd suggest probably with the restartable mode flag and tweaking the retry and wait values).

Not that it's likely to make any difference if there are network issues at play, but it is a more robust mechanism.

[Saab Dastard]

Good idea, Mixture, I'll try various command-line methods of moving files around.

SD