Network Speed - Push Files vs. Pull Files

Status
Not open for further replies.

Savage1701

Posts: 154   +1
I have a server with a RAID 6 array and 2 clients that I regularly transfer large DV files to and from. The server and both clients have Intel Pro/1000 PT PCIe x1 NIC's. Onboard LAN is disabled in BIOS on all 3 computers. Both clients have identical settings on their NiC cards. Both clients and the server are on the same GbE switch.

My question is this - Client "A" can have files pulled from the server side or push them to the server at wire speed - 50-90 MB/s. Client "B" can have files pulled from it on the server side at the same speed, about 50-90 MB/s, but if I try to push a file to the server, either via teracopy or drag-and-drop on a network share, the network utilization goes down to about 1% and the transfer speed is about 2-4MB/s.

What could cause this? Both clients have 4GB i-RAM drives on them for testing purposes, and these read 150MB/s according to HD Tune, so I'm confident this is not some obscure setting buried in the "B" client's drive firmware. Also, the clients can move the files quickly between their other internal drives and their i-RAM drives, so I don't think anything is strange there either.

I'm wondering if the "B" client has an IRQ issue the other client does not, but I don't know how to track stuff like that down.

Any help would be appreciated.
 
Have you tried swapping out the NIC card on the problem PC? It uses different circuits to push and pull, so it could have a problem with one of the circuits and not the other.
 
I took your suggestion and enabled the onboard GbE Marvell NIC. Same thing - fast pulls, 2-4MB/s "pushes". Wonder if this is a switch port problem?
 
No, not a switch port problem either. Switching problem client port makes no difference. Also, ran Intel diagnostics on both NIC's and they were identical for passes, signal quality, etc.
 
Hello Savage

I doubt it is a NIC. I would not do anything to a NIC yet!

Do these on both or computers or all on the LAN.
http://www.speedguide.net/read_articles.php?id=1607

Do the below on both also.

Disable Last Access Timestamp

When the OS reads a file, it stamps the file with the date and time that you accessed it.

Not required for normal use unless you use date of last access for backup
purposes.

Timestamping a file that has just been read means that a write has to be made to disk every time a read is executed, a write is also executed.

To disable the last access timestamp, at cmd prompt, enter the following command then reboot

FSUTIL behavior set disablelastaccess 1
0 to reverse

FSUTIL behavior set disablelastaccess 0
1 to reverse

Disable 8.3 Filenames

You're certain you don't use any 16-bit applications that rely on DOS 8.3 filenames

You can disable DOS 8.3 filename creation. This change will greatly speedup Explorer directory browsing.

If you have a many folders this tweak may afford a speedup browsing folders.

At the command prompt, enter the following then reboot:

fsutil behavior set disable8dot3 1

0 to reverse.

Mike
 
OK, first, NetCables - thanks. I forgot to post I tried that also, but good thought. Flynn & Jo - I will try these and let you know. I appreciate it. I sort of doubted the NIC since but was wondering IRQ issues also, but I will certainly try all of your suggestions. Flynn - that was exactly the sort of article I have been looking for. The best I could ever dig up was tweaking MTU but I thought that more applied to ISP issues. Anyway, I will put these suggestions to the test and post back.

Anyway, thanks for the ideas and I will put them to the test.
 
Oh, forgot - 32-bit XP Pro on both client and server side. (Server 200x not an option). Strangely, or perhaps not strangely, I encountered these sorts of issues when I demo'd Rocket Stream server/client software. Probably unfairly cost them a sale.
 
You should have a test lab using a 24-port managed switch, blade server 32-bit XP Pro and this Rocket Stream. Do some stress testing see how it goes before you implement Rocket Stream on the main.
 
my only issue with mflynn's tweak is that XP normally runs with Access Time recording
and it does not impact other systems nor even your "system-a"
and as faithfully reported by mflynn, it will impact backup software.
 
Well, here's one thing - Just for the heck of it I installed a copy of 64-bit XP Pro I had and lo and behold, all my "push" problems vanished. I also contacted 3Ware and they had never heard of anyone having this issue. No clue, but whatever it is it happens across multiple platforms (Supermicro and Asus boards), onboard or outboard NIC's, 2 different make/models of GbE switches, swapped cables, PCI-X controllers or PCIe, you name it, so I assume it's got to be some weird interaction between 3Ware and XP Pro 32-bit. I know 32-bit is based on NT core and 64-bit is based on Server 2003 core, so I would imagine there are a lot of differences in the way networking is handled underneath the look-alike GUI's.

I hate to say it, but I think I am better off getting a couple extra copies of 64-bit XP Pro and being done with it rather than chasing this sort of thing around (potentially) forever.
 
XP 32 Bit Networking

Savage, it has been my experience that XP 32 bit (Pro or Home) does not work properly with gigabit speeds. Specifically, with the File & Print sharing (SMB) on any protocol (TCP/IP or IPX/SPX) I've tried.

