HECnet

hecnet@lists.dfupdate.se

5 participants
15588 discussions

unattended booting, was Re: [HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

by gregg.drwho8＠gmail.com

On Wed, Jan 2, 2013 at 4:47 PM, Dave McGuire <mcguire at neurotica.com> wrote: On 01/02/2013 04:43 PM, Cory Smelosky wrote: (BTW the "buffered console" feature in 4.0 is also awesome, specially to run headless simulators. Now if we could do an unattended RSX boot it would be wonderful!). Yes, an unattended RSX boot WOULD be nice. ;) You could probably do it with "expect". I did some work in that area several years ago. I remember I got pretty far with it. I should try to dig it up. -Dave -- Dave McGuire, AK4HZ New Kensington, PA Hello! It certainly sounds interesting. However Dave for you to find it will require a shovel as it was deeply buried. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

13 years

DMC11 in next simh version... looks nice, and question about TOPS-10

by jg＠jordi.guillaumes.name

Al 02/01/13 22:43, En/na Cory Smelosky ha escrit: How is the performance? I just played a little bit :) But I guess its far better than a real DMC-11 ;)

13 years

unattended booting, was Re: [HECnet] DMC11 in next simh version... looks nice, and question about TOPS-10

by mcguire＠neurotica.com

On 01/02/2013 04:43 PM, Cory Smelosky wrote: (BTW the "buffered console" feature in 4.0 is also awesome, specially to run headless simulators. Now if we could do an unattended RSX boot it would be wonderful!). Yes, an unattended RSX boot WOULD be nice. ;) You could probably do it with "expect". I did some work in that area several years ago. I remember I got pretty far with it. I should try to dig it up. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

13 years

DMC11 in next simh version... looks nice, and question about TOPS-10

by b4＠gewt.net

On 2 Jan 2013, at 16:33, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote: Hello, The upcoming SIMH version (4.0) comes with a virtual DMC11. It has been merged to the head branch in the git repository, so I have been playing with it a little bit. The simh team has done an aswesome work again, so kudos for Bob, Mark and all the others... It seems the DMCx are supported in pdp10, pdp11 and the VAXen. The basic instructions to make it work are in the DOC files. Just to make the story short: - DMC11s work in pairs, just like the real devices. - One of the DMCs has to be put in PRIMARY mode, the other one in SECONDARY. The default is SECONDARY. - Each of the DMCs has to be attached to a local port. - Each of the DMCs has to be peered with the remote port. Let's say we have a VAX780 running at 10.0.0.1 and another one running at 10.0.0.2. To link both simulators via DMC11s we have to: In 10.0.0.1 INI file: simh> set dmc0 enable simh> set dmc0 peer=10.0.0.2:22222 simh> att dmc0 11111 In 10.0.0.2: simh> set dmc0 enable simh> set dmc0 linemode=primary simh> set dmc0 peer=10.0.0.1:11111 simh> att dmc0 22222 Then, in both systems, once VMS is running: NCP>define line dmc-0 state on NCP>define cir dmc-0 state on cost 5 NCP>set line dmc-0 all NCP>set cir dmc-0 all (The systems must be routers if they also use the ethernet circuit) In a few seconds, the circuit will go up and the adjacency will come alive. Thank you for this information. So we have now an alternative way to link our HECnet nodes via internet. The problem is the link has to be defined in both machines (so it does not help road warriors, a VPN link is still required). It uses TCP links, but if the IP link goes down it is smart enough to reconnect when it comes up again. According to the comments in the code it seems there are plans to add UDP transport. It would be even nicer if it could emulate somehow the multinet tunnel protocol :) but. How is the performance? Now the question. It seems the DMC11 device is supported in the KS10 emulation. Could it be posible to use it to DECNETize (and HECNETize) TOPS-10 over simh? I have not been able to find the docs to install DECNET-10 in a 7.04 monitor... Any TOPS-10 hacker around? :)

13 years

DMC11 in next simh version... looks nice, and question about TOPS-10

by jg＠jordi.guillaumes.name

Hello, The upcoming SIMH version (4.0) comes with a virtual DMC11. It has been merged to the head branch in the git repository, so I have been playing with it a little bit. The simh team has done an aswesome work again, so kudos for Bob, Mark and all the others... It seems the DMCx are supported in pdp10, pdp11 and the VAXen. The basic instructions to make it work are in the DOC files. Just to make the story short: - DMC11s work in pairs, just like the real devices. - One of the DMCs has to be put in PRIMARY mode, the other one in SECONDARY. The default is SECONDARY. - Each of the DMCs has to be attached to a local port. - Each of the DMCs has to be peered with the remote port. Let's say we have a VAX780 running at 10.0.0.1 and another one running at 10.0.0.2. To link both simulators via DMC11s we have to: In 10.0.0.1 INI file: simh> set dmc0 enable simh> set dmc0 peer=10.0.0.2:22222 simh> att dmc0 11111 In 10.0.0.2: simh> set dmc0 enable simh> set dmc0 linemode=primary simh> set dmc0 peer=10.0.0.1:11111 simh> att dmc0 22222 Then, in both systems, once VMS is running: NCP>define line dmc-0 state on NCP>define cir dmc-0 state on cost 5 NCP>set line dmc-0 all NCP>set cir dmc-0 all (The systems must be routers if they also use the ethernet circuit) In a few seconds, the circuit will go up and the adjacency will come alive. So we have now an alternative way to link our HECnet nodes via internet. The problem is the link has to be defined in both machines (so it does not help road warriors, a VPN link is still required). It uses TCP links, but if the IP link goes down it is smart enough to reconnect when it comes up again. According to the comments in the code it seems there are plans to add UDP transport. It would be even nicer if it could emulate somehow the multinet tunnel protocol :) but. Now the question. It seems the DMC11 device is supported in the KS10 emulation. Could it be posible to use it to DECNETize (and HECNETize) TOPS-10 over simh? I have not been able to find the docs to install DECNET-10 in a 7.04 monitor... Any TOPS-10 hacker around? :) (BTW the "buffered console" feature in 4.0 is also awesome, specially to run headless simulators. Now if we could do an unattended RSX boot it would be wonderful!).

13 years

LAT vs CTERM

by uusimaki＠exdecfinland.org

LAT can perform quite well even over long distances. There used to be a nationwide customer network which was a LAT-only and it spanned tens of branch offices and hundreds of users spread all over the country. The longest distance between the VMS servers and the terminal server farthest away was approximately 1500km's (almost 1000 miles). Everything worked fine. Concerning CTERM I think it would perform better by tuning the DECnet parameters to suit modern networks better. That would make other DECnet user protocols perform better as well. Anyway, I assume CTERM isn't the best way to transfer files. Kari On 2.1.2013 18:36, Paul_Koning at Dell.com wrote: 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 .

13 years

LAT vs CTERM

by Paul_Koning＠Dell.com

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

13 years

LAT vs CTERM

by hvlems＠zonnet.nl

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

13 years

Funky file formats, et al...

by Paul_Koning＠Dell.com

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

13 years

LAT vs CTERM

by Paul_Koning＠Dell.com

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

13 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet