CASTalk.com

"Bill Todd" <billtodd@metrocast.net> wrote in message
news:_LqdnYZvmt0JvALeRVn-og@metrocastcablevision.com...

Russell Crook - Computer Systems - System Engineer wrote:
Stephen Fuld wrote:

"Douglas Siebert" <dsiebert@excisethis.khamsin.net> wrote in message
news:dnknd9$frq$1@narsil.avalon.net...

Discussion of whether Niagara would be usefull for Google


For memory bound tasks (like their index
searches, since the indexes are entirely RAM resident from what I
understand
of their setup) it wouldn't be useful, because you are limited by your
memory bandwith.



Then wouldn't the multiple independent servers actually be better (not
the same, but better) as you could get far more memory bandwidth from
say 8 totally independent memory systems each attached to one x86 system
than with one memory system attached to a single Niagara processor?

I'm having difficulty seeing how the above differs from what Doug stated:
he seemed to be suggesting (as was I) that Niagara would be a win for
those tasks primarily involving traffic-cop-style data movement from
storage to the network (for which my vague recollection is Google uses
different servers than it uses for index processing).

But he also said that Niagara wouldn't be useful (which I interpreted to
mean it wouldn't provide any benefit, but also wouldn't cause any loss
versus multiple x86 servers) on memory bound tasks such as the index
processing. I tried to point out, perhaps clumsily, that it could be at an
actual disadvantage due to the reduced total memory bandwidth provided by
eight independent servers versus a single Niagra. (Even given its four
memory controllers as Russell pointed out)

--
- Stephen Fuld
e-mail address disguised to prevent spam

On Sun, 11 Dec 2005 02:52:26 -0500, Bill Todd <billtodd@metrocast.net>
wrote:

Robert Klute wrote:
On Sat, 10 Dec 2005 03:25:03 -0500, Bill Todd <billtodd@metrocast.net
wrote:
Let's not forget that this blog, like all company blogs,
is a marketing tool.

As distinct from the more informal marketing that company employees may
engage in in places like comp.arch, I suppose.

You are right, anything I say as an individual will always be tainted by
my association with HP as my employer. So, I guess, the only right
course for me is to be mute on the subject so as not to have my personal
observations confused with anything HP might say.

Robert Klute wrote:

On Sun, 11 Dec 2005 02:52:26 -0500, Bill Todd <billtodd@metrocast.net
wrote:


Robert Klute wrote:

On Sat, 10 Dec 2005 03:25:03 -0500, Bill Todd <billtodd@metrocast.net
wrote:
Let's not forget that this blog, like all company blogs,
is a marketing tool.

As distinct from the more informal marketing that company employees may
engage in in places like comp.arch, I suppose.


You are right, anything I say as an individual will always be tainted by
my association with HP as my employer. So, I guess, the only right
course for me is to be mute on the subject so as not to have my personal
observations confused with anything HP might say.

Given the degree to which I've seen its employees parrot the corporate
line, even in cases where it contained outright lies (though in fairness
the most blatant examples of this came from then-Compaq employees
regarding the Alphacide, shortly prior to the merger announcement), any
such 'taint' is quite easily justifiable.

But it doesn't mean that you need to keep your mouth shut: it just
means that you should be a bit more careful about casting aspersions
about the objectivity of others, especially in cases where your
disagreement with them just happens to parallel your employer's interests.

- bill

Given the degree to which I've seen its employees parrot the corporate
line, even in cases where it contained outright lies (though in fairness
the most blatant examples of this came from then-Compaq employees
regarding the Alphacide, shortly prior to the merger announcement), any
such 'taint' is quite easily justifiable.

But it doesn't mean that you need to keep your mouth shut: it just
means that you should be a bit more careful about casting aspersions
about the objectivity of others, especially in cases where your
disagreement with them just happens to parallel your employer's interests.

Bill, has it occurred to you that perhaps some employees were just as
in the dark as customers about the Alpha-cide? I mean, honestly,
employees don't know everything the CEO or VP of marketing does.

DK

David Kanter wrote:

Given the degree to which I've seen its employees parrot the corporate
line, even in cases where it contained outright lies (though in fairness
the most blatant examples of this came from then-Compaq employees
regarding the Alphacide, shortly prior to the merger announcement), any
such 'taint' is quite easily justifiable.

