14 Nov
2021
14 Nov
'21
4:01 a.m.
? 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.