On 02/13/2013 07:58 PM, Paul_Koning at Dell.com wrote:
There are faster network interfaces for VAXen, just not Ethernet.
It still wouldn't be an "apples to apples" comparison, but it'd be
closer.
True -- FDDI would fit the bill. The hard part is finding the
infrastructure. And while FDDI to 10 Mb/s Ethernet bridges are
common enough, FDDI to fast Ethernet is probably harder to find.
(I'm not sure what DEC products, if any, offer that. Gigaswitch,
perhaps?)
The only thing I've ever found that would bridge FDDI to Ethernet
*well* was the Cisco Catalyst family. It's easy to go FDDI<->100Mbps
Ethernet with that hardware.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Feb 13, 2013, at 7:47 PM, Dave McGuire wrote:
...
There are faster network interfaces for VAXen, just not Ethernet. It
still wouldn't be an "apples to apples" comparison, but it'd be closer.
True -- FDDI would fit the bill. The hard part is finding the infrastructure. And while FDDI to 10 Mb/s Ethernet bridges are common enough, FDDI to fast Ethernet is probably harder to find. (I'm not sure what DEC products, if any, offer that. Gigaswitch, perhaps?)
paul
On 02/13/2013 12:53 PM, Johnny Billquist wrote:
I can believe that the 11/84 made the 11/44 obsolete, however. They
fulfill the same niche, with the 11/84 being faster, smaller and
probably cheaper.
How is the 11/84 smaller? It was available in two chassis: one that's
takes up about two feet of rack space, and one standard 6U box. The
11/44 is a 6U box as well. Were there other packagings of these
machines of which I'm unaware?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 02/13/2013 04:29 PM, Johnny Billquist wrote:
I have been thinking about this, anybody knows if a 100 NIC adapter
attached to the AUI port would actually go 100MB full duplex on the
VAX ?
The AUI port already defines you at 10 Mb/s. You need a different
ethernet controller, as the speed is decided by the controller and not
the PHY.
On the Alpha it does, but I have never tried the VAX, I would think it
should, it does in the Stromasys and Simh emulators, but I'm guessing.
That is because Alphas actually might have a 100 Mbit/s ethernet
controller. No VAX that I know of do.
An emulated machine is a totally different topic. There you are still
emulating a 10 Mb/s interface, even though it might map towards a 100
Mb/s physical backend.
There are faster network interfaces for VAXen, just not Ethernet. It
still wouldn't be an "apples to apples" comparison, but it'd be closer.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On 13 Feb 2013, at 16:22, Kari Uusim ki <uusimaki at exdecfinland.org> wrote:
DECnet-plus (or as called in Tru64unix ; DECnet-OSI) includes everything needed to communicate with DECnet Phase IV nodes. It is only a matter of configuration.
You can use the DECnet-plus for OpenVMS documentation, because NCL vocabulary is exactly the same on both platforms. On Tru64unix the other DECnet related commands differ from OpenVMS; like
SET HOST -> dlogin
DIR -> dls
etc
The DECnet-plus documentation resides at:
http://h71000.www7.hp.com/doc/decnetplus.html
Are you trying to configure your Tru64unix system to communicate with HECNET Phase IV nodes?
If so, why don't you just use the provided configuration tool? That's a lot easier than trying to accomplish the configuration manually.
Yes. And I would use the tool...except it segfaults when I run it.
On 13.2.2013 22:26, b4 at gewt.net wrote:
Can you point me to documentation that mentions how to integrate it with Phase IV? Targeted for Tru64 as well? ;)
Finding documentation that meets both criteria is proving difficult...
----- Original Message -----
From: "Kari Uusim ki" <uusimaki at exdecfinland.org>
To: hecnet at Update.UU.SE
Sent: Wednesday, February 13, 2013 3:21:29 PM
Subject: Re: [HECnet] DECnet-Plus and Phase IV Issues
If you have all or some entities already created, you cannot do it again.
You should first shut the DECnet-plus (DECnet-OSI) down to remove all
the entities before you can try to create and enable them again.
There should be template scripts on the system which you can edit to
make them suit your configuration.
It would help a lot to read the DECnet-plus manuals to get a clear
picture of how it works and how to manage it.
On 13.2.2013 20:47, b4 at gewt.net wrote:
bash-4.0# ncl < start_routing.ncl
Node 0 CSMA-CD
AT 2013-02-13-13:27:14.048-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: Error specific to this entity's class
REASON: Already Exists
Description: Already Exists
Node 0 CSMA-CD Station csmacd-1
AT 2013-02-13-13:27:14.062-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: Error specific to this entity's class
REASON: Already Exists
Description: A Station with this name already exists
Node 0
AT 2013-02-13-13:27:14.091-05:00I-----
FAILED IN DIRECTIVE: Create
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.114-05:00I-----
FAILED IN DIRECTIVE: Set
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.121-05:00I-----
FAILED IN DIRECTIVE: Set
DUE TO: No such Entity Instance exists
Node 0 Routing
AT 2013-02-13-13:27:14.126-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: No such Entity Instance exists
bash-4.0# cat start_routing.ncl
create csma-cd
create csma-cd station csmacd-1 communication port tu0
enable csma-cd station csmacd-1
create routing circuit circuit-1 type csma-cd
#
# The following command sets the inactive area address, which is used
# to enable transmission and receipt of ISO 8473 Inactive Subset PDUs,
# also known as Null Internet. This functionality is disabled by
# default. To enable Null Internet, remove the comment character
# from the following command.
#
create node 0 routing type endnode
set node 0 routing phaseiv address = 9.3
enable node 0 routing
set node 0 routing circuit circuit-1 enable phaseiv address true
set node 0 routing circuit circuit-1 data link entity csma-cd station csmacd-1
enable node 0 routing circuit circuit-1
If the stuff already exists, why is the second half of the script failing?
----- Original Message -----
From: "Kari Uusim ki" <uusimaki at exdecfinland.org>
To: hecnet at Update.UU.SE
Sent: Wednesday, February 13, 2013 1:39:27 PM
Subject: Re: [HECnet] DECnet-Plus and Phase IV Issues
On 13.2.2013 20:23, b4 at gewt.net wrote:
------------------------------------------------------------------------
*From: *b4 at gewt.net
*To: *hecnet at update.uu.se
*Sent: *Wednesday, February 13, 2013 1:09:03 PM
*Subject: *[HECnet] DECnet-Plus and Phase IV Issues
Hello!
I (think) I am following the correct NCL syntax here...but..
ncl> create node 0 routing circuit csmacd-0 type = csma-cd
ncl> set node 0 routing circuit csmacd-0 data link entity csma-cd
Here should be the data link entity defined completely as is done below.
It would be more clear if you use another name for the routing circuit
entity than is used for the csma-cd station entity.
ncl> set node 0 routing circuit csmacd-0 enable phaseiv address true
ncl> enable node 0 routing circuit csmacd-0
Node 0 Routing Circuit csmacd-0
AT 2013-02-13-13:05:26.514-05:00I-----
FAILED IN DIRECTIVE: Enable
DUE TO: Error specific to this entity's class
REASON: Open Port Failed
Description: The Open Port call to the specified Data Link failed
Any ideas what i'm doing wrong?
____
This is the script:
create csma-cd
create csma-cd station csmacd-1 communication port tu0
enable csma-cd station csmacd-1
create routing circuit circuit-1 type csma-cd
#
# The following command sets the inactive area address, which is used
# to enable transmission and receipt of ISO 8473 Inactive Subset PDUs,
# also known as Null Internet. This functionality is disabled by
# default. To enable Null Internet, remove the comment character
# from the following command.
#
create node 0 routing type endnode
set node 0 routing phaseiv address = 9.3
enable node 0 routing
set routing circuit circuit-1 enable phaseiv address true
set routing circuit circuit-1 data link entity csma-cd station csmacd-1
enable routing circuit circuit-1
.
.
On 2013-02-13 22:34, hvlems at zonnet.nl wrote:
my point exactly: VMS handles these requests differently; at the cost of response time.
I should point out that you *can* put that information into NCP on RSX, it's just that you don't *need* to.
And VMS is just being plain silly to scan through the nodename database in the case where the MOP request have an explicit file name in the request. The NCP database is then only potentially used for one thing - if you want to not serve the MOP request.
I have not checked RSX here, but I wonder if it only do the scan in the case no filename is provided, or if it always do the scan anyway also on RSX. Either way, RSX responds before VMS even to seem to start thinking about it.
Johnny
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:31:24
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SECc: <hvlems at zonnet.nl>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 22:29, hvlems at zonnet.nl wrote:
Then why holds NCP the required load file for a given MAC address?
It don't on RSX...
That led me to believe that all the MOP client provided was a MAC address.
All ethernet packets provide a source MAC address... :-)
Johnny
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:24:54
To: <Paul_Koning at Dell.com>
Reply-To: hecnet at Update.UU.SECc: <hecnet at Update.UU.SE>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 20:39, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 12:57 PM, Johnny Billquist wrote:
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
...
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
I thought at least primary boot requests tend to just say "help me" so you need a lookup to find the name of the file to load.
Optional. At least DECservers actually provide in the request what file
they want to boot.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
my point exactly: VMS handles these requests differently; at the cost of response time.
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:31:24
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SECc: <hvlems at zonnet.nl>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 22:29, hvlems at zonnet.nl wrote:
Then why holds NCP the required load file for a given MAC address?
It don't on RSX...
That led me to believe that all the MOP client provided was a MAC address.
All ethernet packets provide a source MAC address... :-)
Johnny
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:24:54
To: <Paul_Koning at Dell.com>
Reply-To: hecnet at Update.UU.SECc: <hecnet at Update.UU.SE>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 20:39, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 12:57 PM, Johnny Billquist wrote:
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
...
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
I thought at least primary boot requests tend to just say "help me" so you need a lookup to find the name of the file to load.
Optional. At least DECservers actually provide in the request what file
they want to boot.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-13 22:29, hvlems at zonnet.nl wrote:
Then why holds NCP the required load file for a given MAC address?
It don't on RSX...
That led me to believe that all the MOP client provided was a MAC address.
All ethernet packets provide a source MAC address... :-)
Johnny
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:24:54
To: <Paul_Koning at Dell.com>
Reply-To: hecnet at Update.UU.SECc: <hecnet at Update.UU.SE>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 20:39, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 12:57 PM, Johnny Billquist wrote:
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
...
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
I thought at least primary boot requests tend to just say "help me" so you need a lookup to find the name of the file to load.
Optional. At least DECservers actually provide in the request what file
they want to boot.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-02-13 21:15, Dan B wrote:
I have been thinking about this, anybody knows if a 100 NIC adapter
attached to the AUI port would actually go 100MB full duplex on the
VAX ?
The AUI port already defines you at 10 Mb/s. You need a different ethernet controller, as the speed is decided by the controller and not the PHY.
On the Alpha it does, but I have never tried the VAX, I would think it
should, it does in the Stromasys and Simh emulators, but I'm guessing.
That is because Alphas actually might have a 100 Mbit/s ethernet controller. No VAX that I know of do.
An emulated machine is a totally different topic. There you are still emulating a 10 Mb/s interface, even though it might map towards a 100 Mb/s physical backend.
Johnny
On 2/13/13, Steve Davidson <jeep at scshome.net> wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Jordi
Guillaumes i Pons
Sent: Wednesday, February 13, 2013 14:47
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] NT 4 on AlphaServer es40
El 13/02/2013, a les 18:57, Johnny Billquist <bqt at softjar.se>
va escriure:
Which is silly in it self. Why even search the node
database? After all, the MOP request holds all the
information needed to serve it. RSX don't do a lookup at a
boot request. It just serves it.
But even so, it is surprising that even a fairly modern VAX
can't keep up with a PDP-11 here.
Funny thing: a real VAX (VS 4000/60) can't keep up with an
EMULATED PDP-11 running in a Raspberry Pi ;) I had to disable
service in the emulated PDPs or else they tried to serve the
OS to my 4000/90 ;)
Really? Are you sure that does not have more to do with the fact that
the VAX only has a 10M NIC where as the Raspberry Pi has a 10/100 NIC.
I have not clocked the virtual 11/83 on my RPI but the virtual VAX runs
at about 1.6 VUPs. That would put it in the VAX-11/785 class - ie not
all that fast...
-Steve
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Then why holds NCP the required load file for a given MAC address?
That led me to believe that all the MOP client provided was a MAC address.
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Wed, 13 Feb 2013 22:24:54
To: <Paul_Koning at Dell.com>
Reply-To: hecnet at Update.UU.SECc: <hecnet at Update.UU.SE>
Subject: Re: [HECnet] NT 4 on AlphaServer es40
On 2013-02-13 20:39, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 12:57 PM, Johnny Billquist wrote:
On 2013-02-13 18:52, Paul_Koning at Dell.com wrote:
On Feb 13, 2013, at 11:12 AM, Johnny Billquist wrote:
...
Fun detail: when devices want to MOP boot on a network where you have both a VAX and a PDP-11, the PDP-11 normally ends up serving the image, since it responds much faster than the VAX.
That's because the VMS MOP server did its lookup for a match in the node database by a linear search. I never could convince the engineer responsible for that code to use a better algorithm.
Which is silly in it self. Why even search the node database? After all, the MOP request holds all the information needed to serve it. RSX don't do a lookup at a boot request. It just serves it.
I thought at least primary boot requests tend to just say "help me" so you need a lookup to find the name of the file to load.
Optional. At least DECservers actually provide in the request what file
they want to boot.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
