Date: Tue, 01 May 2001 15:03:49 -0700 From: John Merryweather Cooper <jmcoopr@webmail.bmi.net> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@FreeBSD.ORG> Subject: Re: problem with plip stealing clock Message-ID: <3AEF32C5.F36D2EE3@webmail.bmi.net> References: <3AED84DB.8D241BCF@webmail.bmi.net> <20010501171807.M59150@gsmx07.alcatel.com.au> <3AEED69E.F6EC1EAD@webmail.bmi.net> <20010502072950.N59150@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > > 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. > I'm going to try to slash the MTU way down from 1500 first. If that doesn't do it, I'll be interested in enabling the "interrrupt per nibble" approach. Note, the lap top has no problems with it's clock; it's the Duron 700 (doing most of the transmitting--since I was installing packages from 4.2-RELEASE onto my laptop) that gets the major slowdown in the clock. > 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. Yes, ultimately, I think that is necessary. With the ever-increasing CPU speed, this little problem with plip is likely to get worse in the future. > >> 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. > Didn't have a null-modem cable--I had an old-old null modem connector for 25-pin serial interfaces. This is the first time I've used it and it wouldn't work. Tried it at every bit rate possible--no dice--probably something not quite right in its cross-over--or it may be damaged (I've moved since last using it). You are correct that the laptop has 16450 UART's. I was averaging 19.2KB/sec with MTU set to 1500 (but with the clock slowing effects on the Duron). > 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. Hmm, I'll have to take a look at that code--didn't realize plip and slip shared code (seems logical though). jmc > 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?3AEF32C5.F36D2EE3>