On May 27, 2014, at 8:53 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 22:09, Paul_Koning at Dell.com wrote:
On May 27, 2014, at 4:04 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 21:48, Bob Armstrong wrote:
The way to run DECnet over a flaky long distance network is to use point
to point mode with a data link layer that deals with packet loss.
Probably a good idea, but we don't have that option on HECnet.
Well, HECnet is not a static piece of equipment. Anything is possible...
My bridge emulates a simple ethernet segment. Good enough many times, but if we have a link like yours, that sometimes seems to drop packets, then maybe some other alternative should be considered.
Now, the question then becomes, what can we do in this case.
As far as I understand, links using Multinet are more broken, and still use UDP. The same would appear to possibly be the case for Cisco as well?
Do anyone run any links using TCP?
That would work. DDCMP over UDP would work.
Really? UDP can cause packets to arrive in the wrong order, duplicated, or sometimes dropped. I was certain you wrote above "a data link layer that deals with packet loss". Or was that not meant to be read as that the underlaying transport should deal with it?
DDCMP is a data link layer that deals with packet loss. It also deals with reordering, within reason, by treating it as packet loss, just as NSP did until Phase V. It should be ok with limited duplication as well though duplication is not one of the supposed characteristics of UDP.
Note that I meant the DDCMP protocol, not the DDCMP point to point service. In other words, the UDP packets would carry DDCMP frames, with DDCMP header (including sequence number and all that). I think SIMH has that right now, in V4.0 DMC emulation.
paul
Higher up the thread there was mention of using DDCMP, and also of the fact that missing 3 hello messages will cause the adjacency to go down.
Well, the user mode router I have written implements DDCMP now, over TCP. It still has some strange issues that I need to resolve, and it is only passive (ie it won't initiate a connection to a peer). But, it is mostly there otherwise. You can work around the passiveness by using SIMH at the other end and using the emulated DMC11.
Additionally, while I implement the 3 hello limit for Ethernet circuits (BC3TMULT in the routing spec), that could be changed quite easily to be a higher limit, but you would need the router to be configured the same way at both ends of the link for that to work.
Regards
Rob
On 28 May 2014 07:47, Pontus Pihlgren <pontus at update.uu.se> wrote:
On Tue, May 27, 2014 at 11:13:05PM +0200, Peter Lothberg wrote:
>
> (I might even find a switch that does it right and send it to Update)
If you do, we'll try not to procrastinate setting it up for a year :-)
/P
On 2014-05-28 08:52, Cory Smelosky wrote:
Hello all,
So...I have an 11/23+ here that runs RSTS/E and RSX-11M+ however...it
fails to even BOOT XXDP. Which is...interesting to say the least.
The disk image I made booted fine in simh. When I boot it it just drops
me back to ODT with the last address...which was REALLY soon after boot.
Could it be the same RSTS/E disk image size issue I had before? Any
ideas? My bus is contiguous, this part of memory is good, and RSTS/E
and RSX-11M+ work fine.
I would guess on a bad XXDP image, since XXDP requires almost nothing working. If RSRS/E and RSX works then I can't imagine XXDP not working.
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
--
DECtec mailing list
http://dectec.info
To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
Hello all,
So...I have an 11/23+ here that runs RSTS/E and RSX-11M+ however...it fails to even BOOT XXDP. Which is...interesting to say the least.
The disk image I made booted fine in simh. When I boot it it just drops me back to ODT with the last address...which was REALLY soon after boot.
Could it be the same RSTS/E disk image size issue I had before? Any ideas? My bus is contiguous, this part of memory is good, and RSTS/E and RSX-11M+ work fine.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Tue, May 27, 2014 at 11:13:05PM +0200, Peter Lothberg wrote:
(I might even find a switch that does it right and send it to Update)
If you do, we'll try not to procrastinate setting it up for a year :-)
/P
On 2014-05-27 23:13, Peter Lothberg wrote:
When we where chasing another problem, it was found that packets
"disapear" in the Ethernet fabric at Update, sometimes.
I think you are referring to when we played with transfers and the
performance drops to the floor. That is lost packets because of
interface speed differences. They are not really lost, but there only so
much that can be queued up in the fabric between interfaces with
different speeds.
Maybe Johnny can make a small map of the current topology with all
involved things and the lan-speeds?
That would actually be useful either way, but I'm not sure I can do it
easily.
Johnny
If it was only ONE switch used for all the DECnet speaking things at
Update, it would be simple to make a drawing. And with only one device
per port, I think any resonable switch has enough buffers to make it
work way better.
--P
(I might even find a switch that does it right and send it to Update)
Well, if it was only Update then the obvious other solution would be to just force everything to use 10 Mb/s. I don't think that other than that, changing the switch would help much. If a maching is throwing out DECnet packets on a 100Mb/s interface, and it is received by a machine with a 10Mb/s interface, DECnet will suck because of the way DECnet handles packet loss and so on. Probably made even worse by really slow physical machines that don't even read out the packets from the ethernet interface at any good rates... (Hey, a PDP-11 isn't exactly super fast...)
However, the same problem appears for anyone anywhere when they try to use DECnet locally. If you run it over my bridge, I actually reshape the traffic to make it ok (that is what the throttling is about, Bob).
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-27 22:09, Paul_Koning at Dell.com wrote:
On May 27, 2014, at 4:04 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2014-05-27 21:48, Bob Armstrong wrote:
The way to run DECnet over a flaky long distance network is to use point
to point mode with a data link layer that deals with packet loss.
Probably a good idea, but we don't have that option on HECnet.
Well, HECnet is not a static piece of equipment. Anything is possible...
My bridge emulates a simple ethernet segment. Good enough many times, but if we have a link like yours, that sometimes seems to drop packets, then maybe some other alternative should be considered.
Now, the question then becomes, what can we do in this case.
As far as I understand, links using Multinet are more broken, and still use UDP. The same would appear to possibly be the case for Cisco as well?
Do anyone run any links using TCP?
That would work. DDCMP over UDP would work.
Really? UDP can cause packets to arrive in the wrong order, duplicated, or sometimes dropped. I was certain you wrote above "a data link layer that deals with packet loss". Or was that not meant to be read as that the underlaying transport should deal with it?
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
When we where chasing another problem, it was found that packets
"disapear" in the Ethernet fabric at Update, sometimes.
I think you are referring to when we played with transfers and the
performance drops to the floor. That is lost packets because of
interface speed differences. They are not really lost, but there only so
much that can be queued up in the fabric between interfaces with
different speeds.
Maybe Johnny can make a small map of the current topology with all
involved things and the lan-speeds?
That would actually be useful either way, but I'm not sure I can do it
easily.
Johnny
If it was only ONE switch used for all the DECnet speaking things at
Update, it would be simple to make a drawing. And with only one device
per port, I think any resonable switch has enough buffers to make it
work way better.
--P
(I might even find a switch that does it right and send it to Update)
Area 44 is missing from the list.
Johnny, did you turn off the bridge link to my LAN?
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Bob Armstrong
Verzonden: dinsdag 27 mei 2014 22:50
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] "Dropped by adjacent node" ....
I appreciate the suggestions, but I'm not really interested in trying to
re-architect HECnet. That's a losing battle - I just want my node to work
:-)
I tried sending the USR1 signal to the bridge program and got this -
0: legato 0.0.0.0:0000 (Rx: 827 Tx:11017 (Drop rx: 6)) Active: 1
Throttle: 278(114)
1: psilo 130.238.19:4711 (Rx:11044 Tx: 821 (Drop rx: 27)) Active: 1
Throttle: 115(332)
Hash of known destinations:
aa0004000d04 -> 1 (1.13)
aa0004000f04 -> 1 (1.15)
aa0004001404 -> 1 (1.20)
aa0004001504 -> 1 (1.21)
aa0004005e05 -> 1 (1.350)
aa000400c205 -> 1 (1.450)
aa0004000108 -> 0 (2.1)
aa000400f810 -> 1 (4.248)
aa000400ff17 -> 1 (5.1023)
aa0004009021 -> 1 (8.400)
aa0004009121 -> 1 (8.401)
aa000400bc21 -> 1 (8.444)
aa000400f421 -> 1 (8.500)
aa000400022c -> 1 (11.2)
aa000400032c -> 1 (11.3)
aa000400642c -> 1 (11.100)
aa0004000138 -> 1 (14.1)
aa000400284c -> 1 (19.40)
aa000400294c -> 1 (19.41)
aa0004000470 -> 1 (28.4)
aa0004002970 -> 1 (28.41)
aa000400feab -> 1 (42.1022)
aa0004002fbc -> 1 (47.47)
aa0004004dbd -> 1 (47.333)
aa0004002bbe -> 1 (47.555)
aa0004002cbe -> 1 (47.556)
aa0004002fbe -> 1 (47.559)
aa000400bcbe -> 1 (47.700)
aa000400bdbe -> 1 (47.701)
aa000400d7be -> 1 (47.727)
aa0004000bec -> 1 (59.11)
aa00040005f8 -> 1 (62.5)
aa0004007dfa -> 1 (62.637)
Note that I restarted it about 30 minutes ago, so this data is just for
that period of time. My first observation is that's a lot of routing nodes,
but that's probably neither here nor there.
Also I'm struck by the asymmetry in the number of packets sent vs
received. I guess that makes sense, since I'm transmitting routing and
hello messages for only one node (LEGATO) and receiving them from beaucoup
nodes.
And I'm not sure that the throttling in the bridge is about...
Bob
I appreciate the suggestions, but I'm not really interested in trying to
re-architect HECnet. That's a losing battle - I just want my node to work
:-)
I tried sending the USR1 signal to the bridge program and got this -
0: legato 0.0.0.0:0000 (Rx: 827 Tx:11017 (Drop rx: 6)) Active: 1
Throttle: 278(114)
1: psilo 130.238.19:4711 (Rx:11044 Tx: 821 (Drop rx: 27)) Active: 1
Throttle: 115(332)
Hash of known destinations:
aa0004000d04 -> 1 (1.13)
aa0004000f04 -> 1 (1.15)
aa0004001404 -> 1 (1.20)
aa0004001504 -> 1 (1.21)
aa0004005e05 -> 1 (1.350)
aa000400c205 -> 1 (1.450)
aa0004000108 -> 0 (2.1)
aa000400f810 -> 1 (4.248)
aa000400ff17 -> 1 (5.1023)
aa0004009021 -> 1 (8.400)
aa0004009121 -> 1 (8.401)
aa000400bc21 -> 1 (8.444)
aa000400f421 -> 1 (8.500)
aa000400022c -> 1 (11.2)
aa000400032c -> 1 (11.3)
aa000400642c -> 1 (11.100)
aa0004000138 -> 1 (14.1)
aa000400284c -> 1 (19.40)
aa000400294c -> 1 (19.41)
aa0004000470 -> 1 (28.4)
aa0004002970 -> 1 (28.41)
aa000400feab -> 1 (42.1022)
aa0004002fbc -> 1 (47.47)
aa0004004dbd -> 1 (47.333)
aa0004002bbe -> 1 (47.555)
aa0004002cbe -> 1 (47.556)
aa0004002fbe -> 1 (47.559)
aa000400bcbe -> 1 (47.700)
aa000400bdbe -> 1 (47.701)
aa000400d7be -> 1 (47.727)
aa0004000bec -> 1 (59.11)
aa00040005f8 -> 1 (62.5)
aa0004007dfa -> 1 (62.637)
Note that I restarted it about 30 minutes ago, so this data is just for
that period of time. My first observation is that's a lot of routing nodes,
but that's probably neither here nor there.
Also I'm struck by the asymmetry in the number of packets sent vs
received. I guess that makes sense, since I'm transmitting routing and
hello messages for only one node (LEGATO) and receiving them from beaucoup
nodes.
And I'm not sure that the throttling in the bridge is about...
Bob
