From owner-freebsd-stable Tue May 1 14:30: 7 2001 Delivered-To: freebsd-stable@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 5B6D537B423 for ; Tue, 1 May 2001 14:30:00 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA22516; Wed, 2 May 2001 07:29:55 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01K32WIZNSRKS4OCL4@cim.alcatel.com.au>; Wed, 2 May 2001 07:29:52 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f41LToI84559; Wed, 02 May 2001 07:29:50 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Wed, 02 May 2001 07:29:50 +1000 From: Peter Jeremy Subject: Re: problem with plip stealing clock In-reply-to: <3AEED69E.F6EC1EAD@webmail.bmi.net>; from jmcoopr@webmail.bmi.net on Tue, May 01, 2001 at 08:30:38AM -0700 To: John Merryweather Cooper Cc: FreeBSD-STABLE Mailing List Mail-Followup-To: John Merryweather Cooper , FreeBSD-STABLE Mailing List Message-id: <20010502072950.N59150@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3AED84DB.8D241BCF@webmail.bmi.net> <20010501171807.M59150@gsmx07.alcatel.com.au> <3AEED69E.F6EC1EAD@webmail.bmi.net> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-May-01 08:30:38 -0700, John Merryweather Cooper wrote: >Couldn't the plip interface arbitrate this though by driving it's "bus" >cycle at the pace of the slowest system? Not really. The options are basically either read the IP packet in a spinloop (as now) or take 2 interrupts per byte (each byte is transmitted as 2 nybbles). One option might be to reduce the interrupt handler priority to allow clock interrupts - though when I tried that, I think it made both systems even more sluggish. (Either system taking a clock interrupt bogs down both systems). Given your speed differential, it might be practical for you to try the `interrupt per nybble' approach on the Duron and use something like ntpdate to continuously `correct' the laptop clock from it. Another option would be to modify the interrupt handler code to count pending (clock) interrupts rather than just setting a flag to say that one is pending. >> I did have the problem with PLIP between my 386 laptop and 486 desktop >> until I reduced the MTU to 512. > >Anything "magical" about 512 (or is lower better here). If lower is >better, how low can I go (I guess I'll find out). Not really. That value seems to work for me between a 386SX25 and a 486DX2-50. YMMV. The disadvantage of reducing the MTU is that the fixed overheads (20 bytes TCP + 20 bytes IP + a couple of bytes for PLIP) eat into your total throughput. You could try timing a couple of big PLIP transfers to calculate your PLIP thoughput and then adjust the MTU so that MTU bytes will take (say) 70% of a clock tick. >> Have you considered using a PPP link running at 115.2kbps instead? >> You will find it a lot more CPU friendly. > >Yes. Not looking forward to buying yet another single-purpose cable. >The null modem I have doesn't seem to do the trick anymore. I don't have problems with standard null-modem cables anywhere. You might have something else amiss. Given that it's a 386, it probably only has a 16450 serial port - I find my laptop can manage 38.4kbps but not 57.6kbps. This means I can get ~3.8KB/sec through PPP compared to 10-15KBps though PLIP. BTW, there may still be some spl mask problems with PLIP. Both SLIP and PLIP have a rather incestuous relationship with both splnet() and spltty(). I'm not sure that the current masking gets it correct. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message