Feel free to disregard, I was just playing with SPF records and I migrated away from gmail and wanted to make sure emails still get places properly.
Had to make sure, always a chance I broke something. ;)
Also: I will very soon have time to get back to making area 9 work.
The page size on the VAX is 512 bytes and it lacked COW (copy-on-write) HW (long, long story as to why, which I will not try to repeat). In the end, this would be a huge problem with all VAX OSses and HW - take look any of the sources. Us OS guys were basically driven nuts at time about it and there were huge fights with the HW team. Only after all the trouble the VAX MMU caused the OS team, and many of the same folks were working on a different system did we get Dave Cane to relent and he gathered up Tom Teixiera, Terry Hayes, myself and we [the OS team] essentially designed a different MMU (IIRC correctly it was 4K page, but I've forgotten and I'm traveling so I can not look at doc in my basement). I should note that Dave is really is one best HW guys I ever worked with - he had previously led the VAX 750 development and was part of the 780. He is one of the people I most respect from those days.
As a side note, about 2-3 years later with the 386/486 Intel put the MMU "on-die" and Moto would follow suite. Once that happened the MMU and the CPU pretty much were married and you see things become a lot more standardized. But to Intel and friends credit that got learn from all of the others and decide what worked and what did not. FYI: if you look at the MMU in the R2000-R4000 [which fairly soft] and then the Alpha, you'll see the logical progression of what HW was needed, how the TLB (or "TB" if you came from the other religion) was what really mattered. The reality is that SW (the OS) started to really influence the MMU design more than it had 10 years before - particularly as the different UNIX flavors became the world of the day.
If you want to understand it and how it came about, there is a really great discussion of all of this is Curt Schimmell's "UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers"
On Tue, Dec 18, 2012 at 7:39 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2012-12-18 19:05, Clem Cole wrote:
Paul. given the time (late 1960's/early 70's) the prevailing page sizes were 64 / 128 / 256 / 512 bytes which just happen to map to the sizes of blocks used in disk controllers. 1/4/8 k pages were a few years in the future.
by the virtual address extension to the 11 ( aka 1975 's vax 11/780) DEC switched to 512 bytes.
That said as wnj would point out in the "fast vax" paper by 1979 512 bytes was to small.
Um... The page size of the PDP-11 is 8K. :-)
Johnny
Clem
On Dec 18, 2012, at 9:45 AM, <Paul_Koning at Dell.com> wrote:
On Dec 17, 2012, at 6:01 PM, Johnny Billquist wrote:
On 2012-12-17 23:50, Boyanich, Alastair wrote:
...
2) Was 2.11BSD ever ported to other platforms? Given the age/era, I'm
curious about 8088/8086/NECv20/80286 given the banked memory models used
and looking at the 8088/8086 XENIX disassembly.
Nope. That would not have been 2BSD then. And since the PDP-11 don't even have banked memory, it would probably cause some headaches to port 2BSD to something like 80286 or other similar machines.
To make it clear - the PDP-11 have a very normal MMU with pages.
Semi-normal. It's rather unusual in that it has a paged MMU with page address granularity different from the page size (64 bytes vs. 8k bytes). Most architectures have those two match, that avoids an adder -- consider VAX or MIPS or Alpha.
paul
--
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 Dec 18, 2012, at 6:58 PM, Rob Jarratt wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 18 December 2012 22:30
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Phase V Routing Specification
On Dec 18, 2012, at 5:07 PM, Rob Jarratt wrote:
http://bitsavers.trailing-edge.com/pdf/dec/decnet/EK-DNAPV-
GD_DECnet_Phase_V_General_Description_Sep87.pdf
Thanks for the link. I had a quick look. It does not go into the
details of the message formats, but it does say it interoperates with
Phase IV, so I just wonder if it was sufficient for me to accept Phase
V messages as if they were Phase IV and just ignore the version bytes.
I might just give that a quick go, which host is Phase V on HECnet now?
The way to interoperate with a version newer than what you implement is
to speak the protocol as you know it. That includes ignoring fields
you're
supposed to ignore, and messages for protocols (such as Ethertypes or
802.2
DSAPs) you don't implement. If you do that, the rest is up to the newer
version.
What I am doing is checking for routing specification 2.0.0 (in the hello
messages), but not checking for later versions. I have disabled the check
temporarily and it seems to work. But I seem to be getting
EthernetRouterHello messages from node 12.2 with the R/S LIST always empty,
so I never get an adjacency with the node. Not sure if this is because I am
not sending myself to 12.2, but an empty list suggests it can't talk to any
of the other routers in the network.
I see... yes, the way to handle version numbers is in the spec. Basically, it follows the principle I described. Examine the received version number. If it's less than yours, speak that version (if you know how). If it's the same, or greater, speak your version. If the other end announces a greater version number, it will speak to you in what you announced, or give up if it doesn't know how to do that.
This rule is used consistently in DECnet -- we defined this at some point as the general rule of version numbers, it's the easy and reliable way for cross-version compatibility to work. All it requires is that you can find the version number in the first message you see. (For example, in III-IV compatibility, if I remember right, the version number in the first message is checked first even though a bunch of fields precede it, because those fields depend on the version number. Or maybe I'm thinking of II-III compatibility. I can find the code if I search long enough... it was somewhere in DECnet/E.)
paul
On 2012-12-18 19:05, Clem Cole wrote:
Paul. given the time (late 1960's/early 70's) the prevailing page sizes were 64 / 128 / 256 / 512 bytes which just happen to map to the sizes of blocks used in disk controllers. 1/4/8 k pages were a few years in the future.
by the virtual address extension to the 11 ( aka 1975 's vax 11/780) DEC switched to 512 bytes.
That said as wnj would point out in the "fast vax" paper by 1979 512 bytes was to small.
Um... The page size of the PDP-11 is 8K. :-)
Johnny
Clem
On Dec 18, 2012, at 9:45 AM, <Paul_Koning at Dell.com> wrote:
On Dec 17, 2012, at 6:01 PM, Johnny Billquist wrote:
On 2012-12-17 23:50, Boyanich, Alastair wrote:
...
2) Was 2.11BSD ever ported to other platforms? Given the age/era, I'm
curious about 8088/8086/NECv20/80286 given the banked memory models used
and looking at the 8088/8086 XENIX disassembly.
Nope. That would not have been 2BSD then. And since the PDP-11 don't even have banked memory, it would probably cause some headaches to port 2BSD to something like 80286 or other similar machines.
To make it clear - the PDP-11 have a very normal MMU with pages.
Semi-normal. It's rather unusual in that it has a paged MMU with page address granularity different from the page size (64 bytes vs. 8k bytes). Most architectures have those two match, that avoids an adder -- consider VAX or MIPS or Alpha.
paul
--
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 2012-12-18 15:45, Paul_Koning at Dell.com wrote:
On Dec 17, 2012, at 6:01 PM, Johnny Billquist wrote:
On 2012-12-17 23:50, Boyanich, Alastair wrote:
...
2) Was 2.11BSD ever ported to other platforms? Given the age/era, I'm
curious about 8088/8086/NECv20/80286 given the banked memory models used
and looking at the 8088/8086 XENIX disassembly.
Nope. That would not have been 2BSD then. And since the PDP-11 don't even have banked memory, it would probably cause some headaches to port 2BSD to something like 80286 or other similar machines.
To make it clear - the PDP-11 have a very normal MMU with pages.
Semi-normal. It's rather unusual in that it has a paged MMU with page address granularity different from the page size (64 bytes vs. 8k bytes). Most architectures have those two match, that avoids an adder -- consider VAX or MIPS or Alpha.
Details. :-)
Just consider it an extra feature.
However, I think it is actually pretty common in a way today, when you have different page sizes on the MMUs. (But I have not looked exactly how you can use them.)
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
basically the "BUNCH" companies used just about everything in those days. hey the B1700 was bit addressable and switches microcode depending on the language so the MMU's were all over the place
you are right the MMU in the 11 was in today's terms strange but so were many others in those days.
find an old copy of the early 1970's classic Bell, Grason, and Newell's. "computer structures: readings and examples". if you wAnt to learn more about those contemporaries most of the papers describing those systems are in it. Dan Seworiok updated it in the late 1970's and swapped in some then more modern systems
On Dec 18, 2012, at 1:12 PM, <Paul_Koning at Dell.com> wrote:
On Dec 18, 2012, at 1:05 PM, Clem Cole wrote:
Paul. given the time (late 1960's/early 70's) the prevailing page sizes were 64 / 128 / 256 / 512 bytes which just happen to map to the sizes of blocks used in disk controllers. 1/4/8 k pages were a few years in the future.
512 bytes, sure. I'm wondering about other sector sizes. RC11 had 64 byte sectors, RF11 2 byte "sectors". I don't remember any other sector sizes on DEC gear. CDC 6000 series had 322 12-bit word sectors. IBM 360 series used whatever sector size you wanted, varying from sector to sector if you were so inclined.
The PDP11 MMU is an odd beast -- physical start on 64 byte granularity, page size variable between 64 bytes and 8192 bytes, but virtual base addresses only multiples of 8192 bytes.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Paul_Koning at Dell.com
Sent: 18 December 2012 22:30
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Phase V Routing Specification
On Dec 18, 2012, at 5:07 PM, Rob Jarratt wrote:
http://bitsavers.trailing-edge.com/pdf/dec/decnet/EK-DNAPV-
GD_DECnet_Phase_V_General_Description_Sep87.pdf
Thanks for the link. I had a quick look. It does not go into the
details of the message formats, but it does say it interoperates with
Phase IV, so I just wonder if it was sufficient for me to accept Phase
V messages as if they were Phase IV and just ignore the version bytes.
I might just give that a quick go, which host is Phase V on HECnet now?
The way to interoperate with a version newer than what you implement is
to speak the protocol as you know it. That includes ignoring fields
you're
supposed to ignore, and messages for protocols (such as Ethertypes or
802.2
DSAPs) you don't implement. If you do that, the rest is up to the newer
version.
What I am doing is checking for routing specification 2.0.0 (in the hello
messages), but not checking for later versions. I have disabled the check
temporarily and it seems to work. But I seem to be getting
EthernetRouterHello messages from node 12.2 with the R/S LIST always empty,
so I never get an adjacency with the node. Not sure if this is because I am
not sending myself to 12.2, but an empty list suggests it can't talk to any
of the other routers in the network.
Regards
Rob
In the case of DECnet Phase V, that's essentially the OSI protocols --
such as
OSI ES-IS and IS-IS. Those run over 802.2 LLC type 1, DSAP address 0xFE.
So
those packets are completely invisible to a Phase IV implementation. What
the DECnet Phase V node does is also listen to the Phase IV protocol
(Ethertype 60-03); if it sees those, it records the sender as a Phase IV
neighbor and sends whatever it has to say to such neighbors using Phase IV
packets.
paul
Well, if it's only HECnet accessible, then what's the issue?
I suppose you could remove the password and just say "email me for password".
This service has been up for like 2+ years and gets about 10 visits a month FYI.
Sampsa
On 18 Dec 2012, at 22:42, Rob Jarratt <robert.jarratt at ntlworld.com> wrote:
I have put details of my Guest account and its password into my info.txt
file. Wondering if I should remove that now.... (query for "vax780" to see).
Regards
Rob
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of sampsa at mac.com
Sent: 17 December 2012 19:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Statistics
BTW, this is what we are talking about:
http://rhesus.sampsa.com/cgi-bin/hecnetinfo/hecnetinfo.com
It's not all THAT interesting to even random people on the wider
Internet...
sampsa
On 17 Dec 2012, at 21:41, sampsa at mac.com wrote:
OK, I'll make it opt-in - if there's an INFO.TXT in the public FAL dir,
I'll run
the NCP commands, otherwise I'll show nothing.
Is that OK with you?
sampsa
On 17 Dec 2012, at 21:33, Peter Coghlan <HECNET at beyondthepale.ie>
wrote:
With this in mind, I'm considering adding an opt-out system for the
HECnet info system on RHESUS, maybe a NOINFO.TXT file in the public
FAL directory and it won't run the NCP SHOW EXECs?
Or is everyone OK with what RHESUS is doing now?
That kind of depends on what exactly RHESUS is doing now.
I'm quite happy for anyone on HECnet to send commands to my NML
servers or to make information from my systems available to others on
HECnet. However I am nervous of making this information available to
anyone who wants it on the wider internet, particularly if it is a
spur of the moment kind of thing which is changing by the hour
without much thought being given to the implications.
I don't think opt-out is a good way to go. People who have not
carefully combed through the 80 plus mails to the mailing list today
will not realise that they are being required to opt out from
something that they did not know they were opting in to.
Regards,
Peter Coghlan.
<Paul_Koning at Dell.com> writes:
On Dec 18, 2012, at 3:55 PM, Brian Schenkenberger, VAXman- wrote:
"Brian Schenkenberger, VAXman-" <system at TMESIS.COM> writes:=20
=20
"Rob Jarratt" <robert.jarratt at ntlworld.com> writes:=20
=20
My user mode DECnet router has started telling me that it is getting
messages for routing specification version 2.2.0. Phase IV is 2.0.0. I
am assuming this is Phase V messages because there has been talk about
this recently. > >Does anyone have a link to the Phase V Routing
Specification?=20
=20
The specs for OSI were huge.=20
=20
Will this link help you any?=20
=20
http://bitsavers.trailing-edge.com/pdf/dec/decnet/EK-DNAPV-GD_DECnet_Pha=
se_V_General_Description_Sep87.pdf
Unfortunately, that's just a brief intro.
=20
Other that this, you're best bet would be the DECNET Documentation. It
should all be on-line at http://HP.COM/go/OpenVMS.=20
Those will tell you how to use VMS based DECnet products, but that doesn't =
say how the protocols work. Unfortunately, it appears that the DECnet Phas=
e V specs have disappeared. The intent definitely was for those ot be publ=
ished, exactly as the older ones were, but it doesn't appear that this was =
ever done.
=20
...and from my personal library:
=20
DECnet Phase V: An OSI Implementation (James Martin, Joe Leben)
Copyright 1992 Digital Press
EY-H8832E-DP
ISBN 1-55558-076-9
I remember reviewing that one when it first came out, unless I'm mixed up w=
ith another book. The conclusion was that the author (Joe Leben) knows lit=
tle or nothing about networking in general and DECnet in particular. James=
Martin was a tech books author from way way back; the one book that I know=
he actually wrote was so utterly atrocious that I never wanted to read any=
of his works ever again. (That was "The design of man-machine interfaces"=
.)
paul
I do hope your mailman wears kevlar!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Dec 18, 2012, at 5:07 PM, Rob Jarratt wrote:
http://bitsavers.trailing-edge.com/pdf/dec/decnet/EK-DNAPV-
GD_DECnet_Phase_V_General_Description_Sep87.pdf
Thanks for the link. I had a quick look. It does not go into the details of
the message formats, but it does say it interoperates with Phase IV, so I
just wonder if it was sufficient for me to accept Phase V messages as if
they were Phase IV and just ignore the version bytes. I might just give that
a quick go, which host is Phase V on HECnet now?
The way to interoperate with a version newer than what you implement is to speak the protocol as you know it. That includes ignoring fields you're supposed to ignore, and messages for protocols (such as Ethertypes or 802.2 DSAPs) you don't implement. If you do that, the rest is up to the newer version.
In the case of DECnet Phase V, that's essentially the OSI protocols -- such as OSI ES-IS and IS-IS. Those run over 802.2 LLC type 1, DSAP address 0xFE. So those packets are completely invisible to a Phase IV implementation. What the DECnet Phase V node does is also listen to the Phase IV protocol (Ethertype 60-03); if it sees those, it records the sender as a Phase IV neighbor and sends whatever it has to say to such neighbors using Phase IV packets.
paul
