On Mon, Oct 19, 2009 at 05:37:39PM +0200, Johnny Billquist wrote:
But all the pieces are documented, and the documents are available on
the internet...
I wonder how hard/impossible it would be to implement this entirely in an
FPGA of some sort. That would be a LOT of work, but extremely cool.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Bob Armstrong wrote:
Why am I starting to think something like X.500 makes more sense at this
point?
There's also the format used once up on a time by the UUCP mapping project
- we have basically the same problem that they did. http://www.uucp.org/uumap/README
They're long gone now, but there are probably still lots of tools around for
processing data in this format.
Come to think of it, didn't they already have something to produce a
geographic map?
That format works, but it seems so cryptic.
What's wrong with plain text tags, followed by information
Such as (just as an example):
======
HOST: MIM
HARDWARE: E11 (PDP-11/74)
OS: RSX-11M-PLUS V4.6
LOCATION: UPPSALA, SWEDEN
MANAGER: Johnny Billquist
EMAIL: bqt at update.uu.se
EMAIL: MIM::BILLQUIST
======
Keep the format simple, and very relaxed. Let software figure out if they can do anything with it or not.
Uppercase, lowercase, free flowing text. Just keep the tags standard to start with. Maybe we can have some tags with a more formalized value, if needed, such as a POS: value with LAT/LONG if people want to add that?
I've seldom understood why people are striving for more and more complex solutions to a simple information problem. :-)
Johnny
Bob Armstrong wrote:
It also forks of separate processes
Yeah, but John Wilson is famous for writing E11 all in assembly language
and for DOS. It runs right on the bare metal, or silicon in this case. If
there's any multi-processing going on, he must have implemented his own.
Yup. Didn't say he was using the C library. However, MIM is running on a Linux box. And yes, he is rolling his own code to make the system calls to Linux from assembler.
Actually, I believe the different hardware instances are threads, and not forks.
Johnny
Pontus Pihlgren wrote:
Makes you wish you had a real PDP-11/74 around... :-)
Hmm, we have several 11/70 you know. Could we build one? Or would we have to rebuild the whole cache/memory tingies?
Hehe. Yes, we have three PDP-11/70 machines.
But sadly, no. It is not an easy task. The MMU needs modifications to implement the cache bypass bit in the PDR, which a normal PDP-11/70 don't have. Then we need a modification to the core instruction set of the machine, as the ASRB instruction in an 11/74 always bypass the cache unconditionally.
And then we need a different type of memory boxes, that accept cables from up to four CPUs into the memory box, do the arbitration between requests from several CPUs, and also support a read-modify-write cycle interlocked.
And then we need a new piece of hardware called the IIST (Interprocessor Interrupt and Sanity Timer), which is what the CPUs use to interrupt each other, boot each other, and also make sure that a CPU isn't hung.
So, while possible in theory, it would require quite a lot of engineering to actually produce an 11/74 from a few 11/70 machines.
But all the pieces are documented, and the documents are available on the internet...
Johnny
It also forks of separate processes
Yeah, but John Wilson is famous for writing E11 all in assembly language
and for DOS. It runs right on the bare metal, or silicon in this case. If
there's any multi-processing going on, he must have implemented his own.
Bob
Bob Armstrong wrote:
Makes you wish you had a real PDP-11/74 around... :-)
So can E11 actually use multiple processors on the host (aka Intel) side
so that the emulated 11/74 CPUs can really run in parallel?
Yes.
It also forks of separate processes for controllers and the like, so they can run on different processors, if possible. So it will, as much as possibly allowed by the host, act like the real machine.
Johnny
On Mon, Oct 19, 2009 at 04:19:27PM +0100, Sampsa Laine wrote:
Probably because we're building a distributed directory :)
Ah ha! I knew it was something like that. :)
In any case, yes, eventually a central X.500 directory would be
wonderful - however the INFO.TXT + demon-spawn-of-CSV-infofields is
probably a nice and quick hack to throw together in an afternoon.
Hell, we can populate the X.500 dir from the textfiles eventually.
That's a good point. I think you've just motivated me to finally get
around to getting the VAX 4000/500 cluster set back up. I should really
find the DSSI cables I need to use the HSD30 (I *think* it's one of those,
I really need to check, I forget now) in place to start using that.
Although I lack the correct SCSI disks to put on it. Eh, maybe I'll get
the FDDI boards setup and get a FDDI interface into the fileserver and
just use NFS.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Makes you wish you had a real PDP-11/74 around... :-)
Hmm, we have several 11/70 you know. Could we build one? Or would we
have to rebuild the whole cache/memory tingies?
/P
The ground floor flat is mine (i.e. the home of CHIMPY, CHIMP, RHESUS, FIDOGW, SAMDEV and GORVAX):
http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=W14+0ST&sll=5…
On 19 Oct 2009, at 16:23, Bob Armstrong wrote:
so we can look at satellite map and see real location of node :)
I'm not sure I want to tell :-)
Bob
Makes you wish you had a real PDP-11/74 around... :-)
So can E11 actually use multiple processors on the host (aka Intel) side
so that the emulated 11/74 CPUs can really run in parallel?
Bob
Brian Hechinger wrote:
On Mon, Oct 19, 2009 at 04:52:51PM +0200, Johnny Billquist wrote:
Ah, and it might be fun to point out that MIM:: is actually an emulated PDP-11/74.
Yes, that is the multi-CPU PDP-11 that DEC never sold.
I'm usually running MIM:: with only two CPUs online. There is still some debugging to be done of E11 to make it work a little more stable.
How's that working for you? I've been meaning to set that up myself.
The machine is usually running just fine. There are a few bugs somewhere in E11 that occasionally can bite you, but usually it keeps up and running several weeks between crashes, and I abuse that machine pretty heavily.
One thing that should be noted is that performance can be hurt pretty bad for some applications that map a shared region read/write. RSX turns off caching for those APRs, to avoid cache coherency problems, and E11 do something in reponse to that which can be very visible performance wise. However, not many programs are plying with that, so it's not a big problem. I usually see it when I use my own symbolic debugger for RSX, which are using various tricks to be efficient... :-)
Also, some privileged programs might need recompiling, since RSX with multiprocessor support change the layout of some kernel structures, where offsets move around. If a privileged program is playing around with those structures, it needs recompiling or possibly just re-taskbuilding.
I've learned to write my programs to actually handle the case dynamically, but most programmers never faced the situation, so chances are that programs that to magic things in the kernel might break.
But if you like to play with something a bit different, then I'd recommend you to try it. There is nothing like bringing up a second CPU in RSX. :-)
In fact, the dynamic configuration tool in RSX would make any OS developer today envious. RSX really looks good here. It's an undisclosed marvel. You can take CPUs on- and offline during operation without even blinking. The original idea was that you could then diagnose, repair, and bring the CPUs back online while the machine kept running.
Same goes for memory, buses, disks, controllers, and what else there is.
Makes you wish you had a real PDP-11/74 around... :-)
Johnny
Oleg Safiullin wrote:
Bob Armstrong wrote:
I have `geo location of OpenBSD developers' map at
http://pdp-11.org.ru/~form/openbsd/map/
and I can do something like that for HECnet if I have enough info :)
Well, there's a list of the cities in the list that I publish. Is there
an easy way to find a lat/lon for the center of each city?
Yes.
Just open http://maps.google.com/, find your location at satellite map, rightclick and select "Center here".
Then just press "Link" at right up corner of map and you'll get an URL with lat/long.
I think it would be better to use real coordinates, not just center of city, so we can look
at satellite map and see real location of node :)
Why am I starting to think something like X.500 makes more sense at this
point?
There's also the format used once up on a time by the UUCP mapping project
- we have basically the same problem that they did.
http://www.uucp.org/uumap/README
They're long gone now, but there are probably still lots of tools around for
processing data in this format.
Come to think of it, didn't they already have something to produce a
geographic map?
Bob
On 19 Oct 2009, at 16:16, Brian Hechinger wrote:
Why am I starting to think something like X.500 makes more sense at this
point?
Probably because we're building a distributed directory :)
In any case, yes, eventually a central X.500 directory would be wonderful - however the INFO.TXT + demon-spawn-of-CSV-infofields is probably a nice and quick hack to throw together in an afternoon. Hell, we can populate the X.500 dir from the textfiles eventually.
Sampsa
Bob Armstrong wrote:
I have `geo location of OpenBSD developers' map at
http://pdp-11.org.ru/~form/openbsd/map/
and I can do something like that for HECnet if I have enough info :)
Well, there's a list of the cities in the list that I publish. Is there
an easy way to find a lat/lon for the center of each city?
Yes.
Just open http://maps.google.com/, find your location at satellite map, rightclick and select "Center here".
Then just press "Link" at right up corner of map and you'll get an URL with lat/long.
On Mon, Oct 19, 2009 at 04:11:26PM +0100, Sampsa Laine wrote:
Contact address: I say we put in both, SMTP and DECNET.
I agree.
We should add a field for lat/long data in some standard format.
Good thinking.
I don't see why one host could not provide multiple tag lines, for
example the format below would allow for that (it has the node address
and name embedded in the data) - and since we're a nice cooperative
bunch we can trust others not to provide spurious information about
other machines.
Why am I starting to think something like X.500 makes more sense at this
point?
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
We should add a field for lat/long data in some standard format.
Lat/lon doesn't mean much to me, but I find it easy to build a mental
picture from reading the list of city names.
Of course, if Oleg can produce a map then I can always just look at that.
Bob
I have `geo location of OpenBSD developers' map at
http://pdp-11.org.ru/~form/openbsd/map/
and I can do something like that for HECnet if I have enough info :)
Well, there's a list of the cities in the list that I publish. Is there
an easy way to find a lat/lon for the center of each city?
Bob
I've bee meaning to make a comment about this, but just haven't come around to it.
I think that Sampsas suggestion for a INFO.TXT file is a pretty nice idea. But I also think that some standard form to it would be nice.
Any suggestions?
Johnny
Bob Armstrong wrote:
Obviously no one sent me any either. ;-)
http://www.avanthar.com:8080/nodes/
I was meaning to talk to you about that - the listing for CODA is
incorrect, too. I don't know where this list gets its information.
Clearly, keeping all these separate lists updated manually is getting to
be impossible.
If Sampsa's INFO.TXT file contained more information AND had a
standardized format that was not too hard to parse, then we could use that
as the basis for automatically generating all these lists. "If..." :-)
Bob
Contact address: I say we put in both, SMTP and DECNET.
As for the order of the fields, two options: Either label the fields or trust people to remember the order. I vote for trusting people :)
We should add a field for lat/long data in some standard format.
I don't see why one host could not provide multiple tag lines, for example the format below would allow for that (it has the node address and name embedded in the data) - and since we're a nice cooperative bunch we can trust others not to provide spurious information about other machines.
Sampsa
On 19 Oct 2009, at 16:04, Bob Armstrong wrote:
!HNINFO:1.401|CHIMPY|AlphaServer 800|OpenVMS 8.3|Comments go here|
That works for me, although everybody has to remember the correct order
for the fields :-)
I think there should also be an email address for the owner (DECnet or
SMTP, that's negotiable) just so somebody can contact him or her if there's
a question.
And I personally find it really interesting to know the geographic
location of the nodes. I always wanted to make a map of the world with the
HECnet links and sites marked, but I never got around to it. Is anybody
looking for something to do?
Oh, and it needs to be possible to put information for nodes other than
the current one (i.e. the one actually serving the INFO.TXT file) into the
file. That's to allow for machines that aren't up 24x7.
Bob
And I personally find it really interesting to know the geographic
location of the nodes. I always wanted to make a map of the world with the
HECnet links and sites marked, but I never got around to it. Is anybody
looking for something to do?
I have `geo location of OpenBSD developers' map at http://pdp-11.org.ru/~form/openbsd/map/
and I can do something like that for HECnet if I have enough info :)
!HNINFO:1.401|CHIMPY|AlphaServer 800|OpenVMS 8.3|Comments go here|
That works for me, although everybody has to remember the correct order
for the fields :-)
I think there should also be an email address for the owner (DECnet or
SMTP, that's negotiable) just so somebody can contact him or her if there's
a question.
And I personally find it really interesting to know the geographic
location of the nodes. I always wanted to make a map of the world with the
HECnet links and sites marked, but I never got around to it. Is anybody
looking for something to do?
Oh, and it needs to be possible to put information for nodes other than
the current one (i.e. the one actually serving the INFO.TXT file) into the
file. That's to allow for machines that aren't up 24x7.
Bob
Got an idea for that too :)
Make the file human readable, but have a standardised "tag line" with all the relevant data on it in a simple-to-parse format (in this case pipe | separated), e.g.
!HNINFO:1.401|CHIMPY|AlphaServer 800|OpenVMS 8.3|Comments go here|
Or something.
On 19 Oct 2009, at 15:54, Bob Armstrong wrote:
Obviously no one sent me any either. ;-)
http://www.avanthar.com:8080/nodes/
I was meaning to talk to you about that - the listing for CODA is
incorrect, too. I don't know where this list gets its information.
Clearly, keeping all these separate lists updated manually is getting to
be impossible.
If Sampsa's INFO.TXT file contained more information AND had a
standardized format that was not too hard to parse, then we could use that
as the basis for automatically generating all these lists. "If..." :-)
Bob
On Mon, Oct 19, 2009 at 04:52:51PM +0200, Johnny Billquist wrote:
Ah, and it might be fun to point out that MIM:: is actually an emulated
PDP-11/74.
Yes, that is the multi-CPU PDP-11 that DEC never sold.
I'm usually running MIM:: with only two CPUs online. There is still some
debugging to be done of E11 to make it work a little more stable.
How's that working for you? I've been meaning to set that up myself.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
