This may have been answered clearly, but since I'm scanning a few days worth
of messages, I'll just throw it in.

IEEE-448 / GP-IB / HP-IB is a byte- or word- at-a-time interface (like
parallel) with hardware handshaking, so it can be very fast.  Printers on
RS-232 are usually configured with software handshaking using XON/XOFF or
ENQ/ACK handshaking, which can slow things down quite a bit, especially if
there are higher latency (ping) times between the host and the printer.  On
older/slower printers at higher baud rates, XON/XOFF characters (my buffer
has room / my buffer is almost out of room) might not reach the host in time
to avoid a buffer overrun, so they need to be configured at much slower baud
rates.  These problems can be exacerbated by the use of PVCs (permanent
Virtual Circuits - emulation of a serial connection over a network.)

Changing an RS-232 printer connection to hardware handshaking might speed up
the printer quite a bit, depending on other conditions.  I seem to remember
some problem trying to eliminate the XON/XOFF when using hardware
handshaking, but that might have been for terminal connections rather than
printers.

-Dave

> -----Original Message-----
> From: Jeff Woods [mailto:[log in to unmask]]
> Sent: Tuesday, December 26, 2000 3:12 PM
> To: [log in to unmask]
> Subject: Re: HBIB vs 19.2kbps speed?
>
>
> Tracy Pierce asked:
> >>We recently switched our line printer from HPIB to serial at
> >>19,200bps.  When printing spooled output, any IO rate
> difference goes
> >>unnoticed, but for "hot" jobs, the actual printing rate is
> about half as
> >>fast as it used to be using HPIB.
> >>
> >>Is/was HPIB really twice as fast as 19.2?
>
> Much faster than 19.2 kbps!  IIRC (not a given), HP-IB is
> somewhere in the
> neighborhood of 1 mbps... but I don't recall if that's bits
> or bytes in
> this instance.  19.2 kbps is "k bits per second".
>
> At  02:28 PM 12/26/00, Wirt Atmar replied:
> >HP-IB is significantly/substantially/enormously faster than
> 19.2 Kbps, but
> >because your target device is a printer, you wouldn't
> ordinarily see that
> >difference. The printer just lops along at its own pace. It
> couldn't go any
> >faster if you had a T1 line into the device.
> >
> >However, 19.2Kbps should also be much faster than the
> printer, thus you
> >shouldn't see any difference at all between the two forms of
> connection if
> >you're just watching the paper move through the printer.
> Both transport
> >mechanisms should keep the printer's buffer completely full
> at all times
> >while a spoolfile is being directed to the printer.
>
> Actually, 19.2 kbps serial connections can easily be outrun
> by a fast line
> printer.  I believe some of the 256x models could print at
> 1200 or 1600
> lines per minute.  And while 132 columns of text is the
> "norm" for such a
> printer, it's possible to print 200 or more characters per
> line in some
> instances.  Also, there's a certain amount of overhead handling
> flow-control, CCTL and other printer formatting (font
> selection and such)
> but that's likely to be small on a 256x printer anyway and
> I'm going to
> completely ignore it.
>
> 19.2 kbps serial connection is 2400 bytes per second.  If your average
> print line is 132 bytes long, that's less than 18.2 lines per
> second which
> converts to less than 1092 lines per minute.  Of course, if
> your average
> line length is longer than 132 characters, it would be even
> slower.  And
> any additional overhead I've ignored will only slow the
> aggregate print
> speed down further.
>
> It's likely that the serial link isn't quite keeping up with
> the printer
> and much of the lag in throughput is handshaking acknowledgements, but
> that's just a guess.  In any case, a faster connection could
> very plausibly
> increase the speed of the printer back to its rated capacity.
>  Again IIRC,
> if the dataflow isn't keeping up with the print head, the printer will
> constantly fall in and out of printing... and the 256x printers take a
> short but significant amount of time to "spin up" to begin
> printing.  That
> means that I would expect a slight lack of datacomm bandwidth
> (just enough
> to tend to keep the printer buffer empty instead of full)
> would cause a
> dramatic decrease in the print speed.  It's very similar to a
> streaming
> tape drive which isn't getting data fast enough to stay
> streaming.  The
> overhead of starting and stopping can very easily begin to consume a
> substantial portion of the potential throughput.
>
> >If you're seeing a difference between the two print speeds,
> it can only be
> >due to one of several conditions:
>
> [snipped Wirt's additional comments on what might also be
> compounding the
> problem]
>
> --
> Jeff Woods
> [log in to unmask] (preferred for personal posts)
> [log in to unmask] (present professional position)
> [log in to unmask] (portable & permanent, but problematic)
>