[HECnet] Another TOPS-10 DECnet problem

Johnny Billquist bqt at softjar.se
Sun Nov 14 03:42:18 PST 2021


I've not done any analysis, but I suspect it's higher in M+. The reason 
being that one important change in M+ was the creation of secondary 
pool, which is much larger, and a bunch of stuff moved over from primary 
pool to secondary pool. You also have split I/D space for the kernel, so 
pool in general is much larger in M+.

But thanks for the info. Very interesting.

   Johnny

On 2021-11-14 04:01, Lee Gleason wrote:
> 
> 
>    This discussion of RSX  limits reminds me of a pre symposium seminar 
> I attended decades ago, about the RSX11M exec (M+ hadn't been released 
> yet).
> 
>    It was presented by Robert Bismuth, an RSX heavy of the era. He 
> mentioned in passing that the absolute limit of the number of running 
> tasks on an RSX11M system was around 300 or so (he had an exact number - 
> I don't recall it). All running a one instruction task that did a 
> branch-on-self. He said it was limited by available pool. I wonder if 
> anyone has done the research on M+ to see what its maximum number of 
> running tasks is.
> 
> 
> 
> On 11/13/2021 7:46 PM, Johnny Billquist wrote:
>> In RSX, there is no fixed table for logged in users.
>> There is the device table, and each existing terminal can have a user 
>> logged in into it.
>>
>> With "no limits" I just mean that there are no predefined limits, such 
>> as in RSTS/E where you define how many users/jobs you have.
>>
>> In RSX, a logged in user has his terminal, and that's it. So there is 
>> in that sense certainly a limit which is based on how many terminals 
>> you have.
>>
>> But each user can run any number of processse at the same time. There 
>> are no fixed limit on that. Each process take up a little space in 
>> pool, and if you run out of pool, you will not be happy.
>> But processes are dynamically created/deleted, and they all just sit 
>> in a linked list. So memory would be the one limit, I guess. But that 
>> is not a fixed number.
>>
>>   Johnny
>>
>> On 2021-11-13 17:57, Thomas DeBellis wrote:
>>> I think Tops-20 had some code for applications terminals, but I don't 
>>> remember where I saw that. It has hooks for canonical terminals, but 
>>> I think that may be DEC's adaptation of MIT's SUPDUP code.
>>>
>>> May I ask you to clarify what you mean by 'no hard limit'?  Do you 
>>> mean that the configuration parameter is effectively infinite (I.E., 
>>> a 31 bit positive number) or that the system will dynamically 
>>> allocate jobs and tasks as they are requested?
>>>
>>> Either way, that is remarkably impressive and contrasts with Tops-20 
>>> where you have to configure these and (I believe) you do have some 
>>> limits or some tables overflow.  I think the number of forks per job 
>>> is limited by the job status block (JSB), which was never put into 
>>> extended memory.  The number of forks is a hard limit and configured 
>>> when building the monitor.  For PANDA, the system can accommodate a 
>>> maximum of 320 forks.  I guess that is probably plenty for all but 
>>> the most excessive hobbyist usage. This is what my typical 
>>> development job looks like:
>>>
>>>     @i fork
>>>          Editor (1): Editor, Kept, HALT at 53206, 0:00:22.1
>>>          SETNODE-Sources (3): Kept, HALT at 53206, 0:06:23.0
>>>          Once-Source (4): Kept, HALT at 53206, 0:00:48.9
>>>          STAR-Sources (5): Kept, HALT at 53206, 0:07:47.7
>>>          EFTPSER-Sources (6): Kept, HALT at 53206, 0:00:01.9
>>>          Monitor-DECnet-Sources (7): Kept, HALT at 53206, 0:00:10.1
>>>          ALGOTS-Sources (12): Kept, HALT at 53206, 0:00:59.0
>>>          DN60-Sources (13): Kept, HALT at 53206, 0:00:00.8
>>>          BATCON-Sources (14): Kept, HALT at 53206, 0:00:15.3
>>>          FAL-DAPLIB-Sources (15): Kept, HALT at 53206, 0:00:01.2
>>>          PA1050-Sources (16): Kept, HALT at 53206, 0:03:40.5
>>>          NETPTH-DECnet-Ping-Sources (17): Kept, HALT at 53206, 0:00:09.7
>>>          DDT-Sources (21): Kept, HALT at 53206, 0:01:28.8
>>>          Exec-Sources (22): Kept, HALT at 53206, 0:00:05.5
>>>          LAT-Sources (23): Kept, HALT at 53206, 0:00:08.3
>>>       => Monitor-TTY-Service (10): Kept, HALT at 53206, 0:00:04.5
>>>          Kermit-Source (11): Kept, HALT at 53206, 0:03:25.4
>>>          Monitor-Scheduler (20): Kept, HALT at 53206, 0:00:09.3
>>>          Monitor-DTE-Driver (2): Kept, HALT at 53206, 0:00:07.1
>>>          Monitor-NRT-Sources (24): Kept, HALT at 53206, 0:00:03.8
>>>     @
>>>
>>> At certain times of the year, using 20 forks to handle various source 
>>> and editing might have gotten me a scolding, back in the day.  During 
>>> the summer however, we went from 3 student DEC20's to one (CU20A) and 
>>> the other two (CU20C and CUU20D) were handed over to staff for 
>>> development and to get them off the staff machine (CU20B). I did get 
>>> close to this one summer when I was putting Columbia's (extensive) 
>>> modifications into the Tops-20 V6 field test.
>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>> On 11/12/21 6:12 PM, Johnny Billquist wrote:
>>>>
>>>> There is no hard limit on the number of logged in users in RSX. And 
>>>> no hard limit on the number of running tasks either.
>>>>
>>>> Controlling lots of terminals from one process in RSX is easy. You 
>>>> do need to have the terminals open, but the limit on devices 
>>>> accessed from one task is 256. You don't need to have active I/Os to 
>>>> any terminal in order to read from them, so it's actually very 
>>>> little resources required. A little bit of memory, but that's it.
>>>>
>>>> I believe this was used out by customers in lots of places. I never 
>>>> saw any really big ones, but I heard about 911 dispatch centers in 
>>>> the US. But small scale solutions on the same principles were/are 
>>>> being run that I know of...
>>>>
>>>>   Johnny
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> On 2021-11-12 21:01, Paul Koning wrote:
>>>>>
>>>>> RSTS has an API for that, allowing one program to control lots of 
>>>>> terminals without having to open lots of individual files for each 
>>>>> terminal.  It makes it possible to support 127 terminals, even 
>>>>> though the number of logged-in users is limited to 63.
>>>>>> ------------------------------------------------------------------------ 
>>>>>>
>>>>>> On Nov 11, 2021, at 6:49 PM, Johnny Billquist <bqt at softjar.se> wrote:
>>>>>>
>>>>>> RSX-11M-PLUS can have up to 256 terminals. However, I sortof doubt 
>>>>>> much useful stuff would happen if you had that many users running 
>>>>>> interactively.
>>>>>>
>>>>>> I think it was more used for systems where you had some clever 
>>>>>> programs running that controlled lots of terminals.
>>
> 

-- 
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


More information about the Hecnet-list mailing list