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
On 2013-01-02 12:20, sampsa at mac.com wrote:
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?
Ohhh that you even had to ask...
Johnny
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
