Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.i386
Subject: Re: Slow printing in 386/ix
Message-ID: <9798@alice.UUCP>
Date: 20 Aug 89 20:26:47 GMT
References: <1989Aug10.191352.8363@esegue.uucp>
Reply-To: debra@alice.UUCP ()
Distribution: usa
Organization: AT&T, Bell Labs
Lines: 48

In article <1989Aug10.191352.8363@esegue.uucp> johnl@esegue.UUCP (John Levine) writes:
>I am running 386/ix 2.0.2 on a 25MHz Intel clone, to which I have attached
>an HP Deskjet printer with the usual parallel interface.  It works, but the
>printer runs at a small fraction of the speed at which it runs when I'm
>running DOS.
>
>I suspect the problem is this:
> [ long explanation deleted ]

Most device-drivers are a combination of interrupt-driven and polling drivers.
Normally the device (parallel interface in this case) causes an interrupt
when it is ready to accept a character. The kernel handles the interrupt
(by sending a character to the interface, or by remembering that the device
is ready) and goes back to doing whatever it was doing. When the interface
has sent the character to the printer and the printer is ready for the next
character the interface will again generate an interrupt. This is interrupt-
mode behaviour.
Normally, the kernel also checks (at some rate, which may well be the HZ
rate) whether the interface is ready (by peeking at a status register).
This is done because interrupts may be lost during higher priority interrupts.
This is polling behaviour.

In some cases the time between sending the character to the printer and the
printer indicating it is ready always results in the kernel missing the
interrupt. In that case the kernel does recover using the polling scheme,
but will only print HZ characters per second. I actually experienced this
on a combination of an AT-clone and an Epson MX100 printer. At cpu-speeds
of 8 and 10 Mhz printing was slow. At 9 Mhz (i changed the cristal) printing
was normal.

One feasible solution is to write your own device driver which only does
polling. It must not just send a character when the printer is ready, but
then enter a short busy loop in which it waits for the interface to be
ready again. If the interface is ready in time, the kernel sends another
character, and loops again... If the interface is not ready in time the
kernel gives up and tries again at the next clock tick. Such a device driver
is a real cpu hog because of the busy loops. When my AT was printing
bitmaps the device driver would consume up to 50% of the cpu-time.
But printing was fast.

Hope this sheds some light on the issue.

Paul.

-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------