From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 03 May 2025 13:51:35 -0400, Dan Espen wrote:

Try connecting thousands of users to a single linux box. You'll soon
see the utility of block mode terminals.

A client of mine just got a machine with 40-something CPU cores (each >multithreaded), and something close to a terabyte of RAM. And a couple
dozen hot-swap slots for multi-terabyte hard drives.

Of course we’re going to run Linux. I don’t think we’ll have trouble >handling thousands of users on that ...

Depends what you're doing. The more cores you put on one memory buss, the
more memory contention gets to be an issue. The more data has to be shared
by processes, the more that bandwidth gets to be an issue too. So for
simple web service stuff where each web server process is completely independent and there isn't a central database everyone has to refer to,
that kind of architecture can be great. But make all those web servers
refer to a central Oracle database and watch everything slow to a crawl. --scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 3 May 2025 16:07:59 -0400 (EDT), Scott Dorsey wrote:

That's the cool thing... the way you manage it is by having thousands of
users, each on their own linux box, sending short transactions to the
big IBM machine.

How wonderful. No doubt your user base are accustomed to thinking in terms >of “transactions” rather than point-and-click, are they ...

The users never see that, any more than they see the underlying sql
operations when they are using a directly-attached database. This is
the whole beauty of computers, that you can abstract layers.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 3 May 2025 19:46:55 -0400 (EDT), Scott Dorsey wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sat, 3 May 2025 16:07:59 -0400 (EDT), Scott Dorsey wrote:

That's the cool thing... the way you manage it is by having thousands
of users, each on their own linux box, sending short transactions to
the big IBM machine.

How wonderful. No doubt your user base are accustomed to thinking in
terms of “transactions” rather than point-and-click, are they ...

The users never see that ...

But they do still suffer the latencies from a platform optimized for batch rather than interactive operation, don’t they.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sat, 3 May 2025 19:45:36 -0400 (EDT), Scott Dorsey wrote:

But make all those web servers refer to a central Oracle database and
watch everything slow to a crawl.

I guess that’s a reason why the main tech companies, like Facebook, Google et al, don’t use Oracle. They build their platforms on open-source foundations instead.

--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sat, 03 May 2025 13:55:18 -0400, Dan Espen wrote:

Mainframes support NFS but in my case I mostly ftp'd files, JCL, and
results back and forth.

In other words, you used the mainframe in batch mode, and kept all your interactivity local to a more sensibly-designed machine.

Yep. One user on my "sensibly designed" machine, hundreds of users on
the other end.
--
Dan Espen
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

But they do still suffer the latencies from a platform optimized for batch >rather than interactive operation, don’t they.

No, this isn't 1965 any longer. These are realtime transaction processing systems. You _can_ run batch stuff on VM/CMS too, and the batch jobs
coexist well with the transaction load taking priority of both CPU and
the I/O mechanisms. The ability to manage I/O load dynamically is a big
deal.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 4 May 2025 10:22:51 -0400 (EDT), Scott Dorsey wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

But they do still suffer the latencies from a platform optimized for
batch rather than interactive operation, don’t they.

No, this isn't 1965 any longer. These are realtime transaction
processing systems.

No, they are *batch* transaction processing systems. They have file
formats that still emulate the layout of punch cards.

You _can_ run batch stuff on VM/CMS too ...

Remember what the “VM” part was for: it was a kludge because CMS wasn’t a
proper multiuser OS. So to work around that, each user was given their own entire virtual machine.

The ability to manage I/O load dynamically is a big deal.

Not on a modern OS like Linux, that just takes it all in its stride.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sun, 4 May 2025 10:22:51 -0400 (EDT), Scott Dorsey wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

But they do still suffer the latencies from a platform optimized for >>>batch rather than interactive operation, don’t they.

No, this isn't 1965 any longer. These are realtime transaction
processing systems.

No, they are *batch* transaction processing systems. They have file
formats that still emulate the layout of punch cards.

