Solved! Server 2008 R2 Slow Network Writes

[jim]

I think your packets are arriving out of order, or the server is not sending a packet to let the sender know the data has been recived, the sender then re sends the data. I would try another NIC or different drivers.

Do you have any VLANs?

No, I don't have any.

Thing is though Jay, I've got rubbish transfer speeds from my WHS to my HP N36L, and my PC to my N36L.

Then, apparently, loads of errors (as I just posted about, although it could be normal, it looks pretty horrendous) from my PC to my WHS.

So that would seem to discount any NIC/drivers if all 3 are giving grief.

[spoon_]

What about the switch itself Jim?

[jim]

This is what I'm seeing, desktop to WHS (remember this is working fine at 90MB/s).

Surely this isn't normal?

[jim]

What about the switch itself Jim?

That's what I'm wondering. If someone can confirm that those results for the WHS are way out of line, then I guess it has to be the switch.

It's a Netgear GS605, for what it's worth. EDIT: 2 years old this month apparently.

Does any of this look like a switch on the way out? If I had one I could conveniently swap out, then I would do that and test but that's not the case at the minute.

[pardal51]

snootyjim, what about if you test fiddling with the NIC speed on you Microserver, i.e., 1000F, 1000H, 100F, 100H, etc each time running wireshark

after that you may want to install different drivers and run all tests again.....nice for a BH wknd

Like your sig, like your kit

[Paul Adams]

If the checksum is 0 on all outbound packets, then that is the TCP checksum offloading feature on the NIC - the hardware calculates the checksum just before it hits the wire, but after WinPcap has captured the packet, hence Wireshark sees it as an error.

If you take a simultaneous trace on the other end and match the packets, look if the checksum is zero for incoming packets (I suspect you'll find they are okay).
Alternatively, disable TCP checksum offloading on the NIC and check a new trace.

IME (albeit a few years now since I was in the Networking team in Platforms Support), checksum offloading provides zero improvement for throughput except on incredibly high-end multi-homed servers that have a gigantic sustained load on them - and conversely I have had customers report that services not only work better, but faster too after turning the feature off.

Also, my VMs running inside Hyper-V on W2K8R2 on my home server became incredibly slow to access when the Marvell NIC on the host had the offloading features enabled (but the Realtek NIC had no problems on the same setup, both onboard chipsets).

[jim]

snootyjim, what about if you test fiddling with the NIC speed on you Microserver, i.e., 1000F, 1000H, 100F, 100H, etc each time running wireshark

after that you may want to install different drivers and run all tests again.....nice for a BH wknd

Like your sig, like your kit

I may need to try that, yeah. Regrettably it appears that openfiler doesn't give a lot of options regarding NICs so I will probably need to go back to Windows to properly test that... massive pain in the neck at present because I only have one monitor, one mouse and one keyboard with me!

Definitely need to explore this a bit more, that's for sure. And thanks by the way

If the checksum is 0 on all outbound packets, then that is the TCP checksum offloading feature on the NIC - the hardware calculates the checksum just before it hits the wire, but after WinPcap has captured the packet, hence Wireshark sees it as an error.

If you take a simultaneous trace on the other end and match the packets, look if the checksum is zero for incoming packets (I suspect you'll find they are okay).
Alternatively, disable TCP checksum offloading on the NIC and check a new trace.

IME (albeit a few years now since I was in the Networking team in Platforms Support), checksum offloading provides zero improvement for throughput except on incredibly high-end multi-homed servers that have a gigantic sustained load on them - and conversely I have had customers report that services not only work better, but faster too after turning the feature off.

Also, my VMs running inside Hyper-V on W2K8R2 on my home server became incredibly slow to access when the Marvell NIC on the host had the offloading features enabled (but the Realtek NIC had no problems on the same setup, both onboard chipsets).

That's interesting, all completely new to me.

Accordingly, I've disabled checksum offloading on my NIC. For good measure, I've disabled IPv4 checksum offload, TCP checksum offload for IPv4 and IPv6, and the same for UDP.

However, I'm still getting exactly the same zero checksum errors on outgoing TCP, and indeed SMB as well. You are right though in that it's all outgoing data.

The incoming TCP errors are all just dupe acks.

[jim]

Well, what do you know?!

Some new results, editing as I get them in. Since I can't easily change the NIC speeds on the server, I'm forcing them on my desktop.

All results with checksum offloading and jumbo frames disabled.

Auto-negotiate: 500KB/s - 1MB/s
1.0Gb Full: 500KB/s - 1MB/s
100Mb Full: 5.5 MB/s
100Mb Half: 2 MB/s
10Mb Full: 1MB/s

So, I can easily outperform 1Gb ethernet with 100Mb ethernet, although it's somewhat erratic and not easily repeatable, and I can also outperform it with 10Mb ethernet.

Wireshark still reports the same kinds of errors however.

[jim]

Solved!

I've just redone the network, and eliminated the switch from the network. Now? 12MB/s throughput over 100Mb/s ethernet, which you can't ask for much improvement on.

Looks like it was definitely a dodgy switch. I'm wondering if perhaps the NIC on the HP server was more picky than those on my PC and the WHS, rejecting packets that might've been accepted otherwise.

Either way, it's working now, and the 8-port switch I bought from Guy a few days ago is heading to me now to replace the Netgear switch and then with a bit of luck I'll be back up to Gigabit again.

Fingers crossed that's it, thanks to everyone who helped out! I was convinced it was the server rather than the network, just shows how easily you can miss out things!

[Jay]

nice one mate. It was as if it was asking for the packets to be transmitted over and over. It was a little odd.