[HECnet] DECnet performance problems (on TOPS-10)

[Johnny Billquist]

On 2011-09-01 17:25, Bob Armstrong wrote:
TOPS-10 and RSTS (and RT-11) echo the keystrokes as they occur,
while RSX and VMS echo when the read occurs.

    Ah, I never thought about it before, but that's very profound and clearly
true.   And easily demonstrated too - do some command on VMS that takes a
minute to execute, and then type ahead.   You won't see anything echoed.   On
TOPS10 in the same circumstance, you will.   I don't remember offhand how
TOPS20 behaved (it's been too many years ago).

A short experiment on TOPS-20 suggest that it only echoes once the character is actually read, which also would make sense since things would become rather weird and fouled up with completion, character recognition and so on in TOPS-20 if echo didn't take place at the right place and time. What a character actually will do depends on the context in TOPS-20.

But it was a simple test, and I might just have failed to cause enough of a delay...

And the same is somewhat true in RSX and VMS as well (well, it's actually true in any OS, but most don't take it into consideration).

As Paul also mentioned, the echoing of a newline is different in RSX than RSTS/E. Technically, this is not related to input at all, but only output. Whenever a CR+LF is output in RSX, the LF is surpressed until the next character is written, and only output when something else needs to be printed. The same is actually also true in VMS. However, this behavior is depending on you using the terminal drivers own newline processing function. If you just output the CF and LF characters in your text stream, the LF will not be surpressed.

Another point is the character-at-a-time mode. I don't know exactly how rterm (or whatever) does this, but it's not really comparably to telnet. There is no "raw" mode in telnet (I only finished implementing my telnet client for RSX last week, so right now all the details are very fresh in my head :-) ).
However, it is probably fair to say that TOPS-20 in general reads each single character, and not a line at a time. So any terminal protocol needs to do the same for things to work right. In telnet, the most relevant part here is the echoing function, where you, for interactive sessions, normally have remote echo turned on. With local echo, you normally do a line at a time in telnet, but there is really no difference between doing line at a time and character at a time from the telnet protocol point of view. However, interactive users would not be impressed if you have remote echo, and only send the characters when you have entered a whole line (obviously).

If you want to do the same as TOPS-20 in Unix, however, you will turn on "raw" mode in Unix. :-)

Speaking of rterm by the way, I don't know much about it (obviously), but either it got to be a very clever protocol, or else it works the same as telnet with remote echo. If it's clever, then it needs not only be able to handle if you want to input without echoing, but also if you want binary reads (no terminators), special terminators, special keys meaning special functions, and god knows what else.
I think CTERM atleast tries to be clever here, which is why it is such a mess. Notice how VMS line editing partially works when doing SET HOST to a non-VMS system. Ugh!

	Johnny

-- 
Johnny Billquist                                   || "I'm on a bus
                                                                  ||   on a psychedelic trip
email: bqt at softjar.se                         ||   Reading murder books
pdp is alive!                                         ||   tryin' to stay hip" - B. Idol