On 16 Feb 2013, at 19:51, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-02-17 01:28, Clem Cole wrote:
Linux ip/tcp stack is not the bbn/bsd derived code. it was independently developed so the fact that they are differences is not surprising. one of my own personal gripes about Linux is the desire/need to redo things from scratch (ext fs comes to find here also).
I seem to remember that they have in fact had several implementations, as their first attempts really sucked (Linux people take some pride in the many iterations they do of implementations, it would seem).
"Linux 2.6.19-243" and crazy patchsets/build numbers. ;) Yes. Linux people do take some pride in many implementations of well, anything. ;)
I would not be surprised to learn that after a few failed attempts, they "borrows" parts of the BSD code for their TCP/IP, but I have not looked properly at it in quite a number of years.
The GNU project would never borrow userspace code. Kernelspace code however could be borrowed although I think that'd "taint" the kernel. ;)
Johnny
On Feb 16, 2013, at 4:41 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
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."
--
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-17 01:28, Clem Cole wrote:
Linux ip/tcp stack is not the bbn/bsd derived code. it was independently developed so the fact that they are differences is not surprising. one of my own personal gripes about Linux is the desire/need to redo things from scratch (ext fs comes to find here also).
I seem to remember that they have in fact had several implementations, as their first attempts really sucked (Linux people take some pride in the many iterations they do of implementations, it would seem).
I would not be surprised to learn that after a few failed attempts, they "borrows" parts of the BSD code for their TCP/IP, but I have not looked properly at it in quite a number of years.
Johnny
On Feb 16, 2013, at 4:41 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
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."
--
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
Linux ip/tcp stack is not the bbn/bsd derived code. it was independently developed so the fact that they are differences is not surprising. one of my own personal gripes about Linux is the desire/need to redo things from scratch (ext fs comes to find here also).
On Feb 16, 2013, at 4:41 PM, Gregg Levine <gregg.drwho8 at gmail.com> wrote:
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 Feb 16, 2013, at 4:59 PM, 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 read that as "only the first of the several physical addresses is used..." not "only the address in the first slot". If they intended it to be interpreted as you did, they sure wrote it badly.
paul
On 2013-02-16 23:12, John Wilson wrote:
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.
You are probably right, John, in which case simh does it wrong.
Reading through the whole section over and over, it do feel more like it would scan through the list and grab the first non-broadcast address (no matter which column it is in), and use that one.
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
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."
