Increased it to 32, ...
That's probably a good idea, but I don't actually think that's the
problem. Like I said, I see this happening with several nodes, all on the
bridge QNA - MIM, PONDUS, A5RTR, SGC, etc.
Bob
On 2014-05-26 02:52, Paul_Koning at Dell.com wrote:
On May 24, 2014, at 10:15 AM, Johnny Billquist <bqt at softjar.se> wrote:
...
Do I need to spell it out? :-)
The hardware address is the address the card have from factory. The physical address is the address the software have programmed the card to have. Since DECnet uses specific addresses, the address is changed from the hardware address, since you do not want/need that when running DECnet.
Not necessarily exactly that way.
Well, we are talking about old hardware here, Paul... :-)
The hardware address is the default physical address. It is supposed to be globally unique (not just unique on each LAN). If you have virtual devices, like in SIMH, chances are you re responsible for this (you re in essence the manufacturer). Pedantically, if you administer MAC addresses, they should be from the locally administered address space, i.e., second bit set in the 1st byte. In practice that doesn t matter, but it avoids conflict with real hardware addresses.
Right. But you will be really unlucky if you manage to hit an address that you also happen to have some real hardware using, unless you explicitly sets it so. But even more, once DECnet starts up, it becomes irrelevant again, since DECnet changes the MAC address, and do not even consider retaining the ability to use the original MAC address.
DECnet Phase IV uses a physical address it supplies rather than the default. Other protocols (including DECnet Phase V) don t. If your NIC type (or its driver) supports only a single physical address, the physical address changes for all protocols when you turn on DECnet Phase IV. That s why you have to turn on DECnet before LAT.
Right.
However... if your NIC and driver allow per-protocol physical address, then only DECnet Phase IV uses the aa-00-04-00 address and the others continue to use the hardware address. For such systems, you have to be careful that the hardware address is unique even if DECnet is used.
DECnet on neither PDP-11 nor VAX tries any such tricks. They just assume you only will have one hardware address per interface, and sets it to what DECnet thinks it should be, and that's it. I have not checked Alpha, but I suspect it never do such a thing either. And I know that DECnet under Linux also don't play this way (or didn't last I looked). So while you are right that it could do this in theory, it is not done by anything as far as I know, and the additional complexity without any real gains outweight the potential use of such a behavior.
Most newer DEC NICs (Tulip and beyond) support multiple physical addresses, as does QNA. UNA and LANCE do not. Whether a particular OS/driver implements that is another matter.
simh and other things normally use libpcap, and that do not add extra addresses, but just gets the device into promiscuous mode, and then deals with it in software.
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 2014-05-26 03:06, Bob Armstrong wrote:
Do you have a max routers set too low on your machine maybe?
We have quite a few routers on the bridge segment.
$ NCP SHOW EXEC CHAR
...
Max broadcast nonrouters = 512
Max broadcast routers = 128
...
$ NCP TELL MIM SHOW EXEC CHAR
...
Max broadcast nonrouters = 64
Max broadcast routers = 20
...
Maybe it's too low on MIM?? The message actually makes it sound like MIM
is dropping LEGATO, not the other way around.
Could be... In fact you are probably right. Just checked, and MIM have a MAX of 20 right now, which I believe is too low here. Increased it to 32, but I need to reboot for it to take effect...
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
Do you have a max routers set too low on your machine maybe?
We have quite a few routers on the bridge segment.
$ NCP SHOW EXEC CHAR
...
Max broadcast nonrouters = 512
Max broadcast routers = 128
...
$ NCP TELL MIM SHOW EXEC CHAR
...
Max broadcast nonrouters = 64
Max broadcast routers = 20
...
Maybe it's too low on MIM?? The message actually makes it sound like MIM
is dropping LEGATO, not the other way around.
Bob
On May 24, 2014, at 10:15 AM, Johnny Billquist <bqt at softjar.se> wrote:
...
Do I need to spell it out? :-)
The hardware address is the address the card have from factory. The physical address is the address the software have programmed the card to have. Since DECnet uses specific addresses, the address is changed from the hardware address, since you do not want/need that when running DECnet.
Not necessarily exactly that way.
The hardware address is the default physical address. It is supposed to be globally unique (not just unique on each LAN). If you have virtual devices, like in SIMH, chances are you re responsible for this (you re in essence the manufacturer). Pedantically, if you administer MAC addresses, they should be from the locally administered address space, i.e., second bit set in the 1st byte. In practice that doesn t matter, but it avoids conflict with real hardware addresses.
DECnet Phase IV uses a physical address it supplies rather than the default. Other protocols (including DECnet Phase V) don t. If your NIC type (or its driver) supports only a single physical address, the physical address changes for all protocols when you turn on DECnet Phase IV. That s why you have to turn on DECnet before LAT.
However... if your NIC and driver allow per-protocol physical address, then only DECnet Phase IV uses the aa-00-04-00 address and the others continue to use the hardware address. For such systems, you have to be careful that the hardware address is unique even if DECnet is used.
Most newer DEC NICs (Tulip and beyond) support multiple physical addresses, as does QNA. UNA and LANCE do not. Whether a particular OS/driver implements that is another matter.
paul
At 2:14 AM +0200 26/5/14, Johnny Billquist wrote:
Aha. So it is 10.2 that gets timeouts when sending packets to 10.1. So 10.1 are dropping packets.
Good. Now, in which direction was the transfer attempted?
10.2 -> 10.1, initiated from 10.1:
10.1>NFT TI:=10.2::SOME.FILE
This is a problem inside of DECnet on the simulated host. It gets packets faster than it can process them, so some packets are dropped.
Unfortunately DECnet deals very bad with systematic packet loss like this. You get retransmissions, and after a while the retransmission timeout backs off until you have more than a minute between retransmission attempts.
I have now to find the reason for the packet loss.
Anyway, if you can get simh to throttle the ethernet interface, that might help you. (I don't remember offhand if it do support such functionality.)
The service polling timer can be adjusted
SET XQ POLL={DEFAULT|4..2500}
Set to 100 by default.
--
Jean-Yves Bernier
On 2014-05-26 01:37, Jean-Yves Bernier wrote:
At 1:00 AM +0200 26/5/14, Johnny Billquist wrote:
Well, that is not the full story... :-)
10.1>NCP SHO NOD 10.2 COU
Node counters as of 30-MAR-82 00:21:30
Remote node = 10.2 (SNAKE)
1266 Seconds since last zeroed
272319 Bytes received
1723 Bytes sent
821 Messages received
373 Messages sent
1 Connects received
4 Connects sent
0 Response timeouts
0 Received connect resource errors
2 Node maximum logical links active
10.2>NCP SHO NOD 10.1 COU
Node counters as of 30-MAR-82 01:10:34
Remote node = 10.1 (SHARK)
4212 Seconds since last zeroed
13475 Bytes received
1382813 Bytes sent
2626 Messages received
5177 Messages sent
26 Connects received
2 Connects sent
73 Response timeouts
0 Received connect resource errors
3 Node maximum logical links active
Aha. So it is 10.2 that gets timeouts when sending packets to 10.1. So 10.1 are dropping packets.
Good. Now, in which direction was the transfer attempted?
Summary of my last experiments:
Node A & node B inside VirtualBox (Linux) : that's the configuration i
am running since the beginning of this discussion.
Node A & node B on a same MacMini (BSD). VirtualBox out of the loop.
=> same problem.
Node A on a MacPro, node B on the MacMini. VirtualBox out of the loop
again.
=> same problem.
Node A inside VirtualBox Linux (MacPro), node B on the MacMini (BSD).
=> same problem.
We can rule out VirtualBox.
We can rule out a Linux/BSD/pcap problem.
We can rule out running multiple nodes on the same host (MAC addresses,
etc).
Two versions of simh were used, 3.6 and 3.9, in Mac and Linux build.
Right. And I never expected any of the things listed above to be the problem to start with.
This is a problem inside of DECnet on the simulated host. It gets packets faster than it can process them, so some packets are dropped.
Unfortunately DECnet deals very bad with systematic packet loss like this. You get retransmissions, and after a while the retransmission timeout backs off until you have more than a minute between retransmission attempts.
It is a known problem.
[ Note: since simh 3.7, set console pchar=37777777777 if you want to use
EDT/RMD/NTD at the console, took me an hour to figure. ]
:-)
Anyway, if you can get simh to throttle the ethernet interface, that might help you. (I don't remember offhand if it do support such functionality.)
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
At 1:00 AM +0200 26/5/14, Johnny Billquist wrote:
Well, that is not the full story... :-)
10.1>NCP SHO NOD 10.2 COU
Node counters as of 30-MAR-82 00:21:30
Remote node = 10.2 (SNAKE)
1266 Seconds since last zeroed
272319 Bytes received
1723 Bytes sent
821 Messages received
373 Messages sent
1 Connects received
4 Connects sent
0 Response timeouts
0 Received connect resource errors
2 Node maximum logical links active
10.2>NCP SHO NOD 10.1 COU
Node counters as of 30-MAR-82 01:10:34
Remote node = 10.1 (SHARK)
4212 Seconds since last zeroed
13475 Bytes received
1382813 Bytes sent
2626 Messages received
5177 Messages sent
26 Connects received
2 Connects sent
73 Response timeouts
0 Received connect resource errors
3 Node maximum logical links active
Summary of my last experiments:
Node A & node B inside VirtualBox (Linux) : that's the configuration i am running since the beginning of this discussion.
Node A & node B on a same MacMini (BSD). VirtualBox out of the loop.
=> same problem.
Node A on a MacPro, node B on the MacMini. VirtualBox out of the loop again.
=> same problem.
Node A inside VirtualBox Linux (MacPro), node B on the MacMini (BSD).
=> same problem.
We can rule out VirtualBox.
We can rule out a Linux/BSD/pcap problem.
We can rule out running multiple nodes on the same host (MAC addresses, etc).
Two versions of simh were used, 3.6 and 3.9, in Mac and Linux build.
[ Note: since simh 3.7, set console pchar=37777777777 if you want to use EDT/RMD/NTD at the console, took me an hour to figure. ]
--
Jean-Yves Bernier
On Mon, 26 May 2014, Johnny Billquist wrote:
That is the minimum. I hope you generated an endnode system... :-)
I did.
Well, basically, since your system complains about GEN being too fragmented, you have just managed to start a few things before DECnet tries to start up, and there is not enough contiguous memory left around for DECnet to be happy.
VNP is the third component of DECnet management. NCP and CFE being the other two.
VNP is used to configure networking in the actual system image file, so that it is already installed and in order when you boot. That means no other stuff has yet started, and you have more clear memory to play with, so VNP can probably set you up the same way NETINS do at runtime.
Ahhh.
So, you should go over what NETINS.CMD do, and do the same thing in VNP instead, with the exception that some things cannot be done in VNP. Those steps needs to be left in a modified NETINS.CMD...
But VNP only understands a subset of the NCP commands. For all the installation parts, you instead needs to use VMR.
Now, if you don't feel comfortable with playing around with this stuff, I should warn you that you can render your system unbootable when fooling around with this.
Well, I fiddled with pool:
set /plctl
PLCTL=896.:384.:448.:51.
set /secpol
SECPOL=400.:524.:76%
Then it came up. Closing a LAT connection also doesn't cause a crash now. ;)
Memory utilisation is 78%...but I DO intend to eventually get more memory. I'm just running with half a bad board disabled. ;)
Johnny
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 2014-05-26 01:05, Cory Smelosky wrote:
On Mon, 26 May 2014, Johnny Billquist wrote:
Ho hum. Well, how much memory do you have, and what else have you
managed to start before this goes down?
256 Kwords. ;)
That is the minimum. I hope you generated an endnode system... :-)
There are possible solutions as well. But it might require that you
learn a little about VNP...
Well I'm staring at a (correct!) Manager's Guide, so I'm not opposed to
that.
Well, basically, since your system complains about GEN being too fragmented, you have just managed to start a few things before DECnet tries to start up, and there is not enough contiguous memory left around for DECnet to be happy.
VNP is the third component of DECnet management. NCP and CFE being the other two.
VNP is used to configure networking in the actual system image file, so that it is already installed and in order when you boot. That means no other stuff has yet started, and you have more clear memory to play with, so VNP can probably set you up the same way NETINS do at runtime.
So, you should go over what NETINS.CMD do, and do the same thing in VNP instead, with the exception that some things cannot be done in VNP. Those steps needs to be left in a modified NETINS.CMD...
But VNP only understands a subset of the NCP commands. For all the installation parts, you instead needs to use VMR.
Now, if you don't feel comfortable with playing around with this stuff, I should warn you that you can render your system unbootable when fooling around with this.
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
