Mailing List Archive

perle jetstream settings
Folks,

I'm a long-time conserver user, and a long-time terminal-server user,
but this is the first time I've used conserver with a terminal-server.
We're setting conserver up to connect to a Perle JetStream 8548 in
reverse-telnet mode. Our console master host platform is Solaris-10
on both Sun Blade 150 and also Solaris-10_x86 on a P4 PC.

One thing I've noticed is that reverse telnet connections seem to have
very bursty output on this unit. Instead of a steady stream of characters
that a direct (hardwired) serial connection gives, you get a batch of
characters (maybe 4-5 lines of text) in a quick burst, pause, then another
batch, etc. This happens when using both conserver and plain old telnet
to connect to a port, so it's nothing wrong with conserver itself.

As I said, I've used terminal servers for years, but this is my first
experience with the JetStream product. We also have an old IOLAN+ Rack
unit, and the IOLAN+ does not exhibit this bursty output behavior, even
when given the same serial-line output from identical hardware. The Perle
seems to behave the same when the port is in "reverse raw" mode and conserver
is set with the "protocol raw" option to match.

We're running ports at 9600bps almost without exception, and no serial
flow control is in effect at this time. Network gear is all switched
10/100, operating at 100Mbps (except for the IOLAN+). I'm wondering if
folks have guidance as to settings that one can tune on either the
JetStream or on the Solaris side to give smoother serial output with
this arrangement.

Thanks and regards,

Marion



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
RE: perle jetstream settings [ In reply to ]
I've played with the Rack+ units, and not the JetStream...

If you have bursty traffic, it sounds like it's the JetStream, based
on what you have said. (You indicated that the Rack+ doesn't exhibit the
symptom when connected to the same serial ports, if I understand you
correctly.) Here's a few things to think about and try;

You may find a serial setting, but it may also be that the CPU of the
JetStream can't keep up with the high rates during prolonged bursts.
Another option is that the serial rate may be too slow, and the CPU is
time-slicing to check all of the other ports before getting back to the
next batch from the busy port(s).

You could try to increase the serial port speed on the JetStream and
the serial console you conenct to, and see if the JetStream can keep up.
(Do you have cabling to support hardware flow control? In the cable and
the adapters? Are the serial ports on both devices set to use the flow
control? If not, a higher speed may incur some data loss, because you
may overfill the UART buffers with the higher data rate.)

If the higher data rate works, it may indicate that the JetStream has
an issue polling the various ports. This could point to an issue
handling the interrupts from the UARTs, or servicing a busy network
interface. (Are you attaching the JetStream to a switch port, or a busy
hub?)

-Z-

-----Original Message-----
From: users-bounces@conserver.com [mailto:users-bounces@conserver.com]
On Behalf Of Marion Hakanson
Sent: Friday, August 11, 2006 2:31 PM
To: users@conserver.com
Subject: perle jetstream settings

Folks,

I'm a long-time conserver user, and a long-time terminal-server user,
but this is the first time I've used conserver with a terminal-server.
We're setting conserver up to connect to a Perle JetStream 8548 in
reverse-telnet mode. Our console master host platform is Solaris-10 on
both Sun Blade 150 and also Solaris-10_x86 on a P4 PC.

One thing I've noticed is that reverse telnet connections seem to have
very bursty output on this unit. Instead of a steady stream of
characters that a direct (hardwired) serial connection gives, you get a
batch of characters (maybe 4-5 lines of text) in a quick burst, pause,
then another batch, etc. This happens when using both conserver and
plain old telnet to connect to a port, so it's nothing wrong with
conserver itself.

As I said, I've used terminal servers for years, but this is my first
experience with the JetStream product. We also have an old IOLAN+ Rack
unit, and the IOLAN+ does not exhibit this bursty output behavior, even
when given the same serial-line output from identical hardware. The
Perle seems to behave the same when the port is in "reverse raw" mode
and conserver is set with the "protocol raw" option to match.

