Date: Sun, 19 Nov 2006 16:04:16 +0000 From: Dieter <freebsd@sopwith.solgatos.com> To: freebsd-questions@freebsd.org Subject: Re: TCP parameters and interpreting tcpdump output Message-ID: <200611200004.AAA12714@sopwith.solgatos.com> In-Reply-To: Your message of "Sun, 19 Nov 2006 10:05:34 EST." <20061119100534.a37a6e5c.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611200004.AAA12714>