Re: The Common System Interface: Intel's Future Interconnect

Main, Kerry wrote:
-----Original Message-----
From: JF Mezei [mailto:jfmezei.spamnot@xxxxxxxxxxxxx]
Sent: August 29, 2007 9:35 PM
To: Info-VAX@xxxxxxxxxxxx
Subject: Re: The Common System Interface: Intel's Future Interconnect

Main, Kerry wrote:

All,

The following article may be of interest: (August 28, 2007)
http://www.realworldtech.com/page.cfm?ArticleID=RWT082807020032&p=1


Mr Main,

What will differentiate a 64 bit 8086 plugged into a CSI interface from
a 64 bit IA64 also plugged into a CSI interface ?

If both have access to the same type of memory, cache etc, then won't
the industry standard architecture that has competition from AMD end up
being far superior than some proprietary IA64 thing that requires its
own proprietary funky compilers due to ist EPIC nature ?


JF -

Remember the relative importance to Cust's in terms of both what they have and what they
need In the future:

1. App = 50-60%
2. OS = 25-35%
3. Server HW - 10-15%

While #3 gets all sorts of attention in techie newsgroups, in the pig picture,
#1 and #2 are much more important to Cust's. With a massive glut in available compute
cycles in most Cust's environment today, Cust's are not impressed with fantastic new
computer speeds that will increase their glut of available compute cycles even more.

Btw, this applies to all platforms.

Also, keep in mind that there is now a massive trend to consolidating both servers and
DC's. This is a huge change from the distributed computing designs of the last 10 years.

Imho, the question that will become increasingly important in the future - "Can a company
afford OS platforms for their future centralized, very HA strategy that have "one app,
one OS" App/ISV support cultures and where the OS vendors release 5-20 security patches
per month?"

My advice to Cust's - think like Wayne Gretzky (ok, he's a hockey player) and the way
He became a great player .. "Do not skate to where the puck is, but where it will be in
the next play sequence .."

:-)

I've long noticed this cycle. For example, when I first
started, one of our biggest customers was a large NY bank
that had been burned by its centralized data processing
operation. All their eggs in one basket, and someone had
dropped the basket. (I don't know the details.)

At any rate, when I started out, they were in the midst of
distributing their computer resources out to the end users,
i.e. the branches and departments of the bank. We (and many
other vendors) were using RSTS/E systems for this. (Other
vendors were basing their applications on other platforms,
DG, Prime, Perkin-Elmer, ...) Many of the changes DEC made
to RSTS/E V6B were specifically for this customer. Quite soon,
they networked all these little systems together, since it
was much more efficient than producing dozens of tapes to
hand off each day and shuttle around the city.

Eventually, this "let 100 flowers bloom" strategy resulted
in too much (perceived) inefficiency, too much duplication
of effort, too many operational and security issues (e.g.
making sure all the systems correctly enforced the bank's
security policies, proper backups were being done, etc.),
and improve network efficiency by putting everything in one
room on one Ethernet rather than having dozens of 56Kb
leased lines, so they (and other of our customers) instituted
a policy of consolidation. Get everything into a proper data
center, make sure the systems were run by professionals, make sure
operations procedures were documented and followed, and make
sure proper testing and change procedures were followed.
A lot of this consolidation was done onto VAX/VMS systems in
the early '80s.

This of course re-instituted the original problems that
caused the distribution in the first place, such as a
large, high-inertia IT structure that took a long time
to make application changes and was run by people who
understood the IT stuff much better than they understood
the business, so often the changes didn't really address
the problems they were intended to solve, or were "one
step forward, two steps back", or took much longer to
implement or cost the "customer" (i.e. the company's
department that was the user of the application), far
more than seemed reasonable. ("You mean you want to
charge my department $$$$$ just to produce a summary
page at the end of the report and email it to me twice
a day?!?!?! And it's going to take 6 months to implement?
Get real!")

So when it became practical to move a big chunk of the
data center into a small box in the corner, under the
direct control of the user (i.e. a PC) and bypass the
IT bureaucracy, that's exactly what happened.

Now all the PC's are getting reconsolidated, which
will eventually result in another redistribution,
this time most likely to a (small) rack of blade
servers in the corner with a (small) SAN array for
storage. "Small" in this context means a few
tens of multi-GHz processors and a few Terabytes
of storage, i.e. orders of magnitude more powerful
than the PCs which preceded them last time around,
which were in turn orders of magnitude more powerful
than the PDP-11/70's in the first cycle.

The cycle keeps repeating. I expect it will go on
for ever :-)


Regards


Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-592-4660
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)

OpenVMS - the secure, multi-site OS that just works.







--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
.

Relevant Pages

  • Re: Legality of installing XP bundled with one computer on another
    ... > Kerry Brown wrote: ... You assume you know how I run my business. ... I tell my customers how the ... Less than 1% pick the retail version. ...
    (microsoft.public.windowsxp.general)
  • RE: There are none so blind (Was: Re: updated VMS Information (sent yesterday))
    ... I have no doubt that some Customers are doing some serious stuff with ... security patches - most of which require system reboots. ... effort to QA/test monthly security patches with their mission critical ... Kerry Main ...
    (comp.os.vms)
  • Re: Assembly Rename with Interfaces
    ... I haven't played with type forwarding before, ... We have a .NET application that hosts different kinds of child applications ... interface was well thought out and should almost never need to be modified. ... has purchased, however, this is very confusing to customers who see it. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Interesting Article: How Microsoft Lost the API War
    ... point is that the customers aren't always asking for "full power". ... Thin gives us access to remote data, but the interface sucks ... > really even need a data access layer when the remote user might be using ...
    (borland.public.delphi.non-technical)
  • Re: Fast uC with CAN
    ... > I am looking for a uC for my application: a CAN to RS232 interface. ... > Most important spec is that it must not miss any messages when ... > while running code though not necessary) ... The part officially supports 10,000 write cycles, but lab tests on other AVR ...
    (comp.arch.embedded)