HP3000-L Archives

October 1997, Week 1

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:
Roy Brown <[log in to unmask]>
Reply To:
Roy Brown <[log in to unmask]>
Date:
Tue, 7 Oct 1997 13:43:16 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
In article <[log in to unmask]>, Albert Greene <[log in to unmask]>
writes
>I'm using 16 channel multiplexors to connect users at a remote location
>to our HP3000.  The multiplexors have an aggregate max burst rate of
>115,200bps.  I have 2 printers and 4 terminals all communicating at 9600
>bps.  My problem is that I can only have 3 of the terminals logged on at
>one time - any 3 of the 4 but not 4 at one time.

How exactly does this inability manifest itself? Can't even log on,
unacceptable performance, or what?

 AIUI, adding more load to a mux should just make performance more
'jerky' for the users already on. I.e. a gradual degradation, not
falling off a cliff.

It is a stat mux, isn't it?

>  The phone line is a
>dedicated 9600 baud line.  On the surface it appears that the phone line
>is the limiting factor.

Probably - if six links all want 9600 all the time, each will get an
average of only 1800 bps.

However, if the total traffic is light, and the usages are staggered,
each may never know that they haven't got a dedicated 9600 line of their
own. Generally not the case; everyone wants 100% throughput just before
that 4.00pm shipping deadline!

>  My understanding is that the muliplexor is
>sending individaul packets of information.

On Classics, muxes that knew about and could spoof ENQ/ACK could shift
data a lot faster than those that didn't, by reducing end-to-end
transmission and turnround delays. This was usually sold as 'HP Protocol
Assist' or some such, in the dear dead days when 'HP computer' meant
'HP3000' and no question (if you were muxing).

PA-RISC boxes don't use ENQ/ACK, unless you've left it on by accident,
in which case turn it off at once and watch throughput rise. But there
are, or were, optimisations muxes could use.

>  I would guess that a faster
>line would therefore increase total throughput and allow me to add more
>terminals - adding more terminals and printers is my ultimate goal.

Do you know what the actual line traffic is like at present?

>Am I headed in the right direction or missing the whole concept?

Yes, and no, in that order.
>
>Any help would be appreciated,
>Albert Greeene
>Interstate Van Lines, Inc.
>(703) 569-2121 ext. 440

--
Roy Brown               Phone : (01684) 291710     Fax : (01684) 291712
Affirm Ltd              Email : [log in to unmask]
The Great Barn, Mill St 'Have nothing on your systems that you do not
TEWKESBURY GL20 5SB (UK) know to be useful, or believe to be beautiful.'

ATOM RSS1 RSS2