TCP parameters and interpreting tcpdump output

[Dieter]

> > The machine has 2 GB.  I wonder if the process is getting its fair share?
> > I have been observing other problems where disk activity to one disk
> > will make an unrelated process reading data from a different disk *very*
> > unresponsive.
> 
> Sounds like a hardware problem to me.  If you've got a crappy SATA
> controller that's going to block every now and again, you're going to
> have trouble with this.

Is the Nvidia "Nforce4 Ultra" chipset considered a crappy SATA controller?
There are 4 Seagate SATA drives, 1 Seagate PATA drive (all 7200.8 .9 or .10),
and 1 LG CD/DVD PATA drive.  The PATA drives are idle during these tests.

Doing dd between the disks and /dev/null it can do 40 MB/sec sustained at
the slow end and 65-70 MB/s at the fast end of the drives, limited by the
drives, and do this with all four SATA drives at once.  It can do this
reading or writing if the disks' cache is turned on.  With the disks' cache
turned off, the sustained write speed drops to about 1/10.

But... if I do something like copy a large file from one disk to another,
and then do something that needs to read from a third disk, the new process
may hang for a very very long time.  If I suspend (^Z) the copy process for
a moment, the new process gets its data.  I suspect that the kernel is
letting the copy process kick everything else out of memory.  To some extent
that makes sence.  It is caching the most recently accessed data.  What I
haven't figured out is why the new process is allowed to hang for so long.

I had thought of putting in a circular buffer, but figured that it should
be unnecessary since the normal Unix write-behind should buffer the
writes from the disk I/O for me.  I'll give it a try, maybe it will help.