Date: Wed, 02 May 2001 07:29:50 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: John Merryweather Cooper <jmcoopr@webmail.bmi.net> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@FreeBSD.ORG> Subject: Re: problem with plip stealing clock Message-ID: <20010502072950.N59150@gsmx07.alcatel.com.au> In-Reply-To: <3AEED69E.F6EC1EAD@webmail.bmi.net>; from jmcoopr@webmail.bmi.net on Tue, May 01, 2001 at 08:30:38AM -0700 References: <3AED84DB.8D241BCF@webmail.bmi.net> <20010501171807.M59150@gsmx07.alcatel.com.au> <3AEED69E.F6EC1EAD@webmail.bmi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-May-01 08:30:38 -0700, John Merryweather Cooper <jmcoopr@webmail.bmi.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010502072950.N59150>