Subject: Re: Parallel port CPU hog (was: Disk driver related problems?)
To: Mark White <mark.white@st-edmund-hall.oxford.ac.uk>
From: Steven M. Bellovin <smb@research.att.com>
List: port-i386
Date: 11/21/2000 09:01:19
In message <20001121125321.A2676@st-edmund-hall.oxford.ac.uk>, Mark White write
s:
>Richard Rauch writes:
>> You mention that accessing the parallel port causes CPU strain (oddly you
>> mention this under ``DMA problems''; as Manuel said, I don't think that
>> NetBSD provides DMA to the parallel port).
>
>Ok; I suppose that means being stuck with ECP.  But, running
>ECP under (say) debian, I don't get the slowdown problem.
>Which means, as you say, that there are probably fewer
>interrupts going on, either because of H/W or S/W buffering.
>
>I'd had it classified as 'DMA problem' because when I first
>tried to get printing working on NetBSD I had EPP enabled,
>and the machine froze when spooling began.  (Infact died
>violently; the X display even got completely messed up.)
>
>> (I assume that this works for more than just printers, but the person
>> commenting on this was using it for a printer.  I almost got one for
>> myself, but I really don't do that much printing.)
>
>There must be a reasonably large number of poeple who do use
>printing from NetBSD, though?  It's manageable for a
>workstation, but if you tried to hook a printer to a server
>type machine this would be a serious problem...

I'm far from an expert on parallel ports, but I recall reading that 
using the polling version of the driver was faster, and generated lower 
CPU loads.  On my system, I've found that /dev/lpa0 works much better 
than /dev/lpt0.  Which are you using?

		--Steve Bellovin