From owner-freebsd-current Thu Jun 5 23:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA02951 for current-outgoing; Thu, 5 Jun 1997 23:57:06 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA02945 for ; Thu, 5 Jun 1997 23:57:02 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id QAA02486; Fri, 6 Jun 1997 16:26:30 +0930 (CST) From: Michael Smith Message-Id: <199706060656.QAA02486@genesis.atrad.adelaide.edu.au> Subject: Re: sio driver performance In-Reply-To: from Richard Straka at "Jun 5, 97 11:31:25 pm" To: straka@inficad.com (Richard Straka) Date: Fri, 6 Jun 1997 16:26:30 +0930 (CST) Cc: bde@zeta.org.au, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Richard Straka stands accused of saying: > > I have noticed that the communications work great until I interrupt the > process on the box which is tranmitting the data. At that point, the box > which was receiving suddenly elevates to 100% CPU usage (mostly system) as > if in a polling loop. Read the manpage for the read() system call, and pay particular attention to the return value for EOF. I suspect that when the sender is killed it is lowering whatever control signal is driving DCD at the receiving end. Without seeing the rest of your code, it's hard to be sure if this is the case. > Also when the receive process is started, before the transmit process is > started on the other box, the read seems to periodically return -1. > Shouldn't the read indefinitely block if c_cc[VMIN]=1 and c_cc[VTIME]=0? Check errno on these occasions; I would guess that you are probably seeing EINTR. > The "tty-level buffer overflows" only occurs after the transmit process is > started, then halted, then restarted. This could be a real problem for my > remote test equipment as the serial lines may be inadvertently > disconnected and reconnected from time to time. I suspect that this is an artifact of the receiver having lost its brain. > Richard Straka -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[