Re: architectural goals, Byte Addressability And Beyond

John Levine wrote:

According to George Neuner  <gneuner2@comcast.net>:

Consider the equivalent number of mainframes, with their inbuilt
diagnostics capabilities etc, to match that reliability.

>
Can't find it now and don't remember many details, but ...
>
A long time ago, there was a story going around about Microsoft vs IBM
regarding the day-to-day operation of their company web sites.  It
claimed that Microsoft was running a ~1000 machine server farm with a
crew of ~100, whereas IBM was running 3 mainframes with a crew of ~10.

 It depends on what you want to do.
 If you're doing something that is mostly read-only and easy to
parallelize, then it makes sense to use a farm of cheap PCs. But if
you are a bank or an airline, you need to be able to lock your
database so that you debit a bank account or sell a plane seat exactly
once.  There is a rule of thumb that the cost of locking something
grows roughly as the square of the number of things contending for
the lock.

Which is why you use my trick (probably old?) of setting up an array of N preliminary locks, as gate-keepers: N would be approx sqrt(number_of_competing_users), and only after winning that first stage are you allowed to compete for the "real" lock.
I've showed a way here in c.arch to make this adaptive, so it would only kick in after a given amount of contention.

 For example, airline reservation systems are the classic example of a
mainframe database. About 25 years ago, ITA Software had the bright
idea to do searches for seats and prices on racks of cheap PCs, which
worked great since it's read only, and if they suggest a seat or fare
that turns out to have just sold out, too bad, try again. But when
travel agents and airlines used it, they kept the ticketing info in a
regular database because it has to work.

The main problem here is how long you are allowed to "soft lock" a set of seats that you are contemplating buying.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"