[HECnet] Another TOPS-10 DECnet problem

[Thomas DeBellis]

Believe me, a large number of us in the systems group were really sorry 
to retire our 11/60 (or 11/50? 55?) RSTS system.  We just thought it was 
so neat.  And we missed it for years.  The assembler was a little 
strange for us, but definitely easier for us to hack than PDP-8 (which 
had its own advocates) or IBM 370 (which had truly maniacal devotees)  
The architecture had some very interesting ideas.

I was also one of the few that would move between DEC and IBM, which is 
quite a paradigm shift if you've ever had to stare a 3270 in the face 
after EMACS.

My students always seem to ask me which OS I prefer or what language is 
the best, my response is always the same, "I like the OS that I get paid 
to use and the language I get paid to program in".  One has to earn a 
living...

I honestly don't know where those two got their stamina from...

------------------------------------------------------------------------
On 11/11/21 6:26 PM, Johnny Billquist wrote:
> And where I'm from we were regularly running 40 people on one 11/70 
> with RSTS/E, and on bad days we were above 60. But then it was 
> miserably slow...
>
> And yes, I have plenty of memories of the mails between MRC and BAH. :-)
>
>   Johnny
>
> On 2021-11-11 23:48, Thomas DeBellis wrote:
>> Oh, that old cat fight?  Meow!!  I'm walking away from it; I don't 
>> know how much email got spewed between MRC and BAH about it.  I don't 
>> think either side ever got the point that you are not comparing 
>> apples to apples.
>>
>> Having looked at both schedulers, I don't immediately see that either 
>> was more efficient than the other.  There clearly was cross 
>> fertilization in a number of areas.
>>
>> Recall that Tops-20 has processes and that a job may have a large 
>> number of processes.  The number of jobs then is not going to be a 
>> valid comparison.  For example, let's take a look at Galaxy on 
>> Tops-10, which occupies 10 job slots:
>>
>> Job    Who     Line#    What Size(P) State   Run Time
>>
>>  1    [OPR]     DET     NEBULA  26+40   HB 0
>>  3    [OPR]      0      QUEUE   9+38    ^C 1
>>       [OPR]     DET     QUASAR  40+40   SL 1
>>  9    [OPR]     DET     PULSAR  5+40    HB SW 0
>> 10    [OPR]     DET     ORION   109+40  SL 0
>> 11    [OPR]     DET     NML     15+18   HB 3
>> 13    [OPR]     DET     CDRIVE  30+40   HB 0
>> 14    [OPR]     DET     FAL-10  104+40  SL 1
>>
>>
>> They're all underneath a _single_ job on Tops-20 or built into the 
>> EXEÇ, but producing the same load because it is the same code.
>>
>> We did do some instrumenting and we found that the snazzy parsing 
>> (COMND%) was not contributing that much to load.  There was some 
>> overhead simulating UUO's, which are obviously natively executing on 
>> Tops-10.  Nearly all editing was done with WYSIWYG video editing, 
>> which surely must produce more load than TECO or SOS.  Some work was 
>> put into TEXTI% to mitigate the context switching.
>>
>> MRC's position was that Tops-20 was doing more, but I'm not sure how 
>> comfortable I am with that.  Having used and programmed both, I think 
>> it's more like 'doing differently'.  I would say that it was rare to 
>> find people who could easily move between the two and/or who weren't 
>> highly opinionated.
>>
>> It's a waste of time; you bought what did the job best for your 
>> environment.  It's kind of like apples and pineapples; they sound the 
>> same but they're just not.
>> ------------------------------------------------------------------------
>> On 11/11/21 5:20 PM, Robert Armstrong wrote:
>>>
>>> >You had a 20 that would handle 600 students in 1977/???/
>>>
>>>   I think he said something about six 20s…  I’m pretty sure there’s 
>>> no way one CPU would have handled 600 timesharing users.   We could 
>>> get to around 120 on a single KL10E with TOPS-10 before it got 
>>> unbearably slow.  With TOPS-20 on the same hardware we could only 
>>> get to 80 or so; TOPS20 was something of a pig.
>>>
>>> Bob
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211111/7799863c/attachment-0001.htm>