On Thu, 23 Aug 2001, Philip Blundell wrote:
> >My guess is that the parport sharing code is causing some sort of
> >bottleneck which is only showing up on the slow 486. When the laptop is
> >using the 2.0.3 PLIP code (no parport sharing), it communicates fine with
> >the PIII which is using the more modern PLIP (sharing) code.
> I doubt this is the problem. The parport sharing code isn't *that*
> Does PLIP think it's using interrupts? (Check with dmesg.) It might be
> falling back to polled operation, which always brings a large performance hit.
Apologies for the late reply. I decided to replace my home-made parallel
cable with a bought one, just in case it was causing problems. It wasn't,
the results are exactly the same with the bought cable.
There's a very interesting pattern to the failures; perhaps the timings
will ring a bell with someone? Anyway, a quick recap. I have got a 2.4.2
kernel on my PIII (RedHat 7.1) which will communicate perfectly across
PLIP with a 2.0.3 kernel on my 486 laptop. Specific tests include a 1
second ping time of 6 ms, successful flood pinging and continuously
successful 0.001 s interval pinging.
On replacing the kernel on the laptop with either a 2.4.7 kernel or a
2.2.19 with PLIP compiled as a module, I get very strange results.
The ping time starts off as 9 ms (as opposed to 6), then with a
periodicity of about 25 seconds, cycles slowly up and down between 9 ms
and 25 ms. Weird or what?
If I do a flood ping, it starts dropping packets very quickly. If I ping
-i 0.001, I quickly get 400 ms response times and many dropped packets.
On the dmesg output on the laptop, and on the ifconfig output, the module
is definitely using interrupts.
I've compiled these kernels myself, and am wondering if there is any
possibility that something I have left out or put in has caused this
problem? I've had to make the kernel fairly minimal to get it to run on
the laptop. The only relevent things I've delibrately included are
parport, parport_pc and plip.
PS Does anyone knwo what the message "Warning: time of day goes back,
taking countermeasures" means? I get it on the PIII a few seconds after
initiating a ping sequence. This happens even on the 2.0.3 kernel which
works perfectly for PLIP.
PPS The root filesystem on the laptop when I'm using the newer kernels is
the contents of the color.gz disk from Slackware 8.0, which is mainly
intended for installations, not real use; could this be related? My
intention is to use PLIP and this installation to install more of the OS.
-- Ian Hinder firstname.lastname@example.org
-- To unsubscribe, send mail to: email@example.com -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Aug 30 2001 - 19:10:50 EDT