info-3b2@lamc.UUCP (Info-3b2 Mailer) (02/03/89)
Info-3b2 Digest, Number 56
Thursday, February 2nd 1989
Today's Topics:
Darn piggies (FINGERS!)...Re: EPORTS/HP
Re: problem with EPORTS card
Re: problem with EPORTS card
Re: problem with EPORTS card
3BNET & PC's
----------------------------------------------------------------------
Subject: Darn piggies (FINGERS!)...Re: EPORTS/HP
Date: 28 Jan 89 18:15:30 EST (Sat)
From: root@oid.UUCP (Admin-P.L. Aeten)
Looks like my fingers think faster than I can write. Recently
I responded to an HP to EPORTS problem and what I said at least
in the opening paragraph, dribbled out and might be misinterpreted.
The entire monologue follows with the changes indicated.
I am truly sorry for the error! (Shhhhhh fingers, bad fingers).
Subject: Re: problem with EPORTS card
To: info-3b2
Date: Sat, 28 Jan 89 8:29:53 PST
From: Info-3b2 Mailing List <info-3b2@lamc>
Bcc: info-3b2-bulk
Organization: Info-3b2 Mailing List
Reply-To: info-3b2@lamc.UUCP
Errors-To: info-3b2-request@lamc.UUCP
X-Mailer: Elm [version 2.0 gamma]
Message-Id: <8901280829.AA12821@lamc.UUCP>
Status: R
Forwarded message:
To: info-3b2@lamc.UUCP
Subject: Re: problem with EPORTS card
Message-Id: <8901280754.AA02080@oid.UUCP>
Date: 28 Jan 89 07:54:14 EST (Sat)
From: root@oid.UUCP (Admin-P.L. Aeten)
Hi,
Having limited knowledge about the HP and of the general machine
[3B2] setup makes it difficult to analyze the problem. But let me
place some ideas forward.
>We recently moved a HP laserjet+ printer from a 3B2 PORTS card to an EPORTS
>card. Running off the EPORTS card is generating a high number of
>error 22s from the laserjet. We are using the standard black modular cable
>and the terminal/printer connector. Do the EPORTS card require a different
>type of modular connector?
>
First, unless the HP needs to indicate "potential overrun" by dropping
an interface tag (DTR) and re-activate this line when the condition
has passed I'd say the standard "black cable" and Terminal/printer
adapter will suffice. *In which case XON/XOFF is normally employed. If
hardware signals (either DTR or CTS) are needed to "throttle" data
transmission then clearly the Terminal/Printer connector and various
EPORTS, HP and LP Spooler options need to be reconsidered. In a nutshell the Terminal/Printer adapter will either need to be rewired or the correct one
can be orderd (I'd opt for the rewire....Details on request)**
[Was this the case presented recently? If it is I noted that the HP
was set-up for "half dux" operation, if so change it to "full"]
The EPORTS is given its nature is quite a decent "piece" of hardware.
Because of this it is important to give some thought to how it inter-
acts with the 3B (Software wise). Some things to consider:
Check to see that you are useing EPORTS Driver Rel 1.2
NCLIST= /* found in /etc/master.d/kernel */
Check your model in lp and make sure your 'stty' options
are correct for your arrangement.
Check Kernel parameters. Especially now since you state this cond-
ition is more frequently manifested on a boggy (read BUSY) machine.
RE: NCLIST
If too low then characters (data) can be lost without the users know-
ledge.
Other system tuneables can affect the overall performance of the
system which might show as a boggy performance to a user but affects
attached hardware exhibiting then inconsistent operation.
(BTW what is an error 22?: Sounds as if you were receiving these but
to a lesser degree pre EPORTS????)
>Thanks
>Bob Sanderman
>att!mhuxu!rs
This problem is documented in the EPORTS manual. It has to do
with slow XON/XOFF processing on the EPORTS boards.
When the Laserjet's buffer fills up, it sends an XOFF to the
EPORTS board. The EPORTS board will not react immediately, but
will continue sending data for about 60 ms. This is too
long for some printers, ie for the Laserjet.
This skid is well known and is exacerbated if your baud rate is high.
I am unawre of how to fix this but have heard it has been. Others?
A solution would be to use a PORTS board or the contty port,
^^^^^^^^^^^
Not a reasonable solution given that both the console and contty
port should not be used for "production" at high speeds.
Character processing results in high interrupt levels and therefore
software intervention, can result in even poorer performance. In this
case hi-BPS/HP (control and data) streams can be viewed as sustained
(versus bursty) and therefore a problem.
or to use hardware flow control (see the EPORTS manual).
---
Pim Zandbergen | phone: +31 70 542302 | CTI Software BV
--
Not a bad suggestion.
I'd be willing to expand on these issues if you like and provide
some help if needed.
Good Luck!
Peter
P. L. Aeten
{attmail!}bacyn!paeten -o {att,dsinc,netsys,}!aeten@oid
[215-581-4444]
--
------------------------------
From: Pontus Hedman <hoptoad!sq.sq.com!rph>
Subject: Re: problem with EPORTS card
Date: Sun, 29 Jan 89 13:39:46 EST
>>Ch. Gnd 1 ----------------------------- 1 Chassis Ground
>
> NO, NO, NO. Chassis ground (shield) should never be connected on both
> ends. A current carrier (which this becomes due to differences in
> ground potential) is not a shield.
Quite true, but for purposes of preventing a ground loop it often makes
no difference if you leave this connection out or not.
A 3B2/400 ports card connects frame ground (pin 1) and signal ground
(pin 7) *internally*, as do most terminals. Consequently pin7 == pin1
and you have a ground loop whether you like it or not.
This "feature" is a real pain to work around.
--
Pontus Hedman rph@sq.com {utzoo|utgpu}!sq!rph
------------------------------
Subject: 3BNET & PC's
Date: 2 Feb 89 10:02:30 CST (Thu)
From: hoptoad!iquery!matt (Matt Reedy)
I'm getting ready to buy a 3BNET Ethernet card for our 3B2 to network with
several MS-DOS PC's, initially using TCP/IP, later NFS. I have a couple
of questions for those using the 3BNET stuff in this kind of environment.
I'm assuming the 3BNET is thinwire (coax), is this right?
What exactly does the 3BNET software that I have to buy with
the card do for me?
Sources for TCP/IP for the 3B2? (Wollongong, Lachman, etc.)
Practical experiences, problems, successes, etc. are welcome.
Many thanks.
matt
Matthew Reedy UUCP: gatech!petro!iquery!matt
Programmed Intelligence Corp.
400 N Loop 1604 E, Suite 330
San Antonio, TX 78232 (512) 490 6684
-------------------------------------
To join this group or have your thoughts in the next issue, please
send electronic mail to Ken Davis at the following address;
{pacbell,netsys,hoptoad,well}!lamc!info-3b2-request
The views expressed in Info-3b2 Digest are those of the
individual authors only.
*********************
End of Info-3b2 Digest
*********************