The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Arthur Krewat <krewat@kilonet.net>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Old mainframe I/O speed (was: core)
Date: Sun, 24 Jun 2018 11:47:32 -0400	[thread overview]
Message-ID: <2a7b500f-3637-6756-ec0e-d0d5f6534147@kilonet.net> (raw)
In-Reply-To: <07BD6DF6-66B3-4EF3-B3B0-F2E2EBB3A209@serissa.com>

On 6/24/2018 10:41 AM, Lawrence Stewart wrote:
> Glue or microcode NOPs or DRM licence unlock codes work, but they tend to damage your reputation.

I was called in at the last minute to help a consulting firm who was 
having a hard time convincing their customer that they knew what they 
were doing. They spec'd out a SunFire 4800 cluster back in the mid 
2000's that would run 10 or so medium-to-large OLTP and DW Oracle 
instances. I came across the notion of "Capacity On Demand" (COD) CPU 
licensing. You would buy a complete system, full of CPUS and memory, but 
only license a subset of the CPUs (and associated memory).

The customer thought "great!" we can save a few $'s and if we want, we 
can turn on the extra capacity when/if we need it.

After reading all the documentation, I was on a conference call with 
some Sun engineers, the sales rep, and my customer's team (including 
some of the consultants who were a little too "wet behind the ears".

I point-blank asked the engineers: "I see in the documentation that if 
you use COD, memory interleaving is turned off, which only makes sense. 
Since we're only licensing 3 of every 4 CPU, Doesn't that mean we're 
only going to get half if not one quarter of the platform's advertised 
memory bandwidth?" (Single vs. two-way vs. four-way interleaving. Odd 
number of CPUs, no interleaving). Reluctantly, one of the engineers 
agreed that was indeed the case. The other "engineers" had no freakin' 
clue, but muttered something about "we have to remember that for next 
time".

I roughly calculated the difference in my head and said: "For an extra 
2% of the entire project cost (IBM Shark, Oracle licenses and Sun 
hardware combined), we're going to hobble these systems that much?". 
After the consulting firm I was sub-contracting for balked on telling 
the customer about this extra cost, I mentioned this in the presentation 
for the customer's CIO. She perked up her ears and immediately said 
'We'll spend the extra for that much performance. What were you guys 
thinking?'" (referring to the original consulting firm's own "Sun 
expert" who I'd had a lot of arguments with, actually quit the day they 
signed the contract with Sun).

I wonder, to this day, how many Sun customers were sold this COD concept 
only to suffer through 1/2 or 1/4 the memory bandwidth. This was for the 
entire SunFire 3800/4800/4810/6800/E12K/E15K line.

I went on to support that system for 5 more years as the customer 
wouldn't let the consulting firm even THINK of letting me leave ;)

art k.


  reply	other threads:[~2018-06-24 15:48 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-24  3:14 Norman Wilson
2018-06-24 13:03 ` Paul Winalski
2018-06-24 14:41   ` Lawrence Stewart
2018-06-24 15:47     ` Arthur Krewat [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-06-24 18:49 Norman Wilson
2018-06-24 18:49 Norman Wilson
     [not found] <mailman.1.1529690481.3725.tuhs@minnie.tuhs.org>
2018-06-23 10:32 ` Johnny Billquist
2018-06-23 11:39   ` Clem cole
2018-06-24  7:50   ` Mutiny
2018-06-27 13:59     ` Clem Cole
2018-06-22 13:11 Noel Chiappa
2018-06-22 17:49 ` Erik E. Fair
2018-06-15 15:25 [TUHS] core Noel Chiappa
2018-06-15 23:05 ` Dave Horsfall
2018-06-15 23:22   ` Lyndon Nerenberg
2018-06-16  6:36     ` Dave Horsfall
2018-06-16 19:07       ` Clem Cole
2018-06-18  9:25         ` Tim Bradshaw
2018-06-19 20:45           ` Peter Jeremy
2018-06-19 22:55             ` David Arnold
2018-06-20  5:04               ` Peter Jeremy
2018-06-20  5:41                 ` Warner Losh
2018-06-20  8:10                   ` [TUHS] Old mainframe I/O speed (was: core) Greg 'groggy' Lehey
2018-06-20 16:33                     ` Paul Winalski
2018-06-21  3:05                       ` Peter Jeremy
2018-06-21 14:00                         ` Paul Winalski
2018-06-21 14:49                           ` Arrigo Triulzi
2018-06-21 20:39                             ` Paul Winalski
2018-06-22  5:32                               ` Erik E. Fair
2018-06-22 13:32                                 ` Clem Cole
2018-06-23  6:08                             ` Dave Horsfall
2018-06-23 17:02                               ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2a7b500f-3637-6756-ec0e-d0d5f6534147@kilonet.net \
    --to=krewat@kilonet.net \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).