Hi folks

When I type "stty -a" on my terminal emulator the output
includes something like "speed nnnnn baud" where nnnnn is
a number. I have been wondering for some time what this
means in the context of a terminal emulator running on
top of X-windows. I understand what it means if you have
a physical terminal connected with the computer and the
computer transmits characters to the terminal which the
terminal displays. But when you are running X-windows then
the computer controls the display on the pixel level so
I can't imagine what the baud rate stands for. I hope I'm
making myself clear.

So the first question is whether the baud rate has any
physical significance when you're running a terminal
emulator on top of a windows system. Does it mean that
bits get transmitted at a specific rate from some part of
the hardware to some other part of the hardware ?

The second question is whether this baud rate is important
for any programming tasks.

Cheers
Spiros Bousbouras

[ Post a follow-up to this message ]

"spibou@gmail.com" <spibou@gmail.com> writes:

> Hi folks
>
> When I type "stty -a" on my terminal emulator the output
> includes something like "speed nnnnn baud" where nnnnn is
> a number. I have been wondering for some time what this
> means in the context of a terminal emulator running on
> top of X-windows. I understand what it means if you have
> a physical terminal connected with the computer and the
> computer transmits characters to the terminal which the
> terminal displays. But when you are running X-windows then
> the computer controls the display on the pixel level so
> I can't imagine what the baud rate stands for. I hope I'm
> making myself clear.
>
> So the first question is whether the baud rate has any
> physical significance when you're running a terminal
> emulator on top of a windows system. Does it mean that
> bits get transmitted at a specific rate from some part of
> the hardware to some other part of the hardware ?

No, it is meaning less in this context.


> The second question is whether this baud rate is important
> for any programming tasks.

Well, you could choose to issue shorter messages when the speed is
less than 1200 b/s.  Other than that, it's even less important that it
has meaning in the context of xterm.

--
__Pascal Bourguignon__                     http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

[ Post a follow-up to this message ]

spibou@gmail.com wrote On 06/19/06 16:55,:
> Hi folks
>
> When I type "stty -a" on my terminal emulator the output
> includes something like "speed nnnnn baud" where nnnnn is
> a number. I have been wondering for some time what this
> means in the context of a terminal emulator running on
> top of X-windows. I understand what it means if you have
> a physical terminal connected with the computer and the
> computer transmits characters to the terminal which the
> terminal displays. But when you are running X-windows then
> the computer controls the display on the pixel level so
> I can't imagine what the baud rate stands for. I hope I'm
> making myself clear.
>
> So the first question is whether the baud rate has any
> physical significance when you're running a terminal
> emulator on top of a windows system. Does it mean that
> bits get transmitted at a specific rate from some part of
> the hardware to some other part of the hardware ?

Bits are certainly being sloshed around, and perhaps
one could work backwards from "screen speed" to "equivalent
communications link speed," but I don't think the reported
rate has much to do with anything.  (FWIW, I believe the rate
is reported by the pty and not the terminal emulator per se.)

> The second question is whether this baud rate is important
> for any programming tasks.

Yes: Some chunk of software that queries the terminal
characteristics and perhaps changes them is going to want to
see some sort of plausible baud rate.  It's one of the jobs
of the emulator to "emulate," meaning that software that asks
for the baud rate should get an answer and not an error.  It
probably makes sense to report a reasonably high rate, in
case the software says "Oh, 110 baud, too bad: I'll use my
terse CLI mode because nobody's going to wait for my fancy
menus on so slow a line."

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

Pascal Bourguignon <pjb@informatimago.com> wrote:

> Well, you could choose to issue shorter messages when the speed is
> less than 1200 b/s.  Other than that, it's even less important that it
> has meaning in the context of xterm.

xterm sets it to 38400 because many people set $TERM to "vt100", which
commonly has padding in the terminal description, causing curses and
similar applications to run slowly.

so it's relevant - but cause and effect are reversed here...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[ Post a follow-up to this message ]

In article <129egir1dn9i8d5@corp.supernews.com>,
Thomas Dickey <dickey@saltmine.radix.net> wrote:

> Pascal Bourguignon <pjb@informatimago.com> wrote:
> 
>
> xterm sets it to 38400 because many people set $TERM to "vt100", which
> commonly has padding in the terminal description, causing curses and
> similar applications to run slowly.

