By: anon (anon.delete@this.anon.com), October 3, 2011 4:04 pm
Room: Moderated Discussions
Jesper Frimann (jesperfrimann@gmail.com) on 10/3/11 wrote:
---------------------------
>anon (anon@anon.com) on 10/3/11 wrote:
>---------------------------
>>anon (anon@anon.com) on 10/3/11 wrote:
>>---------------------------
>>>Jesper Frimann (jesperfrimann@gmail.com) on 10/3/11 wrote:
>>>---------------------------
>>
>>>>
>>>>It's no where as complex, as what a large outsourcing provider has to deal with. Cause you name it we've got it.
>>>
>>>I think you would be surprised. (I have no internal knowledge of google aside from what has been made public)
>>>
>>
>>What I mean by this is that: Google's fleet/cloud/cluster/whatever you call it
>>is a service provider to the rest of the company. As you know it is a pretty large
>>company doing a very wide (and changing) range of things. They have to accommodate these users.
>>
>>Their range of hardware is difficult to know. But they are interested in hard disks
>>(according to papers they have published), but they also use a lot of nand flash.
>>They probably largely try to keep to homogeneous nodes, but they will surely have
>>at least a couple of generations of node transitioning through its life. Based on
>>some apparent interest in larger nodes, it wouldn't surprise me if they do indeed
>>have fewer, larger nodes for some particular jobs.
>>
>>
>
>I have no doubt that Google have a factor more servers than we do.
(2 factors more)
>But if I was to do a concept like google, I would run it much like a supercomputer installation.
>Hence we are talking very few types of servers, which are basically different versions
>of the same concept, that is slowly evolving, and getting replaced when it makes economical sense to do it.
>Furthermore OS would surely be of the type you normally label as 'SuperCloned',
>and would then also be running in few different versions.
>
>So perhaps if you were to look at the "node type" x "OS versions" factor you would have max 10 different combinations.
>
>Now I have compaq pc's, I have Alpha 4100's, I still have HP3000 systems, an AS400
>B30 from 1988 and I also have a pair of POWER 795's...
>
>I have Windows,zOS,Tru64,Linux,SunOS,AIX .... in pretty much all supported and unsupported versions.
>I have Symetrix, Centera,MSA,EVA,XP,SSA....
>I have network switches from 25 different vendors...
>
>I get tired just thinking about all the combinations.
Oh, in that case, yes, your combinatorial problem with respect to hardware and OS software could easily be on par with Google.
>
>Now the 'problem' Google has to solve is a big one. But it doesn't have as many
>dimensions as the reality that my group has to face. So IMHO no hybris on my side :)
Well... depends on what you define as their 'problem' :)
From purely administrative point of view, perhaps. But they have to do all the scheduling out of jobs and gathering results from a million machines. Fitting job jigsaws together on each machine to utilize most of the resources (eg. put memory, CPU, network, disk intensive jobs together, rather than several CPU intensive jobs on the same box).
I would say that although they gain something in standardization and being able to dictate hardware, they gain whole other dimensions in the size and costs.
---------------------------
>anon (anon@anon.com) on 10/3/11 wrote:
>---------------------------
>>anon (anon@anon.com) on 10/3/11 wrote:
>>---------------------------
>>>Jesper Frimann (jesperfrimann@gmail.com) on 10/3/11 wrote:
>>>---------------------------
>>
>>>>
>>>>It's no where as complex, as what a large outsourcing provider has to deal with. Cause you name it we've got it.
>>>
>>>I think you would be surprised. (I have no internal knowledge of google aside from what has been made public)
>>>
>>
>>What I mean by this is that: Google's fleet/cloud/cluster/whatever you call it
>>is a service provider to the rest of the company. As you know it is a pretty large
>>company doing a very wide (and changing) range of things. They have to accommodate these users.
>>
>>Their range of hardware is difficult to know. But they are interested in hard disks
>>(according to papers they have published), but they also use a lot of nand flash.
>>They probably largely try to keep to homogeneous nodes, but they will surely have
>>at least a couple of generations of node transitioning through its life. Based on
>>some apparent interest in larger nodes, it wouldn't surprise me if they do indeed
>>have fewer, larger nodes for some particular jobs.
>>
>>
>
>I have no doubt that Google have a factor more servers than we do.
(2 factors more)
>But if I was to do a concept like google, I would run it much like a supercomputer installation.
>Hence we are talking very few types of servers, which are basically different versions
>of the same concept, that is slowly evolving, and getting replaced when it makes economical sense to do it.
>Furthermore OS would surely be of the type you normally label as 'SuperCloned',
>and would then also be running in few different versions.
>
>So perhaps if you were to look at the "node type" x "OS versions" factor you would have max 10 different combinations.
>
>Now I have compaq pc's, I have Alpha 4100's, I still have HP3000 systems, an AS400
>B30 from 1988 and I also have a pair of POWER 795's...
>
>I have Windows,zOS,Tru64,Linux,SunOS,AIX .... in pretty much all supported and unsupported versions.
>I have Symetrix, Centera,MSA,EVA,XP,SSA....
>I have network switches from 25 different vendors...
>
>I get tired just thinking about all the combinations.
Oh, in that case, yes, your combinatorial problem with respect to hardware and OS software could easily be on par with Google.
>
>Now the 'problem' Google has to solve is a big one. But it doesn't have as many
>dimensions as the reality that my group has to face. So IMHO no hybris on my side :)
Well... depends on what you define as their 'problem' :)
From purely administrative point of view, perhaps. But they have to do all the scheduling out of jobs and gathering results from a million machines. Fitting job jigsaws together on each machine to utilize most of the resources (eg. put memory, CPU, network, disk intensive jobs together, rather than several CPU intensive jobs on the same box).
I would say that although they gain something in standardization and being able to dictate hardware, they gain whole other dimensions in the size and costs.
| Topic | Posted By | Date |
|---|---|---|
| On the UltraSPARC T4 | Gabriele Svelto | 09/27/11 01:32 PM |
| "perceptron-based" based branch predictor | Mark Roulo | 09/27/11 02:17 PM |
| On the UltraSPARC T4 | DaveC | 09/27/11 02:22 PM |
| On the UltraSPARC T4 | Gabriele Svelto | 09/27/11 03:28 PM |
| On the UltraSPARC T4 | DaveC | 09/27/11 03:59 PM |
| TPC-H benchmark result | Michael S | 09/27/11 03:44 PM |
| TPC-H benchmark result | Jesper Frimann | 09/28/11 01:43 AM |
| TPC-H benchmark result | Michael S | 09/28/11 02:39 AM |
| TPC-H benchmark result | Jesper Frimann | 09/28/11 03:49 AM |
| TPC-H benchmark result | Gabriele Svelto | 09/28/11 09:44 AM |
| TPC-H benchmark result | Phil | 09/28/11 05:56 AM |
| TPC-H benchmark result | Michael S | 09/28/11 06:23 AM |
| TPC-H benchmark result | someone | 09/28/11 06:54 AM |
| TPC-H benchmark result | Jesper Frimann | 09/28/11 07:39 AM |
| cracking benchmarks | anon | 09/28/11 02:10 PM |
| cracking benchmarks | Jesper Frimann | 09/28/11 09:39 PM |
| TPC-H is not a good benchmark | David Kanter | 09/28/11 05:02 PM |
| TPC-H benchmark result | someone | 09/28/11 06:50 AM |
| TPC-H benchmark result | Michael S | 09/28/11 07:11 AM |
| TPC-H benchmark result - the high priced spread | blaine | 09/28/11 07:22 PM |
| TPC-H benchmark result - the high priced spread | Jesper Frimann | 09/28/11 09:41 PM |
| TPC-H benchmark result - the high priced spread-SPARC T4 still comes out ahead! | Phil | 09/29/11 12:06 AM |
| TPC-H benchmark result - the high priced spread-SPARC T4 still comes out ahead! | Jesper Frimann | 09/29/11 01:49 AM |
| TPC-H benchmark result - the high priced spread-SPARC T4 still comes out ahead! | Phil | 09/29/11 02:13 AM |
| TPC-H benchmark result - the high priced spread-SPARC T4 still comes out ahead! | Jesper Frimann | 09/29/11 03:24 AM |
| TPC-H benchmark result | AC | 10/10/11 01:11 AM |
| TPC-H benchmark result | Jesper Frimann | 10/10/11 02:24 AM |
| But woulnd't that make TPC-H meaningless? (NT) | Daniel Bizo | 10/11/11 12:29 AM |
| not very meaningful already | Michael S | 10/11/11 01:09 AM |
| OLTP vs. analytic DBMS | David Kanter | 10/11/11 02:44 PM |
| software or hardware | sp4mysf | 09/29/11 06:14 AM |
| On the UltraSPARC T4 | Thu Nguyen | 09/27/11 04:40 PM |
| On the UltraSPARC T4 | Brett | 09/27/11 08:21 PM |
| On the UltraSPARC T4 | David Kanter | 09/27/11 08:33 PM |
| On the UltraSPARC T4 | anon | 09/27/11 08:56 PM |
| TERA MTA | Mark Roulo | 09/28/11 08:36 AM |
| TERA MTA | anon | 09/28/11 03:11 PM |
| TERA MTA | Michael S | 09/29/11 12:58 PM |
| TERA MTA | anon | 09/29/11 01:46 PM |
| TERA MTA | Brett | 09/29/11 02:33 PM |
| Are you sure? | Michael S | 09/29/11 03:19 PM |
| Are you sure? | Brett | 09/29/11 05:31 PM |
| I trust The Register more | Paul A. Clayton | 09/30/11 10:15 AM |
| TERA MTA | mpx | 09/30/11 05:33 AM |
| On the UltraSPARC T4 | anon | 09/27/11 08:28 PM |
| On the UltraSPARC T4 | Phil | 09/28/11 12:23 AM |
| On the UltraSPARC T4 | David Kanter | 09/28/11 12:57 AM |
| On the UltraSPARC T4 | Gabriele Svelto | 09/28/11 09:22 AM |
| Database clustering | David Kanter | 09/28/11 04:55 PM |
| Database clustering | Phil | 09/29/11 12:15 AM |
| Database clustering | David Kanter | 09/29/11 09:12 AM |
| Database clustering | Alex Fatkulin | 09/29/11 11:14 AM |
| Database clustering | David Kanter | 09/29/11 09:11 PM |
| Database clustering | Anon | 09/30/11 12:32 AM |
| Database clustering | David Kanter | 09/30/11 01:23 AM |
| Database clustering | mpx | 10/05/11 01:12 AM |
| Database clustering | Jesper Frimann | 09/30/11 02:14 AM |
| Database clustering | Anon | 09/30/11 10:14 PM |
| Database clustering | Jesper Frimann | 10/01/11 04:24 AM |
| Database clustering | Anon | 10/01/11 05:27 PM |
| Real system level : ) | David Kanter | 10/02/11 06:59 PM |
| Real system level : ) | Anon | 10/05/11 11:36 PM |
| Database clustering | anon | 10/02/11 05:34 PM |
| Database clustering | Jesper Frimann | 10/03/11 01:56 AM |
| Database clustering | anon | 10/03/11 08:55 AM |
| Database clustering | anon | 10/03/11 11:41 AM |
| Database clustering | Jesper Frimann | 10/03/11 02:24 PM |
| Google... | EduardoS | 10/03/11 03:24 PM |
| Google... | Aaron Spink | 10/04/11 01:02 AM |
| Database clustering | anon | 10/03/11 04:04 PM |
| Database clustering | Jesper Frimann | 10/04/11 02:42 AM |
| Database clustering | anon | 10/04/11 08:13 AM |
| Database clustering | EduardoS | 10/04/11 08:29 AM |
| Database clustering | anon | 10/04/11 08:45 AM |
| Database clustering | bakaneko | 10/04/11 09:11 AM |
| Database clustering | Gabriele Svelto | 10/04/11 10:39 AM |
| Database clustering | anon | 10/04/11 10:51 AM |
| Database clustering | Gabriele Svelto | 10/04/11 01:27 PM |
| Database clustering | anon | 10/04/11 01:39 PM |
| Database clustering | Jesper Frimann | 10/04/11 11:26 AM |
| Database clustering | anon | 10/04/11 01:37 PM |
| Database clustering | anonymous | 10/02/11 10:27 PM |
| Database clustering | mpx | 10/01/11 04:40 AM |
| Database clustering | Alex Fatkulin | 09/30/11 05:42 AM |
| Database clustering | Jesper Frimann | 09/30/11 06:19 AM |
| Database clustering | Alex Fatkulin | 09/30/11 06:33 AM |
| Database clustering | Jesper Frimann | 09/30/11 08:44 AM |
| Database clustering | Alex Fatkulin | 09/30/11 09:01 AM |
| Database clustering | Jesper Frimann | 09/30/11 09:55 AM |
| Database clustering | Alex Fatkulin | 09/30/11 10:07 AM |
| Database clustering | Jesper Frimann | 09/30/11 11:11 AM |
| Database clustering | Alex Fatkulin | 09/30/11 11:33 AM |
| Database clustering | Jesper Frimann | 09/30/11 03:00 PM |
| Database clustering | anon | 10/01/11 09:18 AM |
| Database clustering | Michael S | 10/01/11 10:33 AM |
| Database clustering | Jesper Frimann | 10/01/11 10:22 PM |
| Database clustering | Jesper Frimann | 10/12/11 11:14 PM |
| Warning: Bad pun (no content) | Paul A. Clayton | 10/12/11 11:32 PM |
| Good one *8^) (NT) | Jesper Frimann | 10/12/11 11:56 PM |
| Database clustering | Alex Fatkulin | 10/04/11 08:09 AM |
| Database clustering | Jesper Frimann | 10/04/11 11:35 AM |
| Database clustering | Gabriele Svelto | 10/04/11 01:40 PM |
| Database clustering | David Kanter | 10/04/11 02:45 PM |
| Database clustering | Jesper Frimann | 10/05/11 12:09 AM |
| Database clustering | EduardoS | 09/30/11 02:13 PM |
| Database clustering | Alex Fatkulin | 10/04/11 05:56 AM |
| Database clustering | mpx | 09/30/11 10:39 AM |
| Database clustering | EduardoS | 09/30/11 02:07 PM |
| Database clustering | Alex Fatkulin | 10/04/11 06:01 AM |
| Database clustering | mpx | 10/05/11 01:02 AM |
| Database clustering | Jesper Frimann | 10/01/11 01:32 AM |
| Database clustering | mpx | 09/30/11 12:20 AM |
| Database clustering | EduardoS | 09/30/11 02:09 PM |
| TPC-C king | Michael S | 09/28/11 02:31 AM |
| On the UltraSPARC T4 | someone | 09/28/11 11:23 AM |
| Flash vs. disk on SPECjEnterprise2010? | Paul A. Clayton | 09/27/11 03:29 PM |
| Flash vs. disk on SPECjEnterprise2010? | Gabriele Svelto | 09/27/11 10:23 PM |
| Flash vs. disk on SPECjEnterprise2010? | Jesper Frimann | 09/28/11 12:04 AM |
| Flash vs. disk on SPECjEnterprise2010? | Phil | 09/28/11 12:32 AM |
| Are you trolling? | David Kanter | 09/28/11 01:07 AM |
| memory bandwidth clarification etc.. | Michael S | 09/28/11 02:23 AM |
| memory bandwidth clarification etc.. | Jesper Frimann | 09/28/11 04:13 AM |
| memory bandwidth clarification etc.. | Phil | 09/28/11 06:06 AM |
| memory bandwidth clarification etc.. | Jesper Frimann | 09/28/11 09:25 AM |
| There is one (another one)... | EduardoS | 09/28/11 02:54 AM |
| There is one (another one)... | Michael S | 09/28/11 03:59 AM |
| Are you trolling? Yes, trolling for substantiation!! | Phil | 09/28/11 05:47 AM |
| Are you trolling? Yes, trolling for substantiation!! | Jesper Frimann | 09/28/11 11:01 AM |
| Are you trolling? Yes, trolling for substantiation!! | Phil | 09/29/11 12:26 AM |
| Are you trolling? Yes, trolling for substantiation!! | Jesper Frimann | 09/29/11 02:27 AM |
| Are you trolling? Yes, trolling for substantiation!! | Phil | 09/29/11 04:46 AM |
| Are you trolling? Yes, trolling for substantiation!! | David Kanter | 09/28/11 05:15 PM |
| Are you trolling? Yes, trolling for substantiation!! | Phil | 09/29/11 12:53 AM |
| Are you trolling? Yes, trolling for substantiation!! | Jesper Frimann | 09/29/11 07:43 AM |
| Pricing | David Kanter | 09/28/11 05:28 PM |
| Pricing | Jesper Frimann | 09/28/11 09:56 PM |
| Pricing | Michael S | 09/29/11 01:42 PM |
| T4 better at cryptographic workloads? | Paul A. Clayton | 09/28/11 05:49 AM |
| T4 better at cryptographic workloads? | Gabriele Svelto | 09/28/11 09:36 AM |
| T4 better at cryptographic workloads? | Jesper Frimann | 09/28/11 11:10 AM |
| T4 better at cryptographic workloads? | Gabriele Svelto | 09/28/11 12:56 PM |
| T4 better at cryptographic workloads? | Max | 09/29/11 06:53 AM |
| Instruction- vs. coprocessor-based extensions | Paul A. Clayton | 09/28/11 04:48 PM |
| Memory versioning? | anon | 10/02/11 08:48 PM |
| Memory versioning? | David Kanter | 10/02/11 09:31 PM |
| Memory versioning--not just for TM? | Paul A. Clayton | 10/09/11 02:37 PM |
| Memory versioning--not just for TM? | Gabriele Svelto | 10/09/11 10:11 PM |
| Memory versioning--not just for TM? | David Kanter | 10/11/11 03:15 PM |
| Point well taken | David Kanter | 09/28/11 05:18 PM |
| T4 better at cryptographic workloads? | EduardoS | 09/28/11 05:36 PM |
| Are you trolling? | Gabriele Svelto | 09/28/11 09:49 AM |
| An addendum on I/O | David Kanter | 09/28/11 11:29 AM |
| An addendum on I/O | Phil | 01/27/12 08:19 AM |
| An addendum on I/O | anon | 01/27/12 11:04 AM |
| An addendum on I/O | David Kanter | 01/27/12 03:47 PM |
| An addendum on I/O | Kira | 01/27/12 04:23 PM |
| Meant POWER7 (NT) | David Kanter | 01/27/12 06:55 PM |
| An addendum on I/O | Jesper Frimann | 01/29/12 07:58 AM |
| Are you trolling? | anon | 09/28/11 01:03 PM |
| Flash vs. disk on SPECjEnterprise2010? | mpx | 09/29/11 01:05 AM |
| Well done! | David Kanter | 09/27/11 07:10 PM |
| Well done! | Gabriele Svelto | 09/27/11 10:39 PM |
| On the UltraSPARC T4 | mpx | 09/29/11 12:56 AM |
| How much memory it supports? | EduardoS | 10/11/11 01:37 AM |
| How much memory it supports? | Michael S | 10/11/11 04:14 AM |
| Big power miss on T4? | David Kanter | 07/16/12 09:24 PM |
| Big power miss on T4? | Gabriele Svelto | 07/17/12 11:26 PM |
| Big power miss on T4? | David Kanter | 07/19/12 04:04 PM |
| Big power miss on T4? | Kira | 07/19/12 05:44 PM |
| Big power miss on T4? | EduardoS | 07/19/12 06:19 PM |
| Big power miss on T4? | Kira | 07/19/12 09:37 PM |
| Big power miss on T4? | David Kanter | 07/19/12 10:15 PM |
| T4->T5 | blaine | 07/21/12 08:39 AM |
| Big power miss on T4? | EduardoS | 07/20/12 08:18 AM |
| Big power miss on T4? | mpx | 07/20/12 01:26 AM |
| Big power miss on T4? | EduardoS | 07/20/12 08:26 AM |
| Big power miss on T4? | Gabriele Svelto | 07/21/12 12:38 AM |



