Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 08:50:36PM -0500, Kirk Strauser wrote:
> On Monday 20 September 2004 07:29 pm, Ross Boylan wrote:
> > I'm not sure who *you* means, but my original thought was that the
> > device driver associated with the port might be using a lot of CPU
> > cycles.
> I think that's exactly what's happening, and I was curious as to why
> others thought that it wouldn't be.
> > So the thing reported as parallel:/dev/lpt0 (or whatever it was) is
> > actually part of CUPS?
> Yep. It it's most likely the kernel accumulating all of that CPU time,
> but since CUPS is the application making the IO request, it gets the blame.
> Is your parallel port running in DMA mode? Mine is, based on dmesg:
> parport: PnPBIOS parport detected.
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
> If it's in a non-DMA mode, then I wouldn't be surprised to see the poor
> performance you're describing. Also, I'd strongly consider migrating to
> using the USB interface if at all possible - it really is much faster
> (and typically better-behaved) than parallel.
parport0: Printer, Lexmark International Lexmark Optra E310
lp0: using parport0 (polling).
parport0: PC-style at 0x378 [PCSPP]
I don't really know what that means, but it apparently has no
interrupts and there's no reference to DMA, just PCSPP. Perhaps I can
tweak my BIOS. Unfortunately, my system is interrupt starved.
The (polling) certainly suggests that I am, umh, polling. Which would
explain the CPU useage. Would this also slow down how fast it takes
to ship stuff out? Printing graphics is painfully slow, e.g., 20
minutes per page (with 300dpi!).
I was under the impression that USB was a bit experimental on Linux,
but I did form that impression awhile ago. Partly as a result of
that, and on a more mundane level, I don't have a USB cable, and I
remember them costing more than a completely trivial amount.