24 Feb
2020
24 Feb
'20
10:28 p.m.
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the
current 3.11 that I found - is there a newer version?)
Main host runs Devuan Linux (yes, I'm a systemd hater). VirtualBox VM
hosts the SIMH instance, also running Devuan Linux.
My area router, FRUGAL, boots fine and gets adjacency with my
Multinet-over-IP connections, that is, LEGATO, MIM, and 31.3:: as well as
other DECNet hosts (MISER, CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a
bit with local DECNet hosts as well as the ip-connection to 31.3::
I've tried eliminating the connection to 31.3:: as the culprit by turning
off the circuit, and the connection between FRUGAL:: and MISER:: (both
local nodes) continues to go up and down every few minutes.
I'd welcome some pointers, things to check, etc. Is there such a thing as
an adjacency timer perhaps I could crank up a bit?
Thanks
Fred
24 Feb
24 Feb
11:17 p.m.
On 2020-02-24 22:28, Fred wrote:
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the
current 3.11 that I found - is there a newer version?)
3.11 would suggest you are sticking to Bobs development. There is also
the "fork" by Mark. Not sure which, if either, is better...
Main host runs Devuan Linux (yes, I'm a systemd
hater).? VirtualBox VM
hosts the SIMH instance, also running Devuan Linux.
systemd needs to die.
My area router, FRUGAL, boots fine and gets adjacency
with my
Multinet-over-IP connections, that is, LEGATO, MIM, and 31.3:: as well
as other DECNet hosts (MISER, CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a
bit with local DECNet hosts as well as the ip-connection to 31.3::
I've tried eliminating the connection to 31.3:: as the culprit by
turning off the circuit, and the connection between FRUGAL:: and MISER::
(both local nodes) continues to go up and down every few minutes.
I'd welcome some pointers, things to check, etc.? Is there such a thing
as an adjacency timer perhaps I could crank up a bit?
You could crank up the hello timer on the circuit, but I'm not sure
you'll be much happier with that.
Sounds like you might have some issues with how it performs on the
ethernet. Hard to tell much without more investigation...
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
11:48 p.m.
Turning of SIMH cpu idle and not nicing simh down if it is niced down may be worth a shot
too
---
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
On Feb 24, 2020, at 5:17 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2020-02-24 22:28, Fred wrote:
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the current 3.11
that I found - is there a newer version?)
3.11 would suggest you are sticking to Bobs development. There is also the
"fork" by Mark. Not sure which, if either, is better...
Main host runs Devuan Linux (yes, I'm a
systemd hater). VirtualBox VM hosts the SIMH instance, also running Devuan Linux.
systemd needs to die.
My area router, FRUGAL, boots fine and gets
adjacency with my Multinet-over-IP connections, that is, LEGATO, MIM, and 31.3:: as well
as other DECNet hosts (MISER, CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a bit
with local DECNet hosts as well as the ip-connection to 31.3::
I've tried eliminating the connection to 31.3:: as the culprit by turning off the
circuit, and the connection between FRUGAL:: and MISER:: (both local nodes) continues to
go up and down every few minutes.
I'd welcome some pointers, things to check, etc. Is there such a thing as an
adjacency timer perhaps I could crank up a bit?
You could crank up the hello timer on the circuit, but I'm not sure you'll be
much happier with that.
Sounds like you might have some issues with how it performs on the ethernet. Hard to tell
much without more investigation...
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 
25 Feb
25 Feb
12:59 a.m.
On Monday, February 24, 2020 at 2:17 PM, Johnny Billquist wrote:
On 2020-02-24 22:28, Fred wrote:
3.11 is Bob's maintenance of simulators he specifically wrote.
These 25 simulators are:
eclipse h316 i1620 id16 lgp pdp1 pdp11 pdp4 pdp8 s3 sigma vax
altair gri i1401 i7094 id32 nova pdp10 pdp15 pdp7 pdp9 sds uc15
vax780
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the
current 3.11 that I found - is there a newer version?)
3.11 would suggest you are sticking to Bobs development. There is also the "fork" by Mark. Not sure
which, if either, is better...
Simh's evolving development since v3.9 (about 8 years ago) has been
contained at the github repository https://github.com/simh/simh
The simh history from the earliest releases are contained here as well
as Bob's current development state (3.11) in the Supnik-Current branch.
Many folks have contributed new simulators and additions to Bob's
original work. We've got 80 simulators now with more coming this
week and in the relatively near future and many additions have been
added to both the general simh framework and Bob's original simulators.
Currently the simulators include:
3b2 h316 i7090 imds-810 microvax2 pdp10-ki scelbi
vax750
hp2100 i7094 infoserver100 microvax2000 pdp11 sds
vax780
altair hp3000 ibm1130 infoserver1000 microvax3100 pdp15 sigma
vax780.exe
altairz80 i1401 id16 infoserver150vxt microvax3100e pdp4 ssem
vax8200
b5500 i1620 id32 isys8010 microvax3100m80 pdp6 swtp6800mp-a
vax8600
besm6 i701 imds-210 isys8020 microvax3900 pdp7 swtp6800mp-a2
vaxstation3100m30
i7010 imds-220 isys8024 nova pdp8 tx-0
vaxstation3100m38
cdc1700 i704 imds-225 isys8030 pdp1 pdp9 uc15
vaxstation3100m76
eclipse i7070 imds-230 lgp pdp10 rtvax1000 vax
vaxstation4000m60
gri i7080 imds-800 microvax1 pdp10-ka s3 vax730
vaxstation4000vlc
- Mark
12:44 a.m.
On Feb 24, 2020, at 1:28 PM, Fred <fcoffey at misernet.net> wrote:
My area router, FRUGAL, boots fine and gets adjacency with my Multinet-over-IP
connections, that is, LEGATO, MIM, and 31.3:: as well as other DECNet hosts (MISER,
CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a bit
with local DECNet hosts as well as the ip-connection to 31.3::
Are you sure that the problem is on your end? PDXVAX is my area router, it?s also the
only physical system I have online at this time (a VAXstation 4000/60). I have quite a
bit of flapping. I?m using Johnny?s bridge software on an OpenBSD system. I figure part
of the problem is the distance.
Zane
12:49 a.m.
FWIW, I think the "flapping" is a Multinet problem. I have no problems
with simh and DECnet connections over the local Ethernet.
Version 3 of simh is a bit old. I'm running
MicroVAX 3900 simulator V4.0-0 Current git commit id:
8bec55b9
You can get it from GitHub
https://github.com/simh/simh
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Fred
Sent: Monday, February 24, 2020 1:28 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] SIMH experience?
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the
current 3.11 that I found - is there a newer version?)
Main host runs Devuan Linux (yes, I'm a systemd hater). VirtualBox VM
hosts the SIMH instance, also running Devuan Linux.
My area router, FRUGAL, boots fine and gets adjacency with my
Multinet-over-IP connections, that is, LEGATO, MIM, and 31.3:: as well as
other DECNet hosts (MISER, CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a
bit with local DECNet hosts as well as the ip-connection to 31.3::
I've tried eliminating the connection to 31.3:: as the culprit by turning
off the circuit, and the connection between FRUGAL:: and MISER:: (both
local nodes) continues to go up and down every few minutes.
I'd welcome some pointers, things to check, etc. Is there such a thing as
an adjacency timer perhaps I could crank up a bit?
Thanks
Fred
1:01 a.m.
You know I personally, like the versions kept up at simh's website. I
couldn't figure out how to get my license working on the "master"
version, so I have the latest from https://simh.trailing-edge.com if
that's the right URL. You simply create the ISO mount it and change some
attribs and install the license.
Bill
On 2/24/2020 6:49 PM, Robert Armstrong wrote:
FWIW, I think the "flapping" is a
Multinet problem. I have no problems
with simh and DECnet connections over the local Ethernet.
Version 3 of simh is a bit old. I'm running
MicroVAX 3900 simulator V4.0-0 Current git commit id:
8bec55b9
You can get it from GitHub
https://github.com/simh/simh
Bob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Fred
Sent: Monday, February 24, 2020 1:28 PM
To: hecnet at Update.UU.SE
Subject: [HECnet] SIMH experience?
Hi all
I've moved my SIMH VAXen to a new host with a new version of SIMH (the
current 3.11 that I found - is there a newer version?)
Main host runs Devuan Linux (yes, I'm a systemd hater). VirtualBox VM
hosts the SIMH instance, also running Devuan Linux.
My area router, FRUGAL, boots fine and gets adjacency with my
Multinet-over-IP connections, that is, LEGATO, MIM, and 31.3:: as well as
other DECNet hosts (MISER, CHEAP)
However, the connection from FRUGAL "flaps" (going up and down) quite a
bit with local DECNet hosts as well as the ip-connection to 31.3::
I've tried eliminating the connection to 31.3:: as the culprit by turning
off the circuit, and the connection between FRUGAL:: and MISER:: (both
local nodes) continues to go up and down every few minutes.
I'd welcome some pointers, things to check, etc. Is there such a thing as
an adjacency timer perhaps I could crank up a bit?
Thanks
Fred
1:28 a.m.
On Feb 24, 2020, at 6:49 PM, Robert Armstrong <bob
at jfcl.com> wrote:
FWIW, I think the "flapping" is a Multinet problem. I have no problems
with simh and DECnet connections over the local Ethernet.
Not surprising. Multinet is a design error. With enough effort it can be made to work to
some extent, but it's by far the least desirable of all your communication
possibilities.
Multinet over UDP is especially evil. Multinet over TCP isn't quite as bad, so if you
must use Multinet, be sure to use the TCP flavor.
However, anything else is better. GRE and Johnny's bridge software are two good
options. Another one, if you use SIMH, is to use a DDCMP connection. All these options
are correctly designed and should work well. If the network connection is lossy, DDCMP is
probably the best option.
paul
2:01 a.m.
On Mon, 24 Feb 2020 19:28:41 -0500, Paul Koning wrote:
Multinet over UDP is especially evil. Multinet over
TCP isn't quite as bad,
so if you must use Multinet, be sure to use the TCP flavor.
However, anything else is better. GRE and Johnny's bridge software are two
good options. Another one, if you use SIMH, is to use a DDCMP connection.
If I'm not wrong, Multinet over UDP does not work well at all because it
makes use of a point-to-point connection which in turn implies an underlying
error-free link that UDP could not actually offer.
Probably I'm missing something else, but wouldn't the TCP flavor be of
comparable reliabilty to other solutions, given that TCP would present to
the point-to-point link a dependable error-free path?
Thanks! :)
G.
2:17 a.m.
On Feb 24, 2020, at 8:01 PM, G. <gerry77 at
mail.com> wrote:
On Mon, 24 Feb 2020 19:28:41 -0500, Paul Koning wrote:
It would be possible to build something similar to the Multinet protocol, over TCP, that
is architecturally correct. But what Multinet actually does isn't, so no, it does NOT
provide reliability comparable to other solutions.
Take a look at the DECnet routing layer spec, the list of requirements it gives for
"point to point data links". That's what Multinet pretends to be, but it
fails to implement many of the stated requirements.
For the TCP case, a correct design would tell the routing layer about the establishment of
a new connection and the loss of that connection. Multinet does not do this. So the
synchronization services that Routing expect the data link to provide are missing.
GRE avoids this issue by acting as a broadcast (LAN-like) link, which has simpler
requirements that GRE indeed meets. And DDCMP, of course, also works correctly because
its data link layer delivers the necesary signals up to the routing layer.
paul
Multinet over UDP is especially evil. Multinet
over TCP isn't quite as bad,
so if you must use Multinet, be sure to use the TCP flavor.
However, anything else is better. GRE and Johnny's bridge software are two
good options. Another one, if you use SIMH, is to use a DDCMP connection.
If I'm not wrong, Multinet over UDP does not work well at all because it
makes use of a point-to-point connection which in turn implies an underlying
error-free link that UDP could not actually offer.
Probably I'm missing something else, but wouldn't the TCP flavor be of
comparable reliabilty to other solutions, given that TCP would present to
the point-to-point link a dependable error-free path?
26 Feb
26 Feb
2:33 a.m.
On 2020-02-25 02:17, Paul Koning wrote:
I'm signalling to the DECnet layer when a TCP connection is established
or lost. So it's not impossible to do this.
However, Multinet is doing weird things, which I think are carryovers
from their UDP implementation. Which means I have to do some really
strange stuff in order to properly interoperate with VMS Multinet from
RSX. As an alternative, I can run TCP links in the more straightforward
form as well, which is way simpler and makes more sense.
But that obviously only works against other RSX systems. Might be that
it could also work towards PyDECnet, or else this would at least be easy
to implement.
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 Feb 24, 2020, at 8:01 PM, G. <gerry77 at
mail.com> wrote:
Probably I'm missing something else, but wouldn't the TCP flavor be of
comparable reliabilty to other solutions, given that TCP would present to
the point-to-point link a dependable error-free path?
It would be possible to build something similar to the Multinet protocol, over TCP, that
is architecturally correct. But what Multinet actually does isn't, so no, it does NOT
provide reliability comparable to other solutions.
Take a look at the DECnet routing layer spec, the list of requirements it gives for
"point to point data links". That's what Multinet pretends to be, but it
fails to implement many of the stated requirements.
For the TCP case, a correct design would tell the routing layer about the establishment
of a new connection and the loss of that connection. Multinet does not do this. So the
synchronization services that Routing expect the data link to provide are missing.
25 Feb
25 Feb
5:12 a.m.
GRE and Johnny's bridge software are two good
options.
The problem with Johnny's bridge is that it turns everything into a giant
Ethernet segment. Everybody appears to be adjacent to everybody else.
That's not realistic and doesn't scale well.
GRE is a non-starter unless you have a Cisco router.
If you don't like Multinet, write something better. Make sure it works on
a VAX...
Bob
7:28 a.m.
GRE is a non-starter unless you have a Cisco router.
I used to run my GRE tunnels over both real and emulated Cisco routers,
until I discovered Paul's PyDECnet and it was a drop in replacement for
my Cisco.
It's probably the simplest way to get connectivity running. I've setup
my office machine which is GRE connected upstream into HECnet and a
secondary GRE connection to my home where I have another host. DECnet
works exactly as I would expect.
I know we've all said it before, but kudos again to Paul for one of the
most useful pieces of networking code. With DECnet support being
deprecated everywhere (including a broken Linux kernel implementation),
it was refreshing to see something current and working on modern boxes.
Cheers, Wiz!!
8:03 a.m.
On 2/25/20 1:28 AM, David Moylan wrote:
I know we've all said it before, but kudos again
to Paul for one of the
most useful pieces of networking code.
Cannot be said enough times! Thanks to Paul, all of my GRE mesh links
AND MULTINET mesh links are on instances of DECnet/Python (rev 486 -
rock solid).
BTW I can easily support any area owners who want to migrate away from
Johnny's bridge to MULTINET/TCP or GRE and is not on Area 1. It wouldn't
take more than a half-hour for people on this list to download and
configure DECnet/Python as a direct replacement for Johnny's bridge (or
a dynamips/real CISCO switch or a MULTINET link running on a VAX/PDP -
no hobbyist license is needed for DECnet/Python!).
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
26 Feb
26 Feb
2:40 a.m.
On 2020-02-25 08:03, Supratim Sanyal wrote:
On 2/25/20 1:28 AM, David Moylan wrote:
In general, I recommend that people connect to points nearby that
support the type of connection they need. So no need to try and collect
all people to one place.
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
I know we've all said it before, but kudos
again to Paul for one of the
most useful pieces of networking code.
Cannot be said enough times! Thanks to Paul, all of my GRE mesh links
AND MULTINET mesh links are on instances of DECnet/Python (rev 486 -
rock solid).
BTW I can easily support any area owners who want to migrate away from
Johnny's bridge to MULTINET/TCP or GRE and is not on Area 1. It wouldn't
take more than a half-hour for people on this list to download and
configure DECnet/Python as a direct replacement for Johnny's bridge (or
a dynamips/real CISCO switch or a MULTINET link running on a VAX/PDP -
no hobbyist license is needed for DECnet/Python!). 
25 Feb
25 Feb
5:12 p.m.
I know we've all said it before, but kudos again to Paul for one of the
most useful pieces of networking code. With DECnet support being
deprecated everywhere (including a broken Linux kernel implementation),
it was refreshing to see something current and working on modern boxes.
Not entirely everywhere. I have a github repository with a functional linux kernel
implementation (end-node only) for Raspbian on the Raspberry Pi, last tested with the
2020-02-05 distribution. In the past (late last year), I also verified that it works
correctly on Debian-x86, both 32- and 64-bit. The repository is at:
<https://github.com/JohnForecast/RaspbianDECnet
<https://github.com/JohnForecast/RaspbianDECnet>>
John.
8:33 a.m.
The fact that the bridge turns everything into a single Ethernet segment is
one of the reasons why I wrote my own user mode router. It interoperates
with the bridge and also SIMH DDCMP (although I haven't tried that for a
while and it looks like I haven't documented the fact either!).
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf
Of Robert Armstrong
Sent: 25 February 2020 04:13
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] SIMH experience?
giant
GRE and Johnny's bridge software are two
good options.
The problem with Johnny's bridge is that it turns everything into a Ethernet segment. Everybody appears to be adjacent to
everybody else.
That's not realistic and doesn't scale well.
GRE is a non-starter unless you have a Cisco router.
If you don't like Multinet, write something better. Make sure it works
on a
VAX...
Bob
11:22 a.m.
All the negative comments I?ve seen about Multinet...
I?ve never had a problem with it, connecting nodes across the Internet via TCP. The only
dislike I have is it?s half-baked attempt at providing a $QIO interface for I/O (I?m
comparing it to CMUTEK TCPIP of fond memory)
Nowadays, thanks to pydecnet, the DECnet over Internet part of my setup is handled by that
and the rest is Ethernet (mixture of real, tap and ether to bridge devices). One day I?ll
get around to GRE.... perhaps when I get my first real Alpha box
Keith
On 25 Feb 2020, at 07:33, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
?The fact that the bridge turns everything into a single Ethernet segment is
one of the reasons why I wrote my own user mode router. It interoperates
with the bridge and also SIMH DDCMP (although I haven't tried that for a
while and it looks like I haven't documented the fact either!).
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf
Of Robert Armstrong
Sent: 25 February 2020 04:13
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] SIMH experience?
giant
GRE and Johnny's bridge software are two good
options.
The problem with Johnny's bridge is that it turns everything into a Ethernet segment. Everybody appears to be
adjacent to everybody else.
That's not realistic and doesn't scale well.
GRE is a non-starter unless you have a Cisco router.
If you don't like Multinet, write something better. Make sure it works
on a
VAX...
Bob
3:49 p.m.
On Feb 25, 2020, at 2:33 AM, Rob Jarratt
<robert.jarratt at ntlworld.com> wrote:
The fact that the bridge turns everything into a single Ethernet segment is
one of the reasons why I wrote my own user mode router. It interoperates
with the bridge and also SIMH DDCMP (although I haven't tried that for a
while and it looks like I haven't documented the fact either!).
Regards
Rob
I should mention that Rob's work was what inspired PyDECnet.
On Feb 25, 2020, at 5:22 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
All the negative comments I?ve seen about Multinet...
I?ve never had a problem with it, connecting nodes across the Internet via TCP.
Yes, it often can look ok.
Part of my dislike of it comes from the fact that it is obvious it was created by people
who had never paid serious attention to the DECnet architecture specifications. And part
of it comes from the hacks and workarounds I needed to make in PyDECnet to get it to work
-- for some definition of "work". The need for those hacks is a direct
consequence of the ignorance of the Multinet designers.
I know from experience it can never be truly reliable in the sense of dealing well with
nodes restarting or flaky networks. The most I can possibly do is work around its
fundamental design errors to the point that links will, in general, come up eventually and
will stay up if the winds are fair.
paul
7:25 p.m.
-----Original Message-----
From: owner-hecnet at Update.UU.SE <owner-hecnet at Update.UU.SE> On Behalf
Of Paul Koning
Sent: 25 February 2020 14:50
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] SIMH experience?
And I should mention that I couldn't have done it without Paul's help.
On Feb 25, 2020, at 2:33 AM, Rob Jarratt
<robert.jarratt at ntlworld.com>
wrote:
The fact that the bridge turns everything into a single Ethernet
segment is one of the reasons why I wrote my own user mode router. It
interoperates with the bridge and also SIMH DDCMP (although I haven't
tried that for a while and it looks like I haven't documented the fact either!).
Regards
Rob
I should mention that Rob's work was what inspired PyDECnet.
On Feb 25, 2020, at 5:22 AM, Keith Halewood
<Keith.Halewood at pitbulluk.org> wrote:
All the negative comments I?ve seen about Multinet...
I?ve never had a problem with it, connecting nodes across the Internet via
TCP.
Yes, it often can look ok.
Part of my dislike of it comes from the fact that it is obvious it was created by
people who had never paid serious attention to the DECnet architecture
specifications. And part of it comes from the hacks and workarounds I needed
to make in PyDECnet to get it to work -- for some definition of "work". The
need for those hacks is a direct consequence of the ignorance of the Multinet
designers.
I know from experience it can never be truly reliable in the sense of dealing
well with nodes restarting or flaky networks. The most I can possibly do is work
around its fundamental design errors to the point that links will, in general,
come up eventually and will stay up if the winds are fair.
paul
26 Feb
26 Feb
2:36 a.m.
On 2020-02-25 05:12, Robert Armstrong wrote:
The biggest problem with it is scaling, and that I have not implemented
anything like STP.
Apart from that, it usually works very well, covering about half of the
earth.
GRE and
Johnny's bridge software are two good options.
The problem with Johnny's bridge is that it turns everything into a giant
Ethernet segment. Everybody appears to be adjacent to everybody else.
That's not realistic and doesn't scale well. GRE is a non-starter unless you have a Cisco
router.
If you don't like Multinet, write something better. Make sure it works on
a VAX...
Which is a big problem. Most people do not even have the information
needed to write something that would hook into DECnet this way.
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
25 Feb
25 Feb
1:54 p.m.
On Mon, 24 Feb 2020, Robert Armstrong wrote:
FWIW, I think the "flapping" is a Multinet
problem. I have no problems
with simh and DECnet connections over the local Ethernet.
I'm not doubting you, but I'm not sure about that.
Even the connection from FRUGAL and MISER flap with the circuit to 31.3::
turned off. That's just DECNET to my knowledge.
For the record, the circuits to LEGATO and MIM do not flap. It's very
odd.
Upgrading SIMH was on my consideration list. I may try this.
Thanks everyone for the tips so far.
Supratim: I do not have SIMH nice'd down - just have CPU idle set. Not
to be "that guy" (I hate it when users do this, so I hesistate to say
this) but on my other host system (probably running an even older version
of SIMH) it did not flap this badly.
(more messages to wade through ....)
Fred
3:40 p.m.
Fred,
Disconnect from the external backbone and see if the behavior continues. That way you will
narrow down the source.
-Steve Davidson
SF:iP1
On Feb 25, 2020, at 07:54, Fred <fcoffey at
misernet.net> wrote:
?On Mon, 24 Feb 2020, Robert Armstrong wrote:
FWIW, I think the "flapping" is a
Multinet problem. I have no problems
with simh and DECnet connections over the local Ethernet.
I'm not doubting you, but I'm not sure about that.
Even the connection from FRUGAL and MISER flap with the circuit to 31.3:: turned off.
That's just DECNET to my knowledge.
For the record, the circuits to LEGATO and MIM do not flap. It's very odd.
Upgrading SIMH was on my consideration list. I may try this.
Thanks everyone for the tips so far.
Supratim: I do not have SIMH nice'd down - just have CPU idle set. Not to be
"that guy" (I hate it when users do this, so I hesistate to say this) but on my
other host system (probably running an even older version of SIMH) it did not flap this
badly.
(more messages to wade through ....)
Fred
26 Feb
26 Feb
2:51 a.m.
On 2020-02-25 13:54, Fred wrote:
On Mon, 24 Feb 2020, Robert Armstrong wrote:
Fred, in general I do not think circuits should be flapping.
So feel free to give some more details, and maybe we can help figure out
what the problem is...
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
?FWIW, I think the "flapping" is a
Multinet problem.? I have no problems
with simh and DECnet connections over the local Ethernet.
I'm not doubting you, but I'm not sure about that.
Even the connection from FRUGAL and MISER flap with the circuit to
31.3:: turned off.? That's just DECNET to my knowledge.
For the record, the circuits to LEGATO and MIM do not flap.? It's very odd.
Upgrading SIMH was on my consideration list.?? I may try this.
Thanks everyone for the tips so far.
2:03 p.m.
On Wed, 26 Feb 2020, Johnny Billquist wrote:
Fred, in general I do not think circuits should be
flapping.
So feel free to give some more details, and maybe we can help figure out what
the problem is...
I agree.
Yesterday, I upgraded from SIMH 3.11 to 4(mumble) that is available on
github. The local adjancencies between MISER, FRUGAL, and CHEAP are no
longer flapping and there have only been a handful of Multinet links going
up and down since 16:53 Eastern time yesterday. None since 21:53 local
time. So, I'd say that's "better" but not ideal.
Previously, the operator.log on VMS was "full" of flap messages, to both
Multinet links and local adjacencies.
I'm open to share more details as needed. What would you like to know?
I know that due to my own doing there are multiple layers at play here
(Linux, VirtualBox Linux VM, *then* SIMH) but that's more for my
convenience for ease of management and to not pollute the underlying
physical Linux host.
Fred
2:27 p.m.
On 2/26/20 8:03 AM, Fred wrote:
there have only been a handful of Multinet links going
up and down
since 16:53 Eastern time yesterday.
Ummm ... sorry Fred ... they are probably legit; PYRTR (31.3) was
restarted numerous times yesterday right during that time range ...
--
Supratim Sanyal, W1XMT
39.19151 N, 77.23432 W
QCOCAL::SANYAL via HECnet
2:59 p.m.
On Wed, 26 Feb 2020, Supratim Sanyal wrote:
Ummm ... sorry Fred ... they are probably legit; PYRTR
(31.3) was restarted
numerous times yesterday right during that time range ...
No problem!
I don't want to start a constant posting of when the links go down, but in
this case since you said they are legit, I *think* that just maybe that
those flaps are nothing to be concerned about since that will obviously
happen when hosts reboot/get changed/etc.
This also means that FRUGAL has been rather quiet since 16:41 Eastern
yesterday. (other than known drops/swaps)
Fred
1524
days inactive
1526
days old
26 comments
14 participants
participants (14)
-
bill.cu＠suddenlink.net -
bob＠jfcl.com -
bqt＠softjar.se -
djm＠wiz.net.au -
fcoffey＠misernet.net -
gerry77＠mail.com -
healyzh＠avanthar.com -
john＠forecast.name -
Keith.Halewood＠pitbulluk.org -
Mark＠infocomm.com -
paulkoning＠comcast.net -
robert.jarratt＠ntlworld.com -
steve＠davidson.net -
supratim＠riseup.net