• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Network speed, need MORE

S

Samhorns

n00b
Joined
Nov 25, 2005
Messages
30
Knowing this is the home of those that love to optimize I have a quandary for you all. Trying to solve the conundrum of why I can not pull more then 12-13% out of my gigabit network. I am a total newb at optimizing this part of my machine so I'm hoping some generous souls will spew forth some good tips. Got the basics, Dlink DGL 4300 gigabit router, using cat6 all around, using the onboard Marvell Yukon nics on two machines and a Netgear GA311 in the third. Start me off with where I go to change packet sizes over my LAN and such good stuff, I know the defaults I'm using have got to suck big time. Any help would be greatly appriciated since I have to back up over 190 gigs of poo across this thing and would like to get as much zip as I can without buying any more hardware (yet) ;)
 
Are you testing with just streaming pure testing data? Or are you testing by transferring files?

If you are transferring files, you are only as fast as the sustained throughput of the slowest hard drive involved.
 
Thanks much for the tips. I did google a lot last night and did some more experimenting. To answer the first question I am gauging the speed of actually file transfer using 10-20 gig blocks of mp3s to give me a realistic base. Nessus is on to my biggest issue which is the drive I need to get 111 gigs of data off is a PATA133 MAXTOR diamondmax 10 160gig but I'm putting the data on a SATA 3.0 500gig WD w/ 16mb cache. The maxtor resides in an old AMD t-bird 1.4 with 768ram on an ECA K7S5A and the WD is in my primary machine which is an AMD 2.4 san diego core with 2gig ram on an ASUS A8N-SLI Premium 939 NVIDIA nForce4 board. I'm trying to migrate roughly 170gigs or so MP3s off IDE drives onto SATA drives simply put. I find drive to drive in the same machine from the PATA buss to the SATA drive is painfully slow and that doing it from one machine to another over a gig network was actually faster by almost double. Once I get everything on SATA drives I'll be in the clear because drive to drive in the same machine over the SATA bus has shown to move about 3 times faster then even my gigabit network band-aid. In the end it's PATA FTL and SATA rocks :cool:
 
Samhorns said:
I find drive to drive in the same machine from the PATA buss to the SATA drive is painfully slow and that doing it from one machine to another over a gig network was actually faster by almost double. Once I get everything on SATA drives I'll be in the clear because drive to drive in the same machine over the SATA bus has shown to move about 3 times faster then even my gigabit network band-aid. In the end it's PATA FTL and SATA rocks :cool:
Click to expand...

That's weird, and is not how it's supposed to be. In practice, for file transfers, there's typically very little if any difference due to the interface differences. Take drives from the same family with different interfaces, and the SATA drive typically measure exactly the same as the PATA drive for sequential access. Take different drives, esp. ancient PATA drives vs. latest & greatest SATA drives, and of course the results would be different, but this wouldn't be due to the interface -- it's because the drives themselves have gotten faster. Maxtor DM10's a bit dated, but it's not very old, and should be performing well. SATA vs. PATA is a bit off-topic, so I won't bother to post graphs to back up my points just now.

One potential problem is that the PATA drive isn't negotiating UDMA properly in the computer you tried. Maybe you could try different cables or connections, master/slave, etc., to resolve this issue. I'd suggest trying the other computer if it had a SATA port, but I guess it probably doesn't.

There are lots of gigabit threads in this forum (and maybe the storage forum here). You can find some testing and tweaking info there. The THG thread was pretty old and not that great. Generally the way to go is to measure pure network performance with something like iperf. If that measures well, you forget about tweaking the network further and look at other things (drives, file transfer protocol, Windows). 30 MB/s is a typical figure for Windows to Windows, single drive SMB, and this is pretty hard to improve upon. Pushes generally work better than pulls.

In your case, there are a couple of alternatives:

1. Just transfer the files overnight at your current speed and forget about tweaking it. Really, you could spend far more time on the tweaking.

2. Use ftp. Set up something like FileZilla Server and client, learn how to use them, and use them instead of Windows file transfer. This will get you closest to your network speed because Windows file transfer has issues which you can't really get around short of changing the OS.

Watch out for binary/text mode transfers if your client doesn't automatically switch/default to binary. Check some of your files afterwards -- zip a bunch and check their checksums / or use a utility that calculates checksums -- use it on both ends, and then compare the checksums. Some tools will generate a checksum file, which you can use on the other end to check the files. In this sort of thing, you don't want to go across the network, because that'll take more time.
 
Thanks for the very informative post sir. In the end whatever was the real issue will haunt me but the work is done none the less. As you suggested I just set her to cook overnight and forgot about it, 3-4 hours later it was done.

My biggest issue by far turned out to be an issue with the recovery software I was using to try to restore the dead drive. On the suggestion of the owner of the MP3s we tried Stellar Phoenix and had mixed results. I was impressed how it found most of his drive after a boot sector crash with bad root corruption to include the NTDLR. What quickly ruined my day was how when I tried the same 'set it and forget it' restore method we did for transfer, it would randomly miss entire directories of music. In a collection this size this meant me going back comparing directory sizes to find the 600 or so songs that did not get recovered in the initial try taking upwards of 2-3 hours.

Once the files were located they restored just fine but there was no log file to explain why the silly program had skipped them the first go around. All I can assume is the shear size of the directory structure I was trying to restore overwhelmed the old T-bird but that’ll just have to be left another unsolved mystery.
 
Check to see if your drivers support jumbo frames and if your switch does as well. OTher than that, you're hitting the PATA/SATA wall, bro.
 
The DGL-4300 doesn't support jumbo frames. However, it's still possible to get great throughput without jumbo frames.

(Practice isn't as simple as theory, so sometimes jumbo frames help significantly; often they don't; sometimes it can even hurt throughput a bit. But there's little point in fretting about it here, because the hardware doesn't support it and the odds for a significant improvement aren't all that great.)

That said, jumbo frame performance can be easily tested without a supporting switch by using direct connections. Gigabit as a rule doesn't even need crossover cables for direct connections, and cables don't care about frame sizes.
 
Antivirus real time protection..depending on what AV product you're using..try disabling real time file protection when doing huge transfers...you'd be surprised at how much faster the transfer will go with it disabled.

//inserts warning of assuming your source files are already scanned and clean
 
You must log in or register to reply here.
Back
Top