We're running ports at 9600bps almost without exception, and no serial
flow control is in effect at this time. Network gear is all switched
10/100, operating at 100Mbps (except for the IOLAN+). I'm wondering if
folks have guidance as to settings that one can tune on either the
JetStream or on the Solaris side to give smoother serial output with
this arrangement.

Thanks and regards,

Marion



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: perle jetstream settings [ In reply to ]
david.k.harris@siemens.com said:
> If you have bursty traffic, it sounds like it's the JetStream, based on
> what you have said. (You indicated that the Rack+ doesn't exhibit the symptom
> when connected to the same serial ports, if I understand you correctly.)

Yes, both units are connected to the LOM ports on identical Sun V120's.


> You may find a serial setting, but it may also be that the CPU of the
> JetStream can't keep up with the high rates during prolonged bursts. Another
> option is that the serial rate may be too slow, and the CPU is time-slicing
> to check all of the other ports before getting back to the next batch from
> the busy port(s).

We're running at the V120 default serial settings 9600bps, 8/N/1, no flow
control running at all. Haven't seen signs of lost characters, so the
"CPU too slow" scenario seems unlikely, especially at these speeds.


> If the higher data rate works, it may indicate that the JetStream has an
> issue polling the various ports. This could point to an issue handling the
> interrupts from the UARTs, or servicing a busy network interface. (Are you
> attaching the JetStream to a switch port, or a busy hub?)

Nothing's busy yet; Just one serial port for testing so far, and it's
a switched 10/100 network with not much going on.

When I asked about tuning, I was wondering if there wasn't a poll-type
setting which could be changed. Given the low-speed nature of this
environment, going to a more interrupt-driven scenario in order to get
smoother output would be an acceptable trade-off.

Cabling, adapters, and V120's are capable of doing CTS/RTS flow control,
so I'll see about trying higher port speeds to see if things go a little
more smoothly. Maybe with flow-control enabled the JetStream will use a
different algorithm, or as you said, the faster baud rate may just make it
work harder and/or poll faster.

Thanks and regards,

Marion



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: perle jetstream settings [ In reply to ]
> Cabling, adapters, and V120's are capable of doing CTS/RTS flow control,
> so I'll see about trying higher port speeds to see if things go a little
> more smoothly.

At 38.4kbps, output looks smoother. The pauses are still there between
bursts of output, but less noticeable.


> Maybe with flow-control enabled the JetStream will use a
> different algorithm, or as you said, the faster baud rate may just make it
> work harder and/or poll faster.

Flow control didn't seem to come into play at 38.4kbps. No sign of
lost characters, even with no flow control enabled.

BTW, is it just me, or does Sun do hardware flow control strangely? Given
your experience, you're probably aware of this, but I've just discovered
that the RJ45-DB9 adapter that Sun supplies with their gear (530-3100-01)
is just plain weird. It swaps the TXD and RXD wires (as a null-modem does),
but is otherwise straight through for all the control signals (RTS-RTS,
CTS-CTS, etc.). A full null-modem arrangement (like the APACN 24490-71,
but with Perle JetStream pin-outs on the left instead of IOLAN) doesn't
let the data flow.

Thanks and regards,

Marion



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users
Re: perle jetstream settings [ In reply to ]
hakansom@ohsu.edu said:
> BTW, is it just me, or does Sun do hardware flow control strangely? Given

OK, it's just me. Turns out I hadn't noticed the DCE label on the
diagram which I was comparing to a DTE diagram. Sigh.


> Flow control didn't seem to come into play at 38.4kbps. No sign of lost
> characters, even with no flow control enabled.

One last datapoint: Perle has their TruePort device driver which gives
real Solaris tty's, over the network to ports on the JetStream box. I gave
this a try with conserver, and found the same delayed-bursty output behavior
at 9600bps as when using reverse telnet. So it seems inherent in their
buffer-polling code.

Thanks for the guidance.

Regards,

Marion



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users