[occi-wg] Horizontal & vertical scalability in the cloud

[Sam Johnston]

On Mon, Oct 26, 2009 at 6:44 AM, Randy Bias <randyb at cloudscaling.com> wrote:

> This is hard.  CPU 'clock cycles' are not equivalent.  This is why Amazon
> uses a very specific processor and year to create their ECU.  The 2007
> 1.2Ghz processors all road on 800Mhz FSBs, which limited the amount of
> memory bandwidth (among other things).  Whereas modern CPUs and the much
> better/faster busses of today mean that you can feed the CPU much faster.
>

Now this is relevant because there was some contention (for reasons unknown)
over the inclusion of quantitative measurements of performance
characteristics such as memory
bandwidth<http://en.wikipedia.org/wiki/List_of_device_bandwidths#Memory_Interconnect.2FRAM_buses>.
Surely if some providers (or individual nodes) are using slow RAM, buses,
storage devices, etc. then as a consumer I should be able to find out about
it and/or set parameters on it? Conversely if I have an application that
requires ridiculously fast storage (say, SSD) then I should be able to
request this based on raw performance figures (the "what" rather than the
"how").


> My point isn't that you shouldn't do it, it's simply that it's tricky.
>
> If I had to make a recommendation it would be to baseline off of the Amazon
> ECU.
>

Interesting idea but surely that too is a moving target? Would it not also
favour Intel over AMD (or vice versa)? Having a standard unit to measure
against is an interesting idea, like the standard
kilogram<http://en.wikipedia.org/wiki/File:CGKilogram.jpg>,
and perhaps it's something that could be built from commodity components.

Sam

On Oct 25, 2009, at 7:56 PM, Sam Johnston wrote:
>
> I think you've touched on an interesting point there which ties in to the
> "need" for a universal compute unit
>
>
>
> Randy Bias, Founder & Cloud Strategist, Cloudscaling
> +1 (415) 939-8507 [m], randyb at cloudscaling.com <randyb at neotactics.com>
> BLOG: http://cloudscaling.com/blog
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091026/d545c89f/attachment.html