help: Win2k3 SP1 SMB file copies slow

[Bytre]

On my file server (P4 2.4GHz, 1.12GB RAM, gigabit NIC), I recently upgraded to SP1 and added another drive array. Afterwards, I noticed that my SMB file copies (from a high speed XP client) fluctuate between expected speed and really slow speed.

For about 10 seconds, it'll burn along at 35-40MB/sec or so, then drop down to 2-5MB/sec for about a minute. Then I'll get another boost at high speed. During this time, the server retains relatively decent CPU and memory utilization.

Now the interesting part - if I send the same file (an 8 gig ISO image) via FTP to the IIS server, I'll get a sustained transfer of 40-50MB/sec for the whole transfer, which tells me that the IO on the system can keep up.

I don't know if SP1 had something to do with it or if my upgrade was coincidental. Any ideas?

 

[stimpyman77]

Disable SMB Signing and your speed should come back to normal. I experienced an issue similar to this recently using SBS 2003 SP1. If your server is running AD and is a DC then SMB signing is enabled, if I remember correctly. It is the overhead of signing the payload that is slowing you down. That is why you don't see it when doing an FTP transfer.

Hope that helps..

 

[Bytre]

Thanks for the suggestion, but that's not it. Already disabled. The server is a standalone server, not a DC and not running AD.

 

[nweaver]

Basic net troubleshooting (even though FTP is fine, start at the beginning)

1. Physical: Change/check all cables (swap if possible), change switch/switchports
2. Datalink: Check drivers, check for duplex mismatches, check frame size. Check for collisions, crc erros, etc

Check those first...even if you are "sure they are fine".

 

[Joony]

I've noticed this myself sometimes...can someone offer a solution?

 

[spidey07]

Originally posted by: nweaver
Basic net troubleshooting (even though FTP is fine, start at the beginning)

1. Physical: Change/check all cables (swap if possible), change switch/switchports
2. Datalink: Check drivers, check for duplex mismatches, check frame size. Check for collisions, crc erros, etc

Check those first...even if you are "sure they are fine".

network troubleshooting 101.

do this.

 

[spikespiegal]

network troubleshooting 101.

He's already determined that FTP doesn't have the same problem, so why may I ask are you guys messing around with datalink level problems? Maybe we should add a faster video card or something.....geesh.

I see this issue all the time on my Win2K boxes, and it drives me nuts. I suspect it has something to do with how Windows treats it's system cache and parks a big file transfer into a background state, or more bugs with mrxsmb.sys.

 

[nweaver]

Originally posted by: spikespiegal

network troubleshooting 101.

He's already determined that FTP doesn't have the same problem, so why may I ask are you guys messing around with datalink level problems? Maybe we should add a faster video card or something.....geesh.

I see this issue all the time on my Win2K boxes, and it drives me nuts. I suspect it has something to do with how Windows treats it's system cache and parks a big file transfer into a background state, or more bugs with mrxsmb.sys.

Because you ALWAYS START AT LAYER ONE AND WORK YOUR WAY UP when you are doing network troubleshooting. Why? Because you will solve 95% of problems at L1, 4% at L2, and 1% at the others. Assuming you have a network admin who is worth anything and has your network set up.

The FTP test is not conclusive enough for me to rule out L1/L2. It's best practice to start at 1 and go up.

 

[Bytre]

Thanks for the suggestion, but it is not at the physical layer nor the data link layer (I did double check). The FTP test demonstrates that I have full speed all the way up to layer 7. I can get high throughput - sustained - passing tcp packets back and forth with iperf as well.

What I am seeing is that on my win2k3 system, the write rate to the hard disk is much lower with the SMB transfer vs. an FTP transfer to the same disk. Both are lower than a disk to disk copy on the server, but that's understandable.

A disk to disk transfer writes to the disk at 28MB - 38MB/sec (per perfmon disk write bytes/sec).

The SMB transfer writes to the same drive at 7 - 11MB/sec, whether the network data is coming in at 45 MB/sec or 5 MB/sec - it fluctuates as I wrote before.

The FTP transfer writes to the disk around 38 MB/sec.

My problem isn't packet arrival, it isn't writing to the disk, its writing to the disk on packets received through SMB.

 

[Madwand1]

I've seen problems like this with very large Microsoft backups -- starting out fast, and then degenerating into the bottlenecking / thrashing, in the end giving less than fast ethernet performance over time (dealing with 100's of GB's here). I haven't gone back to figuring that out, but saw that raw xcopy file transfers worked much better. I chalked it up to some OS resource exhaustion, but haven't tracked it down.

MS has an article about improving file server and network performance via configuration tweaks -- perhaps it'll help.