From owner-freebsd-current Mon Nov 13 14:38:02 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03956 for current-outgoing; Mon, 13 Nov 1995 14:38:02 -0800 Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03951 for ; Mon, 13 Nov 1995 14:37:59 -0800 Received: (from henrich@localhost) by crh.cl.msu.edu (8.6.12/8.6.12) id RAA17770; Mon, 13 Nov 1995 17:37:58 -0500 Date: Mon, 13 Nov 1995 17:37:58 -0500 From: Charles Henrich Message-Id: <199511132237.RAA17770@crh.cl.msu.edu> To: terry@lambert.org, freebsd-current@freebsd.org Subject: Re: ISP state their FreeBSD concerns Newsgroups: lists.freebsd.current References: <48839e$nhm@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #3 (NOV) Sender: owner-current@freebsd.org Precedence: bulk In lists.freebsd.current you write: >> > 1. A concern that FreeBSD tends to "bind" for brief periods when >> > loaded... >> >> Can this is an IDE issue? I never saw anything like this until >> I configured an IDE mail server. That system pauses for seconds >> sometimes, and then continues. This is running -stable, syscons >> only (no X), no messages logged, etc. The echo stops going to >> the display, the ethernet activity is stopped, all in all it seems >> to be locked up for three or four seconds. >> >> We have three SCSI only systems and haven't ever seen this, and >> one IDE system that pauses. >I have seen pauses on the order of a second or two on a SCSI system >with PCI + NCR controller. >Typically, there are no console messages associated, as one would >expect with timeouts (which the IDE theory implies). >When the pauses start happening, they will continue happening with >a moderate frequency. Typing "sync" will cure the problem for a short >period of time, after which it will recurr. Generally, I type "sync" >often enough from my V6 background that it doesn't hit me. When it >does, it's obvious. A couple of months back Matt Dillion was here (-hackers actually) talking about this same (similar?) problem which he had tracked down to the VM system, and even provided a solution, that seems to have been sat on. Matt is a really really sharp guy, perhaps we should take a closer look at what he has done? -Crh -- Charles Henrich Michigan State University henrich@crh.cl.msu.edu http://rs560.msu.edu/~henrich/