Shouldn't it then set it to a SLOW speed?  If you have a faster line,
you need to send more padding characters to avoid going too fast for an
old, slow terminal.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <129egir1dn9i8d5@corp.supernews.com>,
>  Thomas Dickey <dickey@saltmine.radix.net> wrote: 
[vbcol=seagreen]
> Shouldn't it then set it to a SLOW speed?  If you have a faster line,
> you need to send more padding characters to avoid going too fast for an
> old, slow terminal.

The reason for padding is for real vt100's which would lose characters
is given too fast.  That problem does not affect xterm

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[ Post a follow-up to this message ]

In article <129fpsthgt08d7f@corp.supernews.com>,
Thomas Dickey <dickey@saltmine.radix.net> wrote:

> Barry Margolin <barmar@alum.mit.edu> wrote: 
> 
>
> The reason for padding is for real vt100's which would lose characters
> is given too fast.  That problem does not affect xterm

I know.  But I thought he was saying that xterm sets the baud rate to
38400 for the sake of code that doesn't realize it's sending to an
xterm, but thinks it's sending to a real vt100.  So if you want to keep
them from sending lots of unnecessary padding characters, the baud rate
should be set to something really low, like 110.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <129fpsthgt08d7f@corp.supernews.com>,
>  Thomas Dickey <dickey@saltmine.radix.net> wrote:
 
[vbcol=seagreen]
> I know.  But I thought he was saying that xterm sets the baud rate to
> 38400 for the sake of code that doesn't realize it's sending to an
> xterm, but thinks it's sending to a real vt100.  So if you want to keep
> them from sending lots of unnecessary padding characters, the baud rate
> should be set to something really low, like 110.

not exactly.  I forgot to mention that ncurses has a related optional featur
e
to tell it to not emit nulls (and with that in the back of my mind, was
responding obliquely).  There's a tradeoff though:  if you set the baudrate
very low, then curses will of course assume padding characters use larger
chunks of time. But it will also choose escape sequences which do not contai
n
that "expensive" padding in preference to "cheap" sequence.  The result is
often about as bad...

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

[ Post a follow-up to this message ]

spibou@gmail.com <spibou@gmail.com> spewed this unto the Network:
> Hi folks
>
> When I type "stty -a" on my terminal emulator the output
> includes something like "speed nnnnn baud" where nnnnn is
> a number. I have been wondering for some time what this
> means in the context of a terminal emulator running on
> top of X-windows. I understand what it means if you have
> a physical terminal connected with the computer and the
> computer transmits characters to the terminal which the
> terminal displays. But when you are running X-windows then
> the computer controls the display on the pixel level so
> I can't imagine what the baud rate stands for. I hope I'm
> making myself clear.

Your shell is connected to the xterm via a simulation of a
serial line called a "pseudo-terminal," or pty. Basically,
your operating system's kernel is lying to your shell, and
all the command-line programs you run therein, by telling them
that they're connected to a serial line. In reality, they're
connected to a memory buffer, with the xterm program at
the other end of this buffer pretending to be a terminal.
The shell transmits characters to the xterm, which the xterm
then displays.

When the stty program asks for the baud rate, your kernel
maintains the lie by reporting a baud rate. The shell
doesn't know that it's not connected to a real terminal, and
it doesn't want to know.

The reason for all this deception is that your shell, and many
of the utilities, were written in a time when UNIX interacted
with humans strictly through terminals, and the software got
absolutely dependant on that interface. Rather than re-writing
all the apps (or even just the libraries) to make them compatible
with modern displays, they just made it look like the programs
were still communicating through terminals.

> So the first question is whether the baud rate has any
> physical significance when you're running a terminal
> emulator on top of a windows system.

A test reveals that, at least on Linux, the baud rate on a
pseudo-terminal is completely ignored:

$ stty ospeed 100
$ stty
speed 300 baud; line = 0;
erase = ^H;
-brkint -imaxbel
$ ls -l /usr/man/man1

[ listing flashes by very quickly ]

> Does it mean that bits get transmitted at a specific rate
> from some part of the hardware to some other part of the hardware ?

Bytes get copied as fast as possible from one memory address
to another. So, you'll notice a speed difference if you list
a long directory over a 100-Mbps Ethernet link, as opposed to if you
do it locally.

> The second question is whether this baud rate is important
> for any programming tasks.

Only if your program is meant to work directly with serial lines.

[ Post a follow-up to this message ]