Yes, there are still 80 column card images in common use, but they are
not batch systems under the hood at all. (Well, MVS still is, but CMS and
CICS sure aren't).

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.

You _can_ run batch stuff on VM/CMS too ...

Remember what the VM part was for: it was a kludge because CMS wasn't a >proper multiuser OS. So to work around that, each user was given their own >entire virtual machine.

Yes, that was the idea, but in the end it turned out to be a win instead
of a loss. I wouldn't call it a kludge so much as a deeper sort of timesharing.

The ability to manage I/O load dynamically is a big deal.

Not on a modern OS like Linux, that just takes it all in its stride.

Sadly, I wish that were the case, although I will say that the one good
thing about systemd is the "quota system" built into it that does allow
some crude per-process I/O restrictions in ways that ionice never did.
It's certainly getting better.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction processing systems.

Their idea of “real time” was responding in a few seconds, before the user got frustrated enough to hit SEND again.

Meanwhile, Linux recently mainlined the PREEMPT_RT patches, where the definition of “real time” is being able to provide sub-millisecond response to playing or recording sound samples for pro audio.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

In article <vv9fdc$3mhk4$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.

Their idea of real time was responding in a few seconds, before the user
got frustrated enough to hit SEND again.

Today we would call those "interactive systems," yes. Not the same as
true realtime systems with deadlines.

Meanwhile, Linux recently mainlined the PREEMPT_RT patches, where the >definition of real time is being able to provide sub-millisecond
response to playing or recording sound samples for pro audio.

That's still not hard realtime at all, but it gives you reduced latency, realtime scheduling, and the ability to preempt kernel threads. That
latter one has become a big deal since som much crap has been rolled into
the kernel.

But what they mean by "RT" isn't what hard realtime people mean by "RT"
which has nothing to do with what the transaction processing guys meant
as "RT." Do not get hung up on words, especially when people use the same words for rather different concepts.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.

Their idea of “real time” was responding in a few seconds, before the user
got frustrated enough to hit SEND again.

My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.
--
Dan Espen
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 5 May 2025 08:30:03 -0400 (EDT), Scott Dorsey wrote:

In article <vv9fdc$3mhk4$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

Meanwhile, Linux recently mainlined the PREEMPT_RT patches, where the
definition of real time is being able to provide sub-millisecond
response to playing or recording sound samples for pro audio.

That's still not hard realtime at all ...

Tell that to the audio engineers in particular. They are kind of sensitive
to the slightest bit of jitter in the timing of things.

But what they mean by "RT" isn't what hard realtime people mean by "RT"
which has nothing to do with what the transaction processing guys meant
as "RT." Do not get hung up on words, especially when people use the
same words for rather different concepts.

Particularly when the transaction processing folks are at the bottom of
that particular league table ...
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Mon, 05 May 2025 11:31:55 -0400, Dan Espen wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.

Their idea of “real time” was responding in a few seconds, before the
user got frustrated enough to hit SEND again.

My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.

“Instantaneous” to every keystroke? In something like a full-screen editor?
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Dan Espen <dan1espen@gmail.com> wrote:

My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.

And that was the bottom of the barrel too. It got so much better with
the newer channel controllers. And THEN we got SNA!
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 05 May 2025 11:31:55 -0400, Dan Espen wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems"
which was written in the early days of SAABRE and other transaction
processing systems.

Their idea of “real time” was responding in a few seconds, before the >>> user got frustrated enough to hit SEND again.

My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.

“Instantaneous” to every keystroke? In something like a full-screen editor?

Huh?

What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke. And in this case
it was also instantaneous to the enter key. First online
app I developed. Online order entry.
--
Dan Espen
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Dan Espen <dan1espen@gmail.com> wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 05 May 2025 11:31:55 -0400, Dan Espen wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Sun, 4 May 2025 20:53:42 -0400 (EDT), Scott Dorsey wrote:

You should check out Martin's "Design of Real-Time Computer Systems" >>>>> which was written in the early days of SAABRE and other transaction
processing systems.

Their idea of “real time” was responding in a few seconds, before the >>>> user got frustrated enough to hit SEND again.

My experience: 360/30, 64K, 1968, locally attached 2260s, BTAM
application, instantaneous response.

“Instantaneous” to every keystroke? In something like a full-screen
editor?

Huh?

What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke. And in this case
it was also instantaneous to the enter key. First online
app I developed. Online order entry.

Lawrence is more often trolling than not.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 06 May 2025 08:19:05 -0400, Dan Espen wrote:

What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke.

But that’s only locally. Nothing goes to the mainframe unless you press
the SEND key.

That’s what “block mode” means.

Now imagine trying to run something more properly interactive, like Emacs
(or vi/vim, if you prefer), through such an interface.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

Now imagine trying to run something more properly interactive, like Emacs >(or vi/vim, if you prefer), through such an interface.

You mean like word processing on PROFS where the editor is basically running
on the channel controller? That is great and extremely zippy over a slow network. Far better performance with any network latency than trying to
send everything over the connection.

CDC did something like this in a less elegant way with the Full Screen
Editor FSE. The PPU did most of the work but the PPU was tightly coupled
to the CPU so even though it offloaded the CPU completely it didn't help
any for slow connections.

But really, this has nothing to do with transaction processing systems,
which is the topic of this thread. Transaction systems need to have enough smarts at the terminal end to generate a transaction and the server needs
to have enough to execute it.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 6 May 2025 18:59:32 -0400 (EDT), Scott Dorsey wrote:

You mean like word processing on PROFS where the editor is basically
running on the channel controller? That is great and extremely zippy
over a slow network. Far better performance with any network latency
than trying to send everything over the connection.

I’m sure it is, but given the channel controller is not a general-purpose CPU, you are going to pay the price in app functionality.
--- Synchronet 3.20c-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Tue, 06 May 2025 08:19:05 -0400, Dan Espen wrote:

What about block mode terminals don't you understand?
Of course it's instantaneous to every keystroke.

But that’s only locally. Nothing goes to the mainframe unless you press the SEND key.

So 90%+ of the time, it's instantaneous.

Where I worked, it was also instant on Enter, Function keys, etc. All
the keys that required mainframe attention.
--
Dan Espen
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 08 May 2025 20:24:29 -0400, Dan Espen wrote:

Where I worked, it was also instant on Enter, Function keys, etc. All
the keys that required mainframe attention.

The idea that every single keystroke/mouse click might require CPU
attention (as is typical with interactive applications) is not something
that mainframes are optimized for.
--- Synchronet 3.21a-Linux NewsLink 1.2