Date: Mon, 20 Nov 2006 11:19:52 -0500 From: Bill Moran <wmoran@collaborativefusion.com> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@freebsd.org Subject: Re: TCP parameters and interpreting tcpdump output Message-ID: <20061120111952.4213dacb.wmoran@collaborativefusion.com> In-Reply-To: <200611200004.AAA12714@sopwith.solgatos.com> References: <20061119100534.a37a6e5c.wmoran@collaborativefusion.com> <200611200004.AAA12714@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In response to Dieter <freebsd@sopwith.solgatos.com>: > > > 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. *shrug* I don't know their product lines to comment. I'm only speculating. "Crappy" could mean that the FreeBSD driver for those devices is problematic ... or it could mean you've got a marginal cable causing communication errors -- in brief, anything that could cause the drive to block as you describe, even if it's not specifically the hardware. > 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 sense. 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'm surprised that you're seeing that much of a "hang". Even if the disks are busy, the system should slow down all disk processes equally, so no one process "blocks", but they're all a little slower. It doesn't sound like that's what's happening. > 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. First, use the /dev/null test to verify whether or not the disks really are the problem. You don't want to waste a lot of time on something that may be unrelated. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061120111952.4213dacb.wmoran>