Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: big, fast, etc, was is Vax addressing sane today
Date: Fri, 13 Sep 2024 12:22:17 +0300
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <20240913122217.00002a21@yahoo.com>
References: <vbd6b9$g147$1@dont-email.me>
	<2024Sep11.113204@mips.complang.tuwien.ac.at>
	<vbsh3q$3n09p$1@dont-email.me>
	<vbtqib$2sce$2@dont-email.me>
	<vbvhs3$2std$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 13 Sep 2024 11:22:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46d778e366440aa5cd4ab92ae9134f42";
	logging-data="479852"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+hfSM+Q5tRJLhhylKDjBwXy/knR7/cLSQ="
Cancel-Lock: sha1:ooXVSWTXMoL59IL8LXyb3ODRbrU=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3272

On Thu, 12 Sep 2024 20:10:43 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

> According to Lawrence D'Oliveiro  <ldo@nz.invalid>:
> >On Wed, 11 Sep 2024 16:39:23 -0000 (UTC), Brett wrote:
> > =20
> >> Then there is the issue of cheap PC=E2=80=99s that fail, and a mainfra=
mes
> >> have a higher level of redundancy and failover. Failed business
> >> transactions can cost millions, more than the machine is worth, so
> >> saving pennies on hardware is stupid. =20
> >
> >You solve that by having multiple units of the cheap machines to
> >achieve the same level of redundancy, or even more. That ends up
> >being more cost- effective than the mainframe. =20
>=20
> That's fine for workloads that work that way.
>=20
> Airline reservation systems historically ran on mainframes because
> when they were invented that's all there was (original SABRE ran on
> two 7090s) and they are business critical so they need to be very
> reliable.
>=20
> About 30 years ago some guys at MIT realized that route and fare
> search, which are some of the most demanding things that CRS do, are
> easy to parallelize and don't have to be particularly reliable -- if
> your search system crashes and restarts and reruns the search and the
> result is a couple of seconds late, that's OK. So they started ITA
> software which used racks of PC servers running parallel applications
> written in Lisp (they were from MIT) and blew away the competition.
>=20
> However, that's just the search part. Actually booking the seats and
> selling tickets stays on a mainframe or an Oracle system because
> double booking or giving away free tickets would be really bad.
>=20
> There's also a rule of thumb about databases that says one system of
> performance 100 is much better than 100 systems of performance 1
> because those 100 systems will spend all their time contending for
> database locks.
>=20
>=20
>=20
>=20

How many transactions per minute does world's biggest company need at
peak hours? Is not this number small relatively to capabilities of
even 15 y.o. dual-Xeon server with few dozens of spinning rust disks?