But it doesn't mean that you need to keep your mouth shut: it just
means that you should be a bit more careful about casting aspersions
about the objectivity of others, especially in cases where your
disagreement with them just happens to parallel your employer's interests.


Bill, has it occurred to you that perhaps some employees were just as
in the dark as customers about the Alpha-cide? I mean, honestly,
employees don't know everything the CEO or VP of marketing does.

David, has it occurred to you to make real efforts to assimilate what
you have read before commenting incompetently on it?

Of course a lot of employees were just as much in the dark as customers
were - but that has nothing to do with the comment which I made.

The comment (still right up there above where you quoted it) was about
parroting the corporate line, even to the degree of parroting the lies
that were part of it and lending one's own personal credibility (such as
it may be) to them.

Parroting lies if you know they are lies is unethical. Parroting lies
if you don't know they are lies is incompetent and irresponsible - as
is, for that matter, parroting *anything* which you cannot personally
vouch for as fact (as contrasted with simply reporting that someone else
has alleged something to be fact).

Only in cases where one has personal knowledge that the line fairly and
accurately represents reality is parroting it reasonable.

During the course of this conversation Robert has been at best quite lax
(which is to say 75% - 86% dead wrong, by one metric) in his own
generalizations about Niagara's relative merit - uniformly, of course,
in the direction of the interests of his employer. Now, this certainly
may reflect merely inherent bias (and a certain cognitive sloppiness) on
his part rather than any concrete intent to deceive, but when he
combined this with a derogatory comment about someone *else's*
credibility it seemed appropriate to comment on that.

- bill

Bill Todd wrote:

If Google is indeed concerned about processor power dissipation, then
almost by definition they've designed their system (which they've
apparently designed to the hilt) such that each processor is working very
close to as hard as it can - i.e., running *enough* I/O-bound
largely-independent software threads to saturate it, or nearly so.

I assume that if they were worried about powerconsumption, then they might
be using SGI Origins which seems to havee fairly low power CPU's. If my
memory serves me right each CPU dissipates around 20W.

I have not checked the total power consumption of an Origin system.

Or they might have used a VIA C3 or equivalent processor in a MiniITX
system. This draws comparatively little power. Mine is a 933MHz unit drawing
0.65A with some other equipement.

greetings,

Greg Lindahl wrote:

Try working out how much you pay for power now. A typical number is
less than 10% of the cost of the hardware, per year. So over a 3-year
lifetime, it's not bigger than the cost of the servers. And while it
would be nice to lower that number, it doesn't drive TCO, so Sun is
going to have a hard time selling Niagra to new customers, unless said
new customers are out of machine room capacity.

Irrelevant math. Separate machines cost a lot of money to run. If you can
collapse 8 servers into one, then there is a substantial saving in more than
rack space.

I belive I read somewhere that the cost of the hardware was only 15-20% of
the total cost of ownership.

And BTW. You should assume that a server is in use for more than three
years. They certainly are where I work. Try 5+ years.

greetings,

Tarjei T. Jensen wrote:

Bill Todd wrote:

If Google is indeed concerned about processor power dissipation, then
almost by definition they've designed their system (which they've
apparently designed to the hilt) such that each processor is working
very close to as hard as it can - i.e., running *enough* I/O-bound
largely-independent software threads to saturate it, or nearly so.


I assume that if they were worried about powerconsumption, then they
might be using SGI Origins which seems to havee fairly low power CPU's.
If my memory serves me right each CPU dissipates around 20W.

Possibly, but it would surprise me if the TCO of such a system could
compete with banks of COTS PC hardware in Google's environment.

I have not checked the total power consumption of an Origin system.

Or they might have used a VIA C3 or equivalent processor in a MiniITX
system. This draws comparatively little power. Mine is a 933MHz unit
drawing 0.65A with some other equipement.

I don't know how relatively important power consumption was to Google
when it made its *original* choices, nor exactly how the choices
available within the x86 camp stacked up then (or do now) in performance
per unit of power on Google's workload. The one thing that *is* clear
is that they've devoted considerable effort toward optimization, and
hence that whatever their platform they're probably exercising its
processors fairly hard in pursuit of that unless some other constraint
precludes that.

- bill

Douglas Siebert wrote:

valuable for certain tasks. For memory bound tasks (like their index
searches, since the indexes are entirely RAM resident from what I understand
of their setup) it wouldn't be useful, because you are limited by your
memory bandwith. But for more disk or network intensive work Niagara may
be a big win for them.

