On 01/02/2013 05:32 PM, Paul_Koning at Dell.com wrote:
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.
Why those two modes? Real DMCs are symmetrical, I would have
expected a simulation to do that too.
I haven't seen the code, but I would guess that it's a matter of
non-DMC-related administrivia, like which end initiates the TCP connection.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Al 02/01/13 23:32, En/na Paul_Koning at Dell.com ha escrit:
Why those two modes? Real DMCs are symmetrical, I would have expected a simulation to do that too.
Just to clarify it, I didn't wrote that software :). I don't want to get anyone's merits. And, for your question, I also wonder why did the author wrote it that way. I guess since it is TCP based one of the partners must put itself in listen mode and the other one has to do the initial connect, hence the need to differentiate between a "primary" or caller and a "secondary" or listener. UDP does not have that problem, but of course you can't (easily) tunnel UDP using -for instance- ssh.
On Jan 2, 2013, at 4:33 PM, Jordi Guillaumes i Pons 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.
Why those two modes? Real DMCs are symmetrical, I would have expected a simulation to do that too.
paul
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."
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 ;)
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
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? :)
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!).
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
.
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