Re: Alpha remembrance day


Bill Todd wrote:
Andrew wrote:
Bill Todd wrote:
Michael Kraemer wrote:
In article <44E6087E.FA9BDDEC@xxxxxxxxxxxx>, JF Mezei
<jfmezei.spamnot@xxxxxxxxxxxx> writes:

Well, considering it was the first "mainstream" 64 bit architecture, I
wouldn't say that Alpha was late. If at all, it was early to the market.
even if it were true (Andrew corrected you on that one), so what ?
It is just now, more than a decade later that people start really looking
at 64 bit stuff.
Ah, you must be a PC weenie: that could explain a lot. Of course, even
PC weenies might have recognized what benefits a 64-bit architecture
could confer on systems configured with 4 GB or less of RAM (let alone
the 64 GB that IA32 servers have supported since 1996 - hmmm, I wonder
why Intel bothered with that?) if he were familiar with NT/2K/XP's
32-bit approach to its file system cache and how much *virtual* space it
can waste.


It would be nice if the benefits of 64bit are as clear as you think
they are

Actually, *most* things are rather close to what I think they are, since
(unlike you) I don't form firm opinions on negligible (and often
flat-out incorrect) data.

it would also be nice if your Windows filesystem cache example
was really a 32bit issue and not just an MS issue.

Since the context above was explicitly PC technology, moron, the two
aren't all that different. But I guess asking you to try to understand
what you've read before responding to it would be expecting far too much
of you.

So why did you introduce it ????????????????????????????

This is a discussion about Tru64/OpenVMS and their competitors the fact
that example you introduced is only true for Windows doesn't increase
its relevance or did you think it did ?????

...

The reality is that 64bit VLM support in Tru64 was of very limited
benefit because the AlphaServer platform was not configurable with a
usefull amount of memory, CPU's and I/O.

Given a choice between believing you and believing the Tru64 customer
base's opinions on this point, I'll take the latter any day.


Its not an opinion, just read the 8400 configuration guide. It was
impossible to configure with redundant I/O and 14CPU's and 14GB of RAM.
There isn't much point having a system with decent I/O bandwidth,

The 8400 had a 9 slot centerplane into which you could put a 2 CPU
module or a 2 GB memory module or a System I/O module. With a single
I/O module (no reduncancy and limitted I/O) you have 8 slots left. 8
CPU's 8GB. 6 CPU's 10GB etc.

Compare that with the Sun 6000 series. 24 CPU's, 24 GB of RAM and
redundant I/O and the 6000 series was a baby compared withe the E10000.


The reality was that the top of the Alphaserver range for most of the
90's was only really equivalent to a sun E4500/4000 (12 CPU's, 12GB RAM
redundant I/O). In fact the E4500 running outperformed the last
iteration of the TurboLaser the GS140 on TPC-C scoring 50K TPM vs 42K
TPM for the GS. By this time in 1999 the Sun was running a 64bit OS and
the GS supported double density memory making 64bit more usefull.
Tru64 supported at least 8 GB of RAM in a March, 1996, TPC-C system (in
case you're as mathematically challenged as your are intellectually
challenged, that's more than 32 bits' worth). A 12 GB TPC-C system
followed in March, 1998, a 16 GB TPC-C system in January, 1999 (you
could even get that much on a lowly quad-socket ES40 later that year),
and in mid-Y2K 128 GB Alpha systems were available (all these figures
and dates being only what is revealed in the TPC-C submissions, though I
suspect those systems probably were configured with the maximum amount
of supported RAM and were submitted not too long after configuration
availability).

Ohh dear, let me help you a bit more. You don't need 64bit support to
have a single OS instance that adresses more than 4GB of RAM. 32bit
versions of Solaris, HP-UX, Dynix, AIX and Linux were all able to
support >4G. The Sun E10000 supported 64GB of RAM and one Solaris 2.x
instance could map all of that memory.

However indevidual processes couldn't address more than 4GB. Something
like Oracle consists of multiple processes but these processes need to
access the SGA which is where being able to support more than 4GB of
RAM for a single process becomes usefull.

In your 8 GB example it is unlikely that Digital actaully configured
the SGA to be more than 4GB, this is because the 8GB of RAM that they
had was also needed for the kernel and buffers, Oracle processes, TP
Monitor etc and it is unlikely that they would have had 4 GB left for
the SGA.

In reality Oracle TPC-C platforms hit a wall at about 40-50K TPM where
4GB SGA's became a necessity. The problem was that the 8400 only ever managed about 50% of this. Sequent through the use of OPS in a box demonstrated how with multiple Oracle instances each with its own SGA you could defeat this limit on a 32bit platform.

It is hard not to conclude from your posts that you don't reallly have
a good grasp of the subject, however you are welcome to continue
digging if that is what makes you happy. You have also conclusively
proved my point about your rudness increasing as your ability to
converse sensibly falls.


That 128 GB system, idiot, was a full 6 years ago (not that 64-bit
operation wasn't useful with as little as 8 or 16 GB of RAM, of course,
which takes us back a bit over 10 full years). Whereas the drivel to
which my earlier response was directed (as distinct from your own drivel
to which *this* response is directed) alleged that only *now* was 64-bit
support becoming interesting to customers.

You seem again to have compeletely missed the point. 64bit support is
in reality all about system balance. Had Digital released the
TurboLaser in a package which supported more than 14 CPU's, more than
14GB of RAM and a decent amount of I/O at the same time then it is
possible that early TurboLaser customers might have seen benefits from
using a 64bit OS and a 64bit DBMS.

But as you beautifully illustrate it was in fact another 8 years after
Alphas initial introduction in 1992 with all its 64bit fanfare that the
platform started to get to memory sizes and CPU number and I/O
bandwidths which made 64bit support necessary.

Thanks, I am very tempted to reflect one of your increasingly ludicrous
insults back at you but the collapse of your point is rewarding enough
in itself.

Regards
Andrew Harrison

.

Relevant Pages

  • Huge performance issue with cciss driver on HP DL385 servers (2.6.13 -> 2.6.17)
    ... We are facing a very serious I/O performance problem with a 2.6.16 Linux ... with iostat reporting an average service time greater ... # ACPI (Advanced Configuration and Power Interface) Support ...
    (Linux-Kernel)
  • Re: [OT] Commodore 64 BASIC v2, again (was: Interesting bug)
    ... >> The included BASIC did nothing whatsoever to support anything beyond ... CIA's I/O-lines controlled which of the 4 16K-portions of the RAM was ... Inside the 16K ROM there was anything: Datasette control, serial I/O ... Why didn't the BASIC have in-built graphics and sound ...
    (comp.lang.c)
  • Re: WinCE 5.0 RAM configuration
    ... The only memory sections that are ... relevant are RAM and RAMIMAGE. ... configuration), WinCE OS always crashed when running... ... How to configure my WinCE 5.0 OS to support 128MB SDRAM(64MB ...
    (microsoft.public.windowsce.platbuilder)
  • io_submit() taking a long time to return ?
    ... We are trying to rewrite our I/O subsystem by replacing multithreaded ... calling thread, and then a standalone background thread is responsible ... # Hardware Performance Monitoring support ... # Device Drivers ...
    (Linux-Kernel)
  • Re: Virtualized SBS / WS /TS
    ... I don't expect any improvement in the USB support question any time soon. ... I chose this group again because the SBS is the main SW in this ... WS 2008 as Hyper-V parent with a couple of guest OS'es running, ... quickly takes 2.5 to 3 GB RAM for just the parent. ...
    (microsoft.public.windows.server.sbs)