[gentoo-amd64] Re: Tcp transfer has a pause every few seconds

[Duncan]

P.V.Anthony posted <435D3729.4070507@×××××××××××.sg>, excerpted below,  on
Tue, 25 Oct 2005 03:34:01 +0800:

> I have a problem with my nfs transfer using tcp or udp. There is a pause
> every few seconds when I am writing to the server. This causes the video
> that I am recording to have jerks and lost frames. The tcp stream is not
> constant.
>
> I will try to explain the best I can.
>
> I have a server for video use. I connect the videoserver with Macs using
> cross cable. Using NFS version 3 and using tcp. The filesystem on the
> server is XFS.
>
> On the macs there is a dv camera connected. Using a video editing
> software, I am recording the video to the nfs mount on the mac. After
> the recording when I play back the recording there are jerks in the
> video every 20 seconds or so.
>
> Next I copy a big file to the nfs mount. The file goes through but I
> notice that
>   there is pause every 20 seconds or so. DV video only need about 3.5MB
>   per
> second. All the ethernet connection is gigabit.
>
> What am I doing wrong? Please do advice.

Pause every few seconds.  I've seen two commonly reported solutions to
this -- two different problems resulting in the same symtoms -- and
another one less common in general but likely equally common on amd64.

1)  DMA, or rather, the lack thereof, or interrupt sharing.  Ensure that
you have  the correct chipset drivers installed, both for whatever bus the
NIC is on, and for your hard drive interface (the PATA/SATA/SCSI chipset).
Often, generic or the wrong drivers will work in degraded mode, but DMA
won't be turned on, and performance will suffer.  For your hard drives
(yes, wrong drivers there /can/ cause bottlenecks up the chain, including
onto the same bus as the NIC), use hdparm (or sdparm) to verify that both
the drive and the chipset agree that DMA is on.

Also check interrupt distribution and sharing.  You may be able to change
these settings in the BIOS, or try switching some cards around
(particularly your NIC if it's not on-board built-in).

2)  Do you have an "extra" network interface?  I've seen this one on
MSWormOS and am unsure how Linux would even have the problem, unless you
have a spare interface (say a wireless card) that's running but not
connected.  Anyway, the problem here is an interface set to DHCP mode that
can't get an IP because it's not connected, so of course can't see a
server.  The system would pause every few minutes (every few seconds seems
a bit much, but...) and try to obtain an IP, stalling all I/O in the
process.  (Again, the reason it's stalling all I/O is likely rooted in
misconfigured DMA or IRQs, but anyway...)

3)  Seen frequently on this list as a problem resulting in one or more of
a number of symtoms, including this one:  APIC or ACPI problems.  Take a
look at the kernel documentation under $kerneldir/Documentation/x86_64,
the apic and acpi boot options, and idle=poll as well.  Note that those
needing these often find they don't after a mature BIOS is available and
flashed.  idle=poll is particularly nasty, as it will cause your CPU to
work far harder and run far hotter than it ordinarily would, but some
early amd64 boards required it until an updated BIOS fixed the issue.  I'm
not sure if that's still a problem with the newer boards or not.

Also note that for specific net chip, various configuration options may be
available.  In particular, there's the Broadcom tigon3/tg3 kernel driver,
and then another (I forget what it's called) for the same net chip.  Often
one will work well, the other won't work or will have issues. If that's
your chip, look it up and consider trying the other driver.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list