[HECnet] Another TOPS-10 DECnet problem
Lee Gleason
lee.gleason at comcast.net
Sat Nov 13 19:01:23 PST 2021
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.
>
More information about the Hecnet-list
mailing list