From owner-freebsd-questions@FreeBSD.ORG Mon Nov 20 00:06:45 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82DD616A4B3 for ; Mon, 20 Nov 2006 00:06:45 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-71-117-237-135.ptldor.fios.verizon.net [71.117.237.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB86843D82 for ; Mon, 20 Nov 2006 00:05:27 +0000 (GMT) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.13.7/8.13.6) with ESMTP id kAK05hL3029457 for ; Sun, 19 Nov 2006 16:05:43 -0800 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.13.7/8.13.4/Submit) with UUCP id kAK05h4E029454 for freebsd-questions@freebsd.org; Sun, 19 Nov 2006 16:05:43 -0800 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id AAA12714; Mon, 20 Nov 2006 00:04:16 GMT Message-Id: <200611200004.AAA12714@sopwith.solgatos.com> To: freebsd-questions@freebsd.org In-reply-to: Your message of "Sun, 19 Nov 2006 10:05:34 EST." <20061119100534.a37a6e5c.wmoran@collaborativefusion.com> Date: Sun, 19 Nov 2006 16:04:16 +0000 From: Dieter Subject: Re: TCP parameters and interpreting tcpdump output X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2006 00:06:45 -0000 > > 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.