In my office (I'm a partner in a computer repair & sales shop), we replaced our 10/100 switch with a gigabit switch and installed gigabit cards in all of the PC's that didn't already have them. I noticed in my speed testing that the PC's that have XP Pro or Home 32 bit will "download" files from our servers (several 2003 32bit and 2008 64 bit) at gigabit speeds. But, those XP 32 bit systems will only "upload" files at 10/100 speeds. I tried switching network cards, drivers, ports, etc. But, the only systems affected were the XP 32 bit systems. The 2003 and 2008 servers, XP 64 bit PC's, and Vista 32 or 64 bit PC's could all upload or download files to network shares at gigabit speeds.

To further test, I installed 2003 server 32 bit in a Virtual Machine and installed XP 32 bit in another VM. The host OS was XP 64 bit. The XP 64 bit system AND the 2003 VM could upload files to shares at gigabit speeds. But, the XP 32 bit VM could only upload at 10/100 speeds. In addition, I tried changing the networking protocols from TCP/IP to only IPX/SPX and the problem remained.

So, in summary, I believe there is a problem with XP 32 bit systems with their File/Print sharing (SMB) subsystems - but only with the "uploading" of files. I have not repeated these tests using another transfer method like FTP. But, I read somewhere online (can't remember where) while researching this problem that someone did test FTP on XP 32 bit and it worked at full gigabit speeds.

Can anyone else confirm my testing or suggest something I might have missed?
 
Bud, I think you summed up my whole experience perfectly. Thanks to all who posted ideas and comments. I appreciate them all.
 
I assure you that you are wrong about XP 32bit not working at Gigabit speeds. I have easily attained transfer speeds from 600 to 800Mbps using an NForce gigabit ethernet controller plugged into a Netgear Gigabit switch (The XP machine) going to a Marvell gigabit ethernet controller on a Linux file server. This includes both "uploading" and "download" to the server.
 
Soul - you just said it - your server is LINUX. Mine is 32-bit XP Pro, which is what I am having the problems with. I'm sure you do attain those speeds on a Linux server. I attain close to those speeds on 64-bit XP Pro on my server, which is why I am not going to spend the rest of my days chasing down some obscure registry entry or convoluted tweak that some of the 100+ 32-bit XP Pro patches probably altered, when I can spend $140 once for a copy of 64-bit XP Pro and be done with it.

The issue has never been the client side; it has been an obscure problem between several 3Ware controllers and 32-bit XP Pro's network interaction on the server side. I don't have those problems either if I use the server's onboard ICH7R or Marvell or even an old, crappy Promise 32-bit PCI RAID card. I can push to any of those at up to 50MB/s from any of my clients over a GbE network without even attempting to go for fine tuning the speed.

I know I neglected to mention that in my first post, but I honestly never thought it was the 3Ware controller interacting with 32-bit XP Pro in some way. But at the end of the day, after eliminating onboard/outboard NIC's from 3 different manufacturers, MB manufacturers, slot swapping, cabling, and switches, I'm left with something that 3Ware can't explain to me - why I can't push files to my servers from my clients at greater than 5MB/s if a 3Ware controller is involved, be it a 9000, 9550, 9590, or 9650 series on PCI, PCI-X, or PCIe.
 
why I can't push files to my servers from my clients at greater than 5MB/s
Plural? I thought is was just one client having problems.
If ALL clients have reduced throughput to your server, then imo this implicates inbound transactions on the server itself.
 
Jo - you are right - originally I was noticing this on only one of the 2 clients because I was pushing files from one of the clients to a different brand of RAID controller on the server (The server has more than one). It never dawned on me, until I worked my way through these posts, that perhaps it was the RAID controller. I assumed it was always some switch problem or NIC issue. As I worked my way through it, and these posts, I sort of realized that, no matter what, irregardless of MB, NIC brand, onboard or outboard, PCI, PCI-X, or PCIe, RAID JBOD, RAID 0, RAID 5, or RAID 6, alternative GbE switches, or fresh cabling, the bottom line was that I could push or pull from any client, jury-rigged or regularly used, to any server, my regular one or ones I temporarily used, to any controller - ICH5R, ICH7R, Promise, Jmicron, or Marvell onboard at respectable, virtually symmetric speeds of, on average, 50MB/s and up. But, if I put a 3Ware controller, be it any of the ones I mentioned above, into any server, permanent or temporary, that any client could only push to it at about 5MB/s.

So, I guess that leads this thread to a new question - is anyone encountering, in a 32-bit XP Pro environment, a situation such as this with 3Ware controllers?

I'm still wondering if this is some sort of IRQ issue where the 3Ware cards are interacting poorly with something on the server side.

Sorry if I was chasing the wrong thing at the beginning of this post, but I guess that's why I am at a forum looking for help. If I knew it was a weirdo 3Ware interaction all along I could have eliminated a lot of things to begin with.

I am considering down-rev'ing the firmware and drivers on one of my controllers (with instructions and driver/firmware sent to me by 3Ware tech support) and seeing if it still happens 4 or so driver/firmware updates ago, and if it does not, stepping my way forward in updates until the issue hits again.

But, bottom line for now, whatever happens in 32-bit XP Pro does not happen in 64-bit XP Pro, and that may just have to be good enough for me.
 
Jo - you are right -
sad to hear that
I'm still wondering if this is some sort of IRQ issue where the 3Ware cards are interacting poorly with something on the server side.
could be, but ONLY if it's a shared IRQ; a conflicted irq would have never gotten you this far.
Sorry if I was chasing the wrong thing at the beginning of this post, but I guess that's why I am at a forum looking for help. If I knew it was a weirdo 3Ware interaction all along I could have eliminated a lot of things to begin with.
hey, that's why is called TROUBLE SHOOTING. Don't finger point the 3Ware too assertedly; that's only one suspect
I am considering down-rev'ing the firmware and drivers on one of my controllers (with instructions and driver/firmware sent to me by 3Ware tech support) and seeing if it still happens 4 or so driver/firmware updates ago, and if it does not, stepping my way forward in updates until the issue hits again.
get a backup first; THIS IS A RISKY CHOICE!

Can you minimize services and/or hardware and use one client to test the configuration?

Have you investigated;
  1. LMHOSTV1 vs V2 authentication (the original is v1 of course)
  2. eliminated SMB Signing?
  3. avoided encrypted network access?
  4. avoided encrypted folders on the server?
 
jo - at this point 3Ware is going to test-bed what I have and see if they can duplicate it. We've pretty much got it narrowed down to 32-bit XP Pro and their driver interacting in some weird way.
 
Status
Not open for further replies.
Back