24 May
2018
24 May
'18
12:20 p.m.
From: Lars Brinkhoff
I'm surprised it appeared that late. Were there
any other versions or
similar Unix programs before that?
The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT based on
'ps' (and no doubt inspired by ITS' PEEK), which had similar
functionality.
Seems like it never escaped, though. Man page and source here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man1/dpy.1
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/dpy.c
The top of my hard-copy man page says 'November 1977', but I suspect it dates
back further than that.
Noel
24 May
24 May
2:09 p.m.
New subject: History of top
On Thu, May 24, 2018 at 5:20 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
around at
different UNIX sites. CMU's locally hacked ps was similar to
dpy and BSD's *stat programs (systatm vmstat, ...). The problem all of
these had was getting the data out of the OS. The original scheme used by
ps being it ran setuid/gid, and then was able to opening /dev/kmem and
reading interesting data structures the kernel. A big problem was that ps
and the OS had to be compiled with exactly the same headers and you really
had to know the layout and the obvious security concerns of using
setuid/gid to control things.
FreeBSD's sysctl and V8's /proc would finally clean that up by making a
formal interface to the OS and controlling what was available in a more
granular manner both from a data structure as well as security path.
Although before /proc came to being (/proc was a UNIX innovation), the
sysctl(2) like interface was reinvented a few times, as it really was not
new with UNIX. It's very much like a similar scheme that came from TOPS,
RSX and VMS (which the Masscomp system parroted being ex-DECies almost
exactly the same as VMS). I believe that Sun had something also, but I've
forgotten its name, Larry might remember. But so did DG-OS and many of
the other commercial UNIXs snd I would not be surprised if many University
hacks did it also.
My favorite of all of these was the one that George Gobble at Purdue built
when he did the Dual VAX. He also spliced an PDP-11 on the UBA on the
their Dual Vax System and wrote a program that like top(1) refreshed itself
(at least as fast as once a sec IIRC). It would read the VAX memory and
then display what the OS was doing in real time. He did a neat talk in a
mid-1980's USENIX with a movie from it. They found an interesting bug in
the BSD scheduler which had been there since 6th edition, which had never
really been noticed until people could visually watch what as happening and
actually get enough information about how processes were being handled.
[This was also around the time one of the first '0-day' issues with UNIX
was found by ghg and team which is now a cute story but at the time was
quite worrisome].
The best I remember, the popularity of top(1) started because it was first
released as USENET came of age; and thus it got wide distribution. By that
point, *BSD was the 'standard' in most places, and this the *stat
commands were pretty well known. The top(1) program consolidated these into
a single one, plus it used the curses library so it could be left running
on a glass TTY. As Vaxen were being used as large timesharing systems for
Universities to teach with, such a program was handy for the sys admins to
keep an eye on what was happening.
Clem
ᐧ
From: Lars
Brinkhoff
I'm surprised it appeared that late. Were
there any other versions or
similar Unix programs before that?
The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT
based on
'ps' (and no doubt inspired by ITS' PEEK), which had similar
functionality.
Seems like it never escaped, though. Man page and source here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man1/dpy.1
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/dpy.c
The top of my hard-copy man page says 'November 1977', but I suspect it
dates
back further than that.
Noel
There were a bunch of these - originally mods off of ps(1) that kicked 
2:43 p.m.
New subject: History of top
I remember George’s Unibus monitoring hack. It was noted at the time that he didn’t
have any bus terminators. The SBI had CPUs on both ends and the Unibus had the
monitoring 11/23 at the far end.
We built one of the Dual vaxes at BRL (BRL-VGR). It was pretty straight forward, just
needed to obtain (well we had it fabbed) a new cardcage and redo a special set of SBI
cables to be an mirror image.
It was amazing how cheap this was compared to the 782 abomination (not to even mention the
VaxCluster and it’s horrendous HSC50 that I ended up administering later at RU).
2:50 p.m.
New subject: Control-T (was top)
Another related creeping featurism was the integration of the control-T feature that was
prevalent in many of the DEC 10/20 OSs.
When Mike Muuss was doing some scheduling tweaks he decided that being able to list out
all the processes on the terminal with a few parameters (he had the weighted load averages
at the top of the list).
It became real handy for me when I set out to reverse engineer how the Csh used job
control as well.
For those who aren’t old time kernel hacks, there are two structures associated with every
process. The “proc” structure has essential things like uid/gid and memory sizes and
priority. The proc structure always was resident making it ripe pickings for control-T.
More detailed information including the stack of the process (and hence the command line
arguments), were in the user structure. While the user structure of the currently
running process was always resident (and on the PDP-11 at 140000, which meant you could
use the display register to display the UID to figure out who the CPU hog was). This
made it harder for the “ps”-like things to get. I finally relented and put a copy of
the first few bytes of the arg list in the proc structure.
3:01 p.m.
New subject: Control-T (was top)
below...
On Thu, May 24, 2018 at 7:50 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
Another related creeping featurism was the integration of the control-T
feature that was prevalent in many of the DEC 10/20 OSs.
Yeah I still sometimes missed that hack. Zimmerman (of EMACS fame) put it
into the Masscomp tty handler. He may have had it in an MIT system. That
was the best UNIX version I ever used.
That said, with a window manager on my modern Mac, I just leave 'Activity
Monitor' running, so I don't need it like I did when we ran on glass ttys.
Actually, my favorite Control-T story is not from UNIX, but from TwinEx.
When you typed Control-T on that system, it would reply with '*running,
load average, ...mumble stats, more mumble and more stats*.' In the late
1970s, Stanford had a DEC System-20 called 'LOTS' which they bought for the
undergrads for teaching. Somebody (who will be left nameless) modified
the OS so the 'running' part changed depending on value of the load
average. * i.e.* running, jogging, walking, crawling. But the
administration made them remove the hack when it came back as 'dying' most
of the time.
Clem
ᐧ
3:48 p.m.
New subject: Control-T (was top)
Clem Cole wrote:
Stanford had a DEC System-20 called 'LOTS'
which they bought for the
undergrads for teaching. Somebody (who will be left nameless) modified
the OS so the 'running' part changed depending on value of the load
average. i.e. running, jogging, walking, crawling.
Another PDP-10 operating system (from MIT) had this:
Warp (fastest), zoom, fly, run, walk, tenex, multix (slowest).
3:08 p.m.
New subject: Control-T (was top)
On 5/24/2018 10:50 AM, Ronald Natalie wrote:
Another related creeping featurism was the integration
of the control-T feature that was prevalent in many of the DEC 10/20 OSs.
Control-T
in TOPS-10 was done straight out of the monitor. If you were
on a slow 300 baud or 110 baud terminal on say a DZ11*, and kept hitting
Control-T really fast, you'd slow down everything else on the machine as
there was no buffering of serial TTY I/O and the monitor would sit and
wait for each character to be transmitted.
ak
* a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
any straight serial port on a KA/KI/KL10 would do the same. If you were,
say, on a DCA mux, that had a 14.4K serial link straight into the
UNIBUS, there was much less of an effect.
28 May
28 May
10:32 p.m.
New subject: Control-T (was top)
On 5/24/18, Arthur Krewat <krewat(a)kilonet.net> wrote:
* a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
any straight serial port on a KA/KI/KL10 would do the same. If you were,
say, on a DCA mux, that had a 14.4K serial link straight into the
UNIBUS, there was much less of an effect.
DZ11s were available on PDP-11s and VAXen as well as the KS10.
Because the controller had no buffer it was dirt cheap. OK, perhaps,
for a realtime or lab application, but if you were doing timesharing
it could bring the CPU to its knees in short order. Some idiot
decided to use the same idea (no buffer in the controller) to reduce
the cost of the TU58 (aka DECtape II), Unlike the original DECtape,
which was extremely reliable, the TU58 was prone to frequent data
overrun and underrun errors even if you set things up such that it got
top scheduler priority.
-Paul W.
11:11 p.m.
New subject: Control-T (was top)
And the other issue was besides not enough buffering DZ11s and the TU58 assumes software
(^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control
the I/O rate. So this of course made 8bit data diificult too. And as Paul points out,
with HW flow the priority could have been lower. But the HW folks assumed a so called 3
wire interface because they thought they were saving money.
A few years later when people tried to put high speed modems like the Trailblazers on
them, let’s say the Unix folks quickly abandoned any hope. Ken O’Humundro at Able
Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more
ports, full DMA and of course full hardware flow control.
Btw it was not just DEC. The original hw version of Masscomp MC500 had the same issue in
cpu board brcause Jeff Mitchell (who had been one the 11/34 designer) did not know any
better. I fixed the MPU board when it was relaided out and our first 8 port serial
controller had rewritten microcode from the original OEM to allow trailblazers to work
right (fortunately then HW was there on the serial board but it was just being ignored in
the original firmware).
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On May 28, 2018, at 6:32 PM, Paul Winalski
<paul.winalski(a)gmail.com> wrote:
On 5/24/18, Arthur Krewat
<krewat(a)kilonet.net> wrote:
* a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
any straight serial port on a KA/KI/KL10 would do the same. If you were,
say, on a DCA mux, that had a 14.4K serial link straight into the
UNIBUS, there was much less of an effect.
DZ11s were available on PDP-11s and VAXen as well as the KS10.
Because the controller had no buffer it was dirt cheap. OK, perhaps,
for a realtime or lab application, but if you were doing timesharing
it could bring the CPU to its knees in short order. Some idiot
decided to use the same idea (no buffer in the controller) to reduce
the cost of the TU58 (aka DECtape II), Unlike the original DECtape,
which was extremely reliable, the TU58 was prone to frequent data
overrun and underrun errors even if you set things up such that it got
top scheduler priority.
-Paul W.
11:32 p.m.
New subject: Control-T (was top)
On 5/28/2018 7:11 PM, Clem cole wrote:
A few years later when people tried to put high speed
modems like the Trailblazers on them
Hence why, in the early 90's, I used an
80486DX2-66 PC with 16550 UARTs
for modems instead of the Sun IPC to do USENET ;)
29 May
29 May
1:12 a.m.
New subject: Control-T (was top)
On Mon, 28 May 2018, Paul Winalski wrote:
DZ11s were available on PDP-11s and VAXen as well as
the KS10. Because
the controller had no buffer it was dirt cheap. OK, perhaps, for a
realtime or lab application, but if you were doing timesharing it could
bring the CPU to its knees in short order. Some idiot decided to use
the same idea (no buffer in the controller) to reduce the cost of the
TU58 (aka DECtape II), Unlike the original DECtape, which was extremely
reliable, the TU58 was prone to frequent data overrun and underrun
errors even if you set things up such that it got top scheduler
priority.
Odd; I have a clear recollection that UNSW's driver (or was it Basser?)
did not use interrupts (too slow, as you point out) but used the clock
interrupt to empty the silos every so often. I'd check the source in the
Unix Archive, but I don't remember which disk image it's in; what I do
remember was that it went like a bat out of hell, and Elec Eng had
something like eight of them on their 11/70.
Can anyone confirm or deny this?
We also had a DZ-11 on our 11/60 (and the 11/40 before that), and it
worked OK, keeping the DJ-11 company.
-- Dave, possibly suffering from mental bit-rot
28 May
28 May
10:31 a.m.
New subject: History of top
The MIT ~PWB1 system had a thing called
'dpy', I think written at MIT
based on 'ps' (and no doubt inspired by ITS' PEEK)
Indeed my hidden agenda was to find a link between top and PEEK.
But apparently the inspiration came from VMS:
http://web.archive.org/web/20170527120123/http://www.unixtop.org:80/about.s…
2166
days inactive
2171
days old
11 comments
8 participants
participants (8)
-
Arthur Krewat -
Clem Cole -
Clem cole
-
Dave Horsfall -
jnc＠mercury.lcs.mit.edu -
Lars Brinkhoff -
Paul Winalski -
Ronald Natalie