I am running 2008.1 on an Intel 915GAG motherboard, with the 500G 7200 RPM
SATA drive. I was doing an extensive transfer of data from that drive
to another computer over a Gbit ethernet card (Reaktec RTA8110sc chipset
using the r8169 driver module.) The throughput was about 12MB/s, but the
responsiveness of the machine was attrocious. Ie, it would take minutes for
another command to respond. Also since it was acting as a server, the nfs
mounts on other machines would time out.
a) I am not sure where the bottleneck was ( since a GBit card should be
able to so 120MB/s not 12-- and yes the machine at the other end was also
gigabit, and so is the switch in between.) but I suspect is was the hard
drive ( from the slow response of the machine). Do SATA hard disk transfers
really crap out at 100Mbit/sec? And why did he machine become so
unresponsive?

Here is the output from hdparm -i

/dev/sda:

Model=ST3500320AS , FwRev=SD15 , SerialNo=
9QM11823
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7

* signifies the current active mode

On Fri, 11 Jul 2008 20:39:46 -0400, Unruh <unruh-spam@physics.ubc.ca> wrote:

> drive ( from the slow response of the machine). Do SATA hard disk transfers
> really crap out at 100Mbit/sec? And why did he machine become so
> unresponsive?

What does "hdparm -Tt /dev/sda" show for the transfer rate?

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

>On Fri, 11 Jul 2008 20:39:46 -0400, Unruh <unruh-spam@physics.ubc.ca> wrote:

>> drive ( from the slow response of the machine). Do SATA hard disk transfers
>> really crap out at 100Mbit/sec? And why did he machine become so
>> unresponsive?

>What does "hdparm -Tt /dev/sda" show for the transfer rate?

-T--> 900MB/s
-t-> 80-90MB/s
So neither of those seem to be the limitation.
What would be destroying the transfers? gigabit card? Gigabit driver?

I guess I will have to try another GB card.

>Regards, Dave Hodgins

>--
>Change nomail.afraid.org to ody.ca to reply by email.
>(nomail.afraid.org has been set up specifically for
>use in usenet. Feel free to use it yourself.)

On Sat, 12 Jul 2008 02:53:00 +0000, Unruh wrote:

> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>
>>On Fri, 11 Jul 2008 20:39:46 -0400, Unruh <unruh-spam@physics.ubc.ca>
>>wrote:
>
>>> drive ( from the slow response of the machine). Do SATA hard disk
>>> transfers really crap out at 100Mbit/sec? And why did he machine
>>> become so unresponsive?
>
>>What does "hdparm -Tt /dev/sda" show for the transfer rate?
>
> -T--> 900MB/s
> -t-> 80-90MB/s
> So neither of those seem to be the limitation.

And hdparm -Tt for the machine at the other end?

Is this over CIFS, NFS, SFTP, FTP, HTTP, or something else?



** Posted from http://www.teranews.com **

On Fri, 11 Jul 2008 22:53:00 -0400, Unruh <unruh-spam@physics.ubc.ca> wrote:

> So neither of those seem to be the limitation.
> What would be destroying the transfers? gigabit card? Gigabit driver?

Somethings getting device waits. No matter how much ram you have, the
kernel may be choosing to swap out some things. Try running

sysctl -w vm.swappiness=1 # Stop applications from being swapped to disk
sysctl -w vm.vfs_cache_pressure=50 # Don't shrink the inode cache

to see if that improves the responsiveness of other applications.

Try running htop --sort-key STATE, and watch it while the transfer is
running, to see what's going into device wait, and if any swapping is
going on.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

On 2008-07-12, Snowbat <snowbat@geocities.com> wrote:
>
> And hdparm -Tt for the machine at the other end?
>
> Is this over CIFS, NFS, SFTP, FTP, HTTP, or something else?

That would have been my question. I find NFS jacks up the system CPU.
FTP is very low.
My guess is that in order of CPU utilisation it would be

FTP->HTTP->CIFS/Samba->NFS

But that's just a guess. Not sure where scp goes, there is encryption
but appart from that it doesnt care about the file system much.

Lordy

Snowbat <snowbat@geocities.com> writes:

>On Sat, 12 Jul 2008 02:53:00 +0000, Unruh wrote:

>> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>>
>>>On Fri, 11 Jul 2008 20:39:46 -0400, Unruh <unruh-spam@physics.ubc.ca>
>>>wrote:
>>
>>>> drive ( from the slow response of the machine). Do SATA hard disk
>>>> transfers really crap out at 100Mbit/sec? And why did he machine
>>>> become so unresponsive?
>>
>>>What does "hdparm -Tt /dev/sda" show for the transfer rate?
>>
>> -T--> 900MB/s
>> -t-> 80-90MB/s
>> So neither of those seem to be the limitation.

>And hdparm -Tt for the machine at the other end?

It is even better 1250 MB/s and 92MBps

Ie, it seems not to be the hard drives.
And the cpus are only at 20% according to gkrellm, so it should not be cpu
saturation.

>Is this over CIFS, NFS, SFTP, FTP, HTTP, or something else?

rsync over ssh.



>** Posted from http://www.teranews.com **

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

>On Fri, 11 Jul 2008 22:53:00 -0400, Unruh <unruh-spam@physics.ubc.ca> wrote:

>> So neither of those seem to be the limitation.
>> What would be destroying the transfers? gigabit card? Gigabit driver?

>Somethings getting device waits. No matter how much ram you have, the
>kernel may be choosing to swap out some things. Try running

>sysctl -w vm.swappiness=1 # Stop applications from being swapped to disk
>sysctl -w vm.vfs_cache_pressure=50 # Don't shrink the inode cache

>to see if that improves the responsiveness of other applications.

>Try running htop --sort-key STATE, and watch it while the transfer is
>running, to see what's going into device wait, and if any swapping is
>going on.

I could try, but it sure should not be. The machine has 3GB of ram and
there is nothing else ( except nfs) running on the machine. If it is
swapping it is a very severe bug in Linux.

But I will try your suggestions.
o

Under htop, how do I know if it is in device wait?


>Regards, Dave Hodgins

>--
>Change nomail.afraid.org to ody.ca to reply by email.
>(nomail.afraid.org has been set up specifically for
>use in usenet. Feel free to use it yourself.)

lordy <spam@lordy.org.ukinvalid> writes:

>On 2008-07-12, Snowbat <snowbat@geocities.com> wrote:
>>
>> And hdparm -Tt for the machine at the other end?
>>
>> Is this over CIFS, NFS, SFTP, FTP, HTTP, or something else?

>That would have been my question. I find NFS jacks up the system CPU.
>FTP is very low.
>My guess is that in order of CPU utilisation it would be

>FTP->HTTP->CIFS/Samba->NFS

>But that's just a guess. Not sure where scp goes, there is encryption
>but appart from that it doesnt care about the file system much.

As I said, I do not think that cpu is the problem. cpu utilisation while
the transfer is going on is only about 15-20% on each of the two cpus (dual
core)
My suspicion is that it either the ethernet card or the ethernet driver,
but that could be wrong.




>Lordy

Unruh <unruh-spam@physics.ubc.ca> writes:

>"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:

>>On Fri, 11 Jul 2008 22:53:00 -0400, Unruh <unruh-spam@physics.ubc.ca> wrote:

>>> So neither of those seem to be the limitation.
>>> What would be destroying the transfers? gigabit card? Gigabit driver?

>>Somethings getting device waits. No matter how much ram you have, the
>>kernel may be choosing to swap out some things. Try running

>>sysctl -w vm.swappiness=1 # Stop applications from being swapped to disk
>>sysctl -w vm.vfs_cache_pressure=50 # Don't shrink the inode cache

>>to see if that improves the responsiveness of other applications.

>>Try running htop --sort-key STATE, and watch it while the transfer is
>>running, to see what's going into device wait, and if any swapping is
>>going on.

>I could try, but it sure should not be. The machine has 3GB of ram and
>there is nothing else ( except nfs) running on the machine. If it is
>swapping it is a very severe bug in Linux.

>But I will try your suggestions.

>Under htop, how do I know if it is in device wait?

OK, tried doing it. htop showed that rsync and a number of other programs
that started up while the rsync was running, was often in D state. (I'd say
at least 50% of the displays on htop had rsync as D.) During that time
programs like spamassasin, syslogd, would pop up in the D state for a
single display time as well.

So, is there any way of finding out if it is the hard disk or the ethernet
card which are putting it into uninterruptable sleep?


>>Regards, Dave Hodgins

>>--
>>Change nomail.afraid.org to ody.ca to reply by email.
>>(nomail.afraid.org has been set up specifically for
>>use in usenet. Feel free to use it yourself.)