[Info-vax] DECnet Phase IV broken after VSI update

[Lawrence D’Oliveiro]

On Friday, November 5, 2021 at 7:46:15 PM UTC+13, osuv... at gmail.com wrote:
>
> On Thursday, November 4, 2021 at 8:54:37 PM UTC-4, Lawrence D’Oliveiro wrote: 
>
>> On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv... at gmail.com wrote: 
>>
>>> Most of PTD$ code runs in kernel mode with some at elevated IPL. 
>>
>> So does a device driver. Why do the PTD functions have to be a separate layer from
>> the device driver? Particularly a separate, caller-visible layer that breaks the normal
>> driver QIO abstraction? 
>>
>>> PTD$READ/WRITE queue request packets directly to FTDRIVER, 
>>> skipping some of the overhead of $QIO processing. 
>>
>> Remember, these are terminals we are talking about -- devices geared to the limits of
>> human I/O bandwidth. Any “overheads” associated with I/O processing would be
>> insignificant compared to the time it takes for a human to type input or read output.
>>
> That's a PC menatility, VAXes were timesharing systems with many concurrent users.

I was using time-sharing before I knew about PCs or even VAXes. When I first entered University, the main computer system was a PDP-11/70 running RSTS/E, which habitually coped with dozens of users. The most popular text editor was called “VTED”, which was a local variant on a screen-based editor written in TECO. I remember the system manager telling me that a single VTED instance consumed about 10% of the available CPU. You can see where this was going ...

The load of using full-screen interactive software, in itself, was never a problem on the VAX. What was a problem was things like MACSYMA, written in LISP, where the large memory usage combined with intensive garbage collection could still bring the system almost, but not quite, to its knees.

That, and the Ada compiler written in an interpreted language ...

 > ... your server process handling many PTYs was state driven by ASTs delivered by the
> terminal driver.

True, but irrelevant.