Couldn't Niagara be a big win when they are pointer chasing through
their index? As long as there is enough parallellism in teh memory
system, that is...


Thomas

In article <43a3d049$3@news.broadpark.no>,
Tarjei T. Jensen <tarjei@online.no> wrote:

Irrelevant math. Separate machines cost a lot of money to run. If you can
collapse 8 servers into one, then there is a substantial saving in more than
rack space.

That was the claim of blade vendors. It hasn't really held up.

And BTW. You should assume that a server is in use for more than three
years. They certainly are where I work. Try 5+ years.

You are welcome to compute the 5 year number from the 3 year number.

-- greg

lindahl@pbm.com (Greg Lindahl) writes:

In article <43a3d049$3@news.broadpark.no>,
Tarjei T. Jensen <tarjei@online.no> wrote:

Irrelevant math. Separate machines cost a lot of money to run. If you can
collapse 8 servers into one, then there is a substantial saving in more than
rack space.

That was the claim of blade vendors. It hasn't really held up.

Aren't blade servers running different OS images on each blade?
A large part of the "server" costs is the cost of maintaining yet
another OS image.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In article <43a52f38$0$11072$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

Aren't blade servers running different OS images on each blade?
A large part of the "server" costs is the cost of maintaining yet
another OS image.

That's an intersting assertion; no wonder clusters have been a total
failure!

Hint: when you automate it, it's not bad.

-- greg

Greg Lindahl <lindahl@pbm.com> wrote:

In article <43a52f38$0$11072$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

Aren't blade servers running different OS images on each blade?
A large part of the "server" costs is the cost of maintaining yet
another OS image.

That's an intersting assertion; no wonder clusters have been a total
failure!

Hint: when you automate it, it's not bad.

-- greg

Most clusters tend to be relatively homogeneous,
which makes it easier to maintain.
Certainly your comment is true for hpc clusters
which probably is what majority of clusters are used for.

However, Niagara is not targetted for hpc clusters
(although there are a few integer/memory-bandwidth intensive
HPC apps that benefit from Niagara)
but for cosolidating multiple servers used for different non-HPC workloads
(directory, app server, nfs, database, etc).

In this context, I think a Niagara box combined with Solaris zones
can reduce the administration effort and the power bill
more than typical blade servers or clusters.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Greg Lindahl <lindahl@pbm.com> wrote:

In article <do6v1e$b86$1@news1nwk.SFbay.Sun.COM>,
Seongbae Park <Seongbae.Park@Sun.COM> wrote:

Most clusters tend to be relatively homogeneous,
which makes it easier to maintain.
Certainly your comment is true for hpc clusters
which probably is what majority of clusters are used for.

This is true. However, the less homogeneous case is dealt with nicely
by several software packages. One free example is cfengine, which is
used in quite a few large, inhomogeneous Unix sites.

Sun happily sells softwares like:

http://www.sun.com/software/products/se ... /index.xml

which automates and provides automated management for such.

So does Sun really want to claim an advantage which is not there if
the customer is using best practices?

Oh well, if you want to take my word as what "Sun" says, good luck :)
All my postings are my personal opinion - which of course
has strong bias favoring Sun - and do not reflect Sun's official anything.
I hope I don't need to put that unnecessary disclaimer...

Anyway, even if you use "the best practice",
there is still the inherent difference of having multiple kernels vs one.
e.g. cfengine doesn't solve problem of patch management
and extra third-party software installation/configuration/maintenance.
If you can reduce the overhead of maintaining multiple kernels
to negligible, obviously it won't matter if you can reduce that overhead futher.
I believe it's not negligible most of the time
and there are many cases where it's significant,
and Niagara combined with Solaris Zones can be of great help for such
(among other things).
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

In article <do6v1e$b86$1@news1nwk.SFbay.Sun.COM>,
Seongbae Park <Seongbae.Park@Sun.COM> wrote:

Most clusters tend to be relatively homogeneous,
which makes it easier to maintain.
Certainly your comment is true for hpc clusters
which probably is what majority of clusters are used for.

This is true. However, the less homogeneous case is dealt with nicely
by several software packages. One free example is cfengine, which is
used in quite a few large, inhomogeneous Unix sites.

So does Sun really want to claim an advantage which is not there if
the customer is using best practices?

-- greg