• 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.

Fluctuating GBE transfers

SoulkeepHL

SoulkeepHL

2[H]4U
Joined
Jun 16, 2001
Messages
2,571
Finally got a gigabit copper switch and desktop nic so I could do gigabit to my fileserver, as I tend to transfer a lot of large files. Did a bit of benchmarking using a 2.13 gb rar, and found that it took about 4.2 minutes over the 100bt network, and about 2.08 over 1000bt, which made me happy. But the odd thing was that the estimated time remaining jumped all over the place when running at 1000bt, which struck me as odd. Copied the file again and ended up with this:
gigabit_shens.gif


I tried to search (ocp/google) but I've got no idea what sort of terminology to use. What accounts for the drop offs in the transfer rate? Both machines were idling otherwise. The desktop is an older axp 2100+ with a 3com 3c2000 card, the switch is a netgear gs108 v2, and the file server is a dual p3 with an older national semi dp83820 64bit/66mhz card in a 64bit/66mhz pci slot. The gigabit network was completely isolated from the 100bt network when I was testing as well.
 
You're probably looking at disk limitations. Remember that disks can only do ~40-60MB/s due to physical limitations. You can get higher bursts, but on a 2+gig file, you'll see limitations in the disk show up in transfer speeds.

That's my guess at any rate.
 
The desktop has pata seagate, but that should still be able to handle ~50mb/s sustained sequential reads, right? And the file server is a 12 disk raid 5 array, (3ware 7805-12 on the same 66mhz/64-bit pci bus, which shouldnt be saturating it), so it should be able to keep up. That said, I'm sure that could be playing into it, but is there anything else that could be contributing to it?
 
Make sure the file you're copying isnt fragmented, cause otherwise you wont be 50mb/s STR, seeing as its not sequential.
 
I've got diskeeper set to screensaver mode, so there's only 10 fragmented files on the mostly full 100gb partition that the rar was on, the fragments all being in system restore files, so it should be a sequential read, anything else that might be affecting it?
 
I would say that it is the inefficiency of transferring files using CIFS.

Use FTP if you want a more efficient protocol and better benchmarking.
 
It looks strange.. My first guess would have been that your reader is a lot faster than your writer --- it bursts along until the cache is full on the writer, and then slows down to a trickle. However, I don't think it should swing up and down again in this case -- it should be going on at the write speed.

So my second guess is that the write speed itself is changing. You have a fancy controller and disk array; perhaps it's got a strange behaviour; perhaps its write performance changes according to the position in the array in this manner.

For checking this out, I suggest using PerfMon -- read the disk bytes / sec and the network bytes / sec counters. For caching effects, you might see the network bursting ahead on the writer, the disks going fairly constantly, but significantly slower than the network. Obviously then the buffers would fill up as the writing disk can't keep up and the network transfer would have to be slowed down, etc. Observations of the fluctuation in the disk performance might give you some indication of the second guess. Lots of possibilities here -- look at both graphs on both sides for some clues.

It might be a better idea to check out the network and disks in isolation. iPerf / PCATTCP /etc. can measure the network. Other utilities can measure the disks. Write caching disabling is one typical culprit in array write performance.
 
Madwand said:
It might be a better idea to check out the network and disks in isolation. iPerf / PCATTCP /etc. can measure the network. Other utilities can measure the disks. Write caching disabling is one typical culprit in array write performance.
Click to expand...

This is the most important thing. It's hard to troubleshoot when you have two massive variables: the network and the drive systems. If you can test the network independently, you'll probably find that there's nothing wrong with it.
 
another good program is netcps. simple to run, generates packets in memory, bypassing the disk system.
 
You must log in or register to reply here.
Back
Top