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
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".
My TOPS20 toy has somehow lost its network connectivity. I'll try to find how to do it in TOPS-20 after fixing that.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
On 2013-01-02 00:37, Paul_Koning at Dell.com wrote:
On Jan 1, 2013, at 10:25 AM, Johnny Billquist wrote:
On 2012-12-31 19:36, Bob Armstrong wrote:
There s something else going on here. I m not sure who originally
analyzed the file to decide that the format was Stream-CR (although
given that the analysis was done on RSX, we can probably guess :-)
Cool. This is become more weird all the time.
WHat I reported was what was shown when doing a directory over DECnet. It's the information VMS presents. RSX is not really involved.
With DECnet, it is. DAP sends the information about the files in the directory listing in encoded form, and it's up to the receiving system to decode it correctly and format it for display. So if you're seeing the wrong attribute, either VMS is sending the wrong DAP code, or RSX is decoding it wrong. A wire trace along with some reading of the DAP protocol spec will tell you which it is.
Thanks, Paul. I have not read the spec. But I came to realize this after looking at this for a while, and being wrong a couple of times.
I think it's fair to use VMS as a reference implementation, since VmS agrees with itself. So I'm going to look at fixing RSX.
Does anyone have an RSTS/E system (or TOPS-20), and could report how the file appears to be, from their point of view?
LEGATO::INFO.TXT;1 is what I'm thinking of.
Johnny
