Subject: Re: SparcStation ipx versus Sparc Classic
To: Don Yuniskis <auryn@GCI-Net.com>
From: Greg A. Woods <woods@weird.com>
List: port-sparc
Date: 05/03/2002 15:53:06
[ On Friday, May 3, 2002 at 05:24:18 (-0700), Don Yuniskis wrote: ]
> Subject: Re: SparcStation ipx versus Sparc Classic
>
> But, what it "protects" against shouldn't be a problem.  EIA232 receivers are
> designed to "see" a floating input safely

Well, are you not the one complaining about the problem?  Why don't you
try the fix -- maybe your receivers are not designed correctly....

>   -- note that with nothing plugged
> into the connector, you don't see an endless or intermittent stream of
> "false BREAKS".

It's usually the making of the connection that causes the problem (and
sometimes the disconnect if you pull the plug on the terminal end, not
the host end).

That's just the nature of transmission lines, especially in an
electrically noisy environment....  Use of better cables, with proper
grounding helps.

> Well, there's the rub.  How do you define a BREAK?  Most simplistic
> algorithms just look for 10 or more consecutive SPACES (i.e. receipt of
> ASCII NUL, followed by a framing error and possibly accompanied by a
> parity error -- depending on the parity setting).  As opposed to something
> more definitive (like a "LONG BREAK").
> 
> At higher bit rates, the "10 SPACEs" gets easier and easier to occur
> unintentionally.

Well, yeah, DUH!  :-) -- so don't run your consoles over 19.2kbps, or
even 9600bps!  (you should probably leave themn all at 9600 anyway since
that's likely the default and there are many many advantages to keeping
all like devices at the same speed and at their factory default speed --
just make sure you re-tune their console logging so that it's very
infrequent or even completely off)

> > (the document I quote does claim it will prevent accidental BREAK
> > conditions when a poorly designed terminal device is powered off or on,
> > and obviously it can only do that in some cases, though from what I've
> > seen of such problems these happen to be quite common cases....)
> 
> I have gear that causes the problem if plugged in and powered up...
> or down.

The offending terminal device is poorly designed.  Get rid of it or fix
it.  :-)

>  I have other devices that cause the problem when powered
> *up* and plugged or unplugged (which baffles me since this *should*
> be safe -- unless it's a problem of variations in contact mating sequence).

You're not taking into account the effects of the transmission lines.

> I would much prefer if the "feature" was implemented in a more robust
> manner.

:-)

Well, you could always buy a bunch of converters that convert your
host's console ports to some more reliable physical interface and use
that instead!  :-)

Or you could run permanent console connections to a reliable and well
designed terminal server....  (which is what I do)

>  This, of course, is a subjective assessment on my part.  Though
> when you see products *advertised* as being "Sun-safe", it pretty
> much seems to acknowledge that this is a problem for a LOT of people...
> suggesting that a better implementation would probably have been wiser.

Yeah, well if people always used things in the manner they were intended
by the original designer then there'd be a lot less problems overall... :-)

If you put your machines all in the environment they were designed for,
and if you used your RS-232 serial console connections _only_ in the way
the EIA specs allow for, then you won't likely have any problems.....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>