HP3000-L Archives

December 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dave Darnell <[log in to unmask]>
Reply To:
Dave Darnell <[log in to unmask]>
Date:
Wed, 27 Dec 2000 08:49:57 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (148 lines)
Sorry,

before I get jumped on, that's IEEE-488, not 448!

-dtd

> -----Original Message-----
> From: Dave Darnell
> Sent: Wednesday, December 27, 2000 8:44 AM
> To: [log in to unmask]
> Subject: RE: HBIB vs 19.2kbps speed?
>
>
> 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)
> >
>

ATOM RSS1 RSS2