From: <Paul_Koning at Dell.com>
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states
that the first address is used as the source address for system ID messages.
Which edition? I'm looking at EK-DELQA-UG-002 (from Bitsavers) and it can't
find anything like that.
I have the same edition (hardcopy) and I think the final paragraph on 3-31
is just being read wrong. They talk about the "first" physical address, but
it seems like what they mean is the first address that's a physical address,
not any address of any kind that's in the first slot of the SETUP packet.
I take that to mean (and this is what E11 does) the LQA doesn't work the
same way as the QNA, so while the QNA hardware may blindly accept anything
that matches any slot in the SETUP packet, the LQA searches that list for
the first non-broadcast/non-multicast address and takes that to be the One
True Address, and that's what goes in system ID frames and gets set in the
Ethernet chip as the station address for reception. That certainly seems
like the cleanest interpretation, and DEC was pretty good about picking
the clean choice over the quick-and-dirty one.
I'm kind of swamped but if anyone's really lying awake nights worrying about
this, I do have a real DELQA and a BA23 here that I guess I could set up
with a bus adapter for testing (either under RSTS or I could hack up my XH:
test code to try different stuff in SETUP packets). Lemme know.
John Wilson
D Bit
On 2013-02-16 22:59, Johnny Billquist wrote:
On 2013-02-16 22:45, Paul_Koning at Dell.com wrote:
On Feb 15, 2013, at 9:24 PM, Johnny Billquist wrote:
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some
multicast address (such as broadcast) into slot 0 of the 16-entry
address match table, and the station address into slot 1. For a
QNA, that's perfectly fine because all slots are equivalent and the
device doesn't do any MOP. It may be that this was a later
restriction that RSTS didn't obey. Or it may be a bad assumption in
the real LQA that wasn't documented -- or maybe it's just a bad
assumption in the SIMH emulation. I haven't yet looked for LQA
manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual
states that the first address is used as the source address for
system ID messages.
Which edition? I'm looking at EK-DELQA-UG-002 (from Bitsavers) and it
can't find anything like that.
The very same.
Page 3-31, Section 3.6.2.4, third paragraph:
"Any columns not used should be set to the physical address (for better
protection against mischievous Ethernet traffic). More than one physical
address may be specified, but in Normal mode, only the first is used for
receiving datagrams, and as the source address for system ID messages
generated by the DELQA."
I just realized that I might be reading that a bit too strict. "First physical address" could be read as the DELQA scans through the table and takes the first physical address it finds, if the implication is that multicast addresses are not physical addresses.
I have not verified this, but it do seem unlikely that the controller would scan through that table or do any more advanced operations on it ever. But I guess there is some room for interpretation here...
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-16 22:45, Paul_Koning at Dell.com wrote:
On Feb 15, 2013, at 9:24 PM, Johnny Billquist wrote:
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states that the first address is used as the source address for system ID messages.
Which edition? I'm looking at EK-DELQA-UG-002 (from Bitsavers) and it can't find anything like that.
The very same.
Page 3-31, Section 3.6.2.4, third paragraph:
"Any columns not used should be set to the physical address (for better protection against mischievous Ethernet traffic). More than one physical address may be specified, but in Normal mode, only the first is used for receiving datagrams, and as the source address for system ID messages generated by the DELQA."
So I guess RSTS/E just sets it up wrong.
More precisely, RSTS/E is written to DEQNA specs, which don't constrain which address goes where.
Right.
I guess I should see about constructing a patch for this.
That would maybe be a good deed. :-)
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 15, 2013, at 9:24 PM, Johnny Billquist wrote:
On 2013-02-16 03:03, Paul_Koning at Dell.com wrote:
The thing to do would be to see what happens if you load some multicast address (such as broadcast) into slot 0 of the 16-entry address match table, and the station address into slot 1. For a QNA, that's perfectly fine because all slots are equivalent and the device doesn't do any MOP. It may be that this was a later restriction that RSTS didn't obey. Or it may be a bad assumption in the real LQA that wasn't documented -- or maybe it's just a bad assumption in the SIMH emulation. I haven't yet looked for LQA manuals to give more clues.
Ah. I thought you had already checked documentation.
Well, I did now, and simh is right. Page 3-31 of the DELQA manual states that the first address is used as the source address for system ID messages.
Which edition? I'm looking at EK-DELQA-UG-002 (from Bitsavers) and it can't find anything like that.
So I guess RSTS/E just sets it up wrong.
More precisely, RSTS/E is written to DEQNA specs, which don't constrain which address goes where.
I guess I should see about constructing a patch for this.
paul
On Sat, Feb 16, 2013 at 4:33 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-16 01:13, Johnny Billquist wrote:
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I
think looks funny in Linux. But right now my head is also spinning, so
maybe there is something I've just forgotten, or don't know, which
explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but
it's not really hurting anything, but I like my TCP/IP to really do
things as right and optimal as possible.
[...]
Any thoughts, opinions or knowledge always welcome.
Not that I've come any closer to figuring it all out, however I thought I
should mention that I've checked some more against both NetBSD and OS/X and
neither show the behavior I observe in Linux, so I think I'm just going to
attribute this to a crappy implementation on the Linux side. That's not the
first time Linux code turns out to be bad, so I'm not totally surprised...
(And yes, I also tried VMS actually... :-) )
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
Hello!
Johnny I've been arguing with the stack for Linux for about as many
years as I've known about the idea of emulating our friends, the
PDP-11 crowd and those Vaxes. And sadly it happens to be something of
a kludge. Alan Cox and the others behind it are constantly sorting it
out. Fact is, three-quarters of it, happens to be from the land of BSD
and fitted into it rather awkwardly.
So your discoveries must be a surprise to a lot of us, but it confirms
what I've known all along.
Incidentally Dave this isn't your fault.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 2013-02-16 01:13, Johnny Billquist wrote:
Hi. As I'm working on my TCP/IP for RSX, I just noticed something that I
think looks funny in Linux. But right now my head is also spinning, so
maybe there is something I've just forgotten, or don't know, which
explains this. But if anyone can shed some light, I'd be interested.
Just for the record - I *think* that TCP/IP in Linux is misbehaving, but
it's not really hurting anything, but I like my TCP/IP to really do
things as right and optimal as possible.
[...]
Any thoughts, opinions or knowledge always welcome.
Not that I've come any closer to figuring it all out, however I thought I should mention that I've checked some more against both NetBSD and OS/X and neither show the behavior I observe in Linux, so I think I'm just going to attribute this to a crappy implementation on the Linux side. That's not the first time Linux code turns out to be bad, so I'm not totally surprised...
(And yes, I also tried VMS actually... :-) )
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 Sat, Feb 16, 2013 at 3:16 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/16/2013 03:15 PM, Gregg Levine wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
They do.
But what's that big hairy something else doing outside your place?
Gyrating suggestively.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
That word there should be "mind". (Fast keyboard and slow mind.) And
the big hairy thing is trying to get someone out to play with.
Supposedly there's enough stuff on the ground to drive everyone to
distraction.
Did anyone see the news concerning last week's asteroid strike in
Russia? It's being blamed on someone who happens to be on our list.
(And not me.)
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 02/16/2013 03:15 PM, Gregg Levine wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
They do.
But what's that big hairy something else doing outside your place?
Gyrating suggestively.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Sat, Feb 16, 2013 at 3:01 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 02/15/2013 08:53 PM, Johnny Billquist wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Hello!
Only if the occupants next to the machine who happened to be needing
it to keep warm mean. Just six cats of both sizes.
But what's that big hairy something else doing outside your place?
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
On 02/15/2013 08:53 PM, Johnny Billquist wrote:
I was watching the MOP Console system ID messages from DECnet/E on
simh, with an emulated LQA. Noticed something odd: the source address
was broadcast. That's not valid, of course. The question is why that
happened.
The answer is that the emulation uses the address in slot 0 of the
address filter as the source address. The hardware doesn't care what
order the addresses go in as far as filtering is concerned; DECnet/E
puts broadcast in slot 0 and the physical address in slot 1, followed
by any multicast addresses.
Is the SIMH behavior also what a real LQA does? That would be an
interesting DECnet/E bug if so... Or does a real LQA just use the
physical address, as a UNA would?
Hi, Paul. Sorry for not responding sooner. Busy, as usual. However, I
did mark this for some later investigation. However, I now realize that
it's not trivial for me to test, as it would appear a RSTS/E system
would help. :-)
I honestly don't know how a real LQA do. Maybe John Wilson knows more,
since he have been digging into these kind of questions way more than
most people I know...
Or else if you have some realistic suggestion on how I would test this
on my machine, as I do have a 11/93 with a real LQA here (although an
LQA plus).
I can provide access to my RSTS/E machine with a DELQA if that would
be helpful.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
