That makes perfect sense: LAT is designed for a LAN while CTERM is a general purpose WAN protocol. So the surprising part is that LAT works as well as it does over a WAN. The reason probably is that modern WANs have performance (latency, in particular) good enough to match the "LAN" expectations of LAT.
paul
On Jan 2, 2013, at 10:51 AM, <hvlems at zonnet.nl>
wrote:
Look at it this way Sampsa: LAT degrades by a factor 3 while CTERM is better than half the performance.
LAT nor CTERM know they're travelling over an extended LAN.
So I'd think CTERM behaves better than LAT :-)
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] LAT vs CTERM
Verzonden: 2 januari 2013 12:20
So just for fun I did some speed experiments with CTERM and LAT using Kermit to send the same file.
WAN connection is KUHAVX (Finland) to RHESUS (UK).
CTERM
LAN: 30,000 CPS
WAN: 16,400 CPS
LAT:
LAN: 100,000 CPS
WAN: 30,000 CPS
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
sampsa
Look at it this way Sampsa: LAT degrades by a factor 3 while CTERM is better than half the performance.
LAT nor CTERM know they're travelling over an extended LAN.
So I'd think CTERM behaves better than LAT :-)
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] LAT vs CTERM
Verzonden: 2 januari 2013 12:20
So just for fun I did some speed experiments with CTERM and LAT using Kermit to send the same file.
WAN connection is KUHAVX (Finland) to RHESUS (UK).
CTERM
LAN: 30,000 CPS
WAN: 16,400 CPS
LAT:
LAN: 100,000 CPS
WAN: 30,000 CPS
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
sampsa
On Jan 2, 2013, at 5:25 AM, Jordi Guillaumes i Pons wrote:
El 02/01/2013, a les 11:04, Johnny Billquist <bqt at softjar.se> va escriure:
Does anyone have an RSTS/E system (or TOPS-20), and could report how the file appears to be, from their point of view?
I don't know how to use RMSDSP against a full DECNET filespec, but a NFT DIR/FU shows this (in RSTS/E):
Directory 2.1::SYS$SPECIFIC:[FAL$SERVER]
Name .Typ Size Prot Access Date Time UIC
INFO .TXT;2 8/10P < 42> 31-Dec-12 31-Dec-12 07:20 [000376,000373]
RF:VAR FO:SEQ USED=8:150 RECSI=174 CC:IMP
INFO .TXT;1 8/35P < 42> 27-Dec-12 08-Jul-10 10:54 [000376,000373]
RF:UDF FO:SEQ USED=8:64 RECSI=174 CC:IMP
Total of 16/45 blocks in 2 files.
The ;1 version lists as RD:UDF. I guess that is "record format: undefined".
Yes, that's what it means. That's different from stream, never mind stream_cr or stream_lf. RSTS should understand stream format -- after all, it exists partly because that's the native format of RSTS (though I think it was actually introduced to support Unix better).
A network capture would be very interesting, since the evidence so far is all over the map.
paul
On Jan 2, 2013, at 7:12 AM, <sampsa at mac.com>
wrote:
On 2 Jan 2013, at 14:03, Mark Benson <md.benson at gmail.com> wrote:
On 2 Jan 2013, at 11:20, sampsa at mac.com wrote:
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
My understanding is LAT is a self contained ethernet-based protocol purely designed and optimised for terminal connectivity. CTERM is a command terminal application that runs on top of DECnet and works via the DECnet stack. The added layers probably, at least in part, account for the speed variation between the two.
I could see that on like Z80s running over a 9.6kbps link, but VAX level gear on a 10 Mbps ethernet LAN?
It can't be the protocol overhead alone, CTERM must be seriously brain-damaged by design.
Cterm is a pretty awful protocol, "heavy" certainly describes it. Roughly speaking, it defines a remote procedure call style "generic terminal I/O" service. The primitives in the protocol resemble the combination of VMS and TOPS-20 terminal driver features. So if you think of all the things you can ask a terminal to do with VMS QIO$ syscalls, then think about hairy stuff like EDT screen based editing, you roughly have what cterm tries to do.
But still, the numbers shown are a bit low.
What is the test scenario for cterm? I suspect a part of the problem may be kernel vs. user mode processing.
paul
sampsa at mac.com writes:
On 2 Jan 2013, at 14:03, Mark Benson <md.benson at gmail.com> wrote:
On 2 Jan 2013, at 11:20, sampsa at mac.com wrote: > >> So LAT is as fast
over a WAN link as CTERM is over a LAN..What's wrong with CTERM? > >
I could see that on like Z80s running over a 9.6kbps link, but VAX level
gear on a 10 Mbps ethernet LAN?
It can't be the protocol overhead alone, CTERM must be seriously
brain-damaged by design.
Just curious. What do the numbers look like when you use RTERM in lieu
of CTERM???
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Weirdly enough, TELNET to both my local system (KUHAVX, on the LAN) and remote (RHESUS, over a 3G link that gets about 10 Mbps down, 4 Mbps up) gave the same transfer rate, i.e. about 100K CPS.
sampsa
El 02/01/2013, a les 13:12, sampsa at mac.com va escriure:
I could see that on like Z80s running over a 9.6kbps link, but VAX level gear on a 10 Mbps ethernet LAN?
It can't be the protocol overhead alone, CTERM must be seriously brain-damaged by design.
A CTERM vs RTERM vs LAT vs TELNET comparison would be a nice thing to look at... :)
I always had the feeling that CTERM is "heavy". Of course LAT has to be the lightest of those protocols, being (by designl) a non-routable MAC-based LAN-only protocol...
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On 2 Jan 2013, at 14:03, Mark Benson <md.benson at gmail.com> wrote:
On 2 Jan 2013, at 11:20, sampsa at mac.com wrote:
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
My understanding is LAT is a self contained ethernet-based protocol purely designed and optimised for terminal connectivity. CTERM is a command terminal application that runs on top of DECnet and works via the DECnet stack. The added layers probably, at least in part, account for the speed variation between the two.
I could see that on like Z80s running over a 9.6kbps link, but VAX level gear on a 10 Mbps ethernet LAN?
It can't be the protocol overhead alone, CTERM must be seriously brain-damaged by design.
sampsa
On 2 Jan 2013, at 11:20, sampsa at mac.com wrote:
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
My understanding is LAT is a self contained ethernet-based protocol purely designed and optimised for terminal connectivity. CTERM is a command terminal application that runs on top of DECnet and works via the DECnet stack. The added layers probably, at least in part, account for the speed variation between the two.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
So LAT is as fast over a WAN link as CTERM is over a LAN..What's wrong with CTERM?
Ohhh that you even had to ask...
Johnny
So I knew CTERM was slower than LAT, but THIS much slower. It's a bit of WTF...
sampsa
