[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial console

"Michael R. Hanulec" <michael.hanulec@xxxxxxx> writes:
> Sean..
> The requested configuration for the Serial Console of:
> "Units must come preconfigured for serial console (9600, N E) usage so 
> we
> can install completely without attaching a monitor and keyboard."
> is what is causing the serial port i/o delays.  This number should be
> bumped up higher, ideally to 115200, in order to kill they various 
> delays
> you are seeing before getting into the bios configuration screen and
> during the Adaptec configuration.
> By default we 'disable' the Quick Boot just so users can see the proper
> amount of RAM installed.  There is no reason it can't be re-enabled 
> would HIGHLY recommend you reevaluate the need for a Serial Connection
> speed of 9600.

Just so that Michael knows, here's what we have or will have in our
operational environment:

servers:			running:	attached to any one of:
dell 1750			bios		solaris sparc + digi sts
western sci			boot code	lantronix (486 speed cpu)
supermicro			linux		regular linux + etherlite
acnc raid			solaris 8	direct to laptop
various solaris sparc boxes

for the terminal server cases, we then have these 4 cases:
local connection via console on terminal server
desktop workstation + ssh
laptop + wireless + ssh
laptop + ssh + dialup connection + portmaster

and then for serial communications programs on the terminal server or laptop
we have several possibilities including:
tip		(which might be running under macos X, windows XP, linux,
conserver	solaris, or openbsd.)

9600 baud is the common denominator that works for us across the board
with all these devices.  For higher baudrates, we have to guarantee
that all of the various permutations of server software, terminal
software, & all the bits inbetween handle flow control right.  If we
want to capture terminal output for later analysis (which we might do
with the "script" and "record" options in tip, or with the "-u" option
with conserver) then we also have to guarantee that only a manageable
amount of data is produced.  (I've used this to capture output that
changes too rapidly for me to type it in.  Also we have "risk
management" people here (combination lawyer-insurance type people) who
would probably be overjoyed if we could log all console interactions on
our machines.)

We can certainly check to see what higher speeds will do, but I'm quite
dubious, for instance, that a lantronix terminal server which is 486
based can keep up with the interupt rate resulting from multiple
servers (maybe even just one) all spewing data at 10k cps+.
We've already noticed that ssh itself eats a lot of CPU on the lantronix.
Of course, even with perfect flow control, a 33k dialup session
simply can't refresh a screen as often as a 115K direct connection.
So that means at best we'd still be frequently looking at reduced data
rates and screen update rates from the bios, even with your suggested

For what it's worth, none of us here are especially overjoyed with the
type of full-screen bios programs most x86 hardware comes with these
days.  We already miss the command line interface that our solaris
boxes have for firmware.  There actually is x86 hardware that does
contain a serial bios that looks to be much closer to what we would
like, made by Soekris, but they're aiming for the small embedded
controller market and don't make large or fast servers.  We'd also be
very interested in openfirmware on x86 hardware (see

				-Marcus Watts
				UM ITCS umce