[Arm-netbook] EOMA server standard

[Gordan Bobic]

On 10/28/2012 08:24 PM, luke.leighton wrote:
> On 10/28/12, Gordan Bobic<gordan at bobich.net>  wrote:
>
>>>> So add a chip to do it, maybe?
>>>
>>>    no.  absolutely not.  whatever the cost of that chip is, it's
>>> automatically too much.  see b), below, which i note conspicuously you
>>> didn't reply to or say "fair enough" or anything :)
>>>
>>>    it could be $0.50 for that chip, but automatically that's too much,
>>> esp. as that could be *greater* than the entire profit margin for a
>>> mass-volume 100 million+ units product.
>>
>> To get a better product with more/better features most people probably
>> wouldn't mind paying an extra $0.50 on the end retail price.
>
>   it doesn't work that way.
>
>   you have to bear in mind that a) it won't be an extra $0.50 it'll be
> an extra $1.00
>   b) an extra $1.00 on a retail price makes it uncompetitive when
> compared to the other products which are not
> EOMA-{insert-version-which-has-a-mandatory-$0.50-IC}
>
>   so the retailers will feel compelled to compare like-with-like
> product, and demand from the manufacturer that the one with the EOMA
> card be given to them for *exactly* the same price.
>
>   the manufacturer will, to shift the stock, be compelled to do so.
>
>   the *manufacturer* will then lose $0.50 in profit.
>
>   that $0.50, especially in the mass-volume retail sector, where the
> product's BOM is say $30 or less, might *be* their profit.
>
>   ... you understand?

I don't thing this is applicable, because EOMA isn't competing with 
anything else out there. We are talking about speccing out standards 
here, not speccing out products. If the standard is based on a 
particular set of features then all the card manufacturers are in the 
same +$0.50 boat, so the playing field is still level. And regardless, 
there will always be price differentials because SoCs have different 
prices (difference of far more than $0.50), and there are other factors, 
too. For example:

Say you want to use an SoC that doesn't have built in graphics for a 
particular purpose. So you just leave the graphics related pins not 
connected and instead you have a serial console (does one of the USB 
connection double up as a slave side serial console?).

If you allow this sort of thing to work (i.e. graphics being optional), 
you have different classes of products that aren't going to be in the 
same price bracket purely by choice of SoC/components.

If you don't allow that to work you are automatically excluding some 
SoCs that might be usable to implement cheaper products with fewer 
features by enforcing a one-size-fits-nobody approach, which is at least 
as bad.


>   in the mass-volume retail sector it simply doesn't work the way you think.
>
>   however, in the *high-end* sector, you would be absolutely right.
> $0.50 would make absolutely no odds.  but in the high-end sector, the
> chances are that you would use a better IC that didn't require that
> $0.50 part in the first place (i.e. it would probably have a composite
> video output.)
>
>   *but*.... because the EOMA-68 standard covers high *and* low end, the
> standard has to be designed to cover both.
>
>   therefore, composite video is out, because if composite video was
> "in", it would jeapordise the viability of the low-end sector.

This only applies if you are fixated on the one-size-fits-nobody method 
of standardising. IMO this is the wrong approach to take because you 
lose more than you gain. Compatibility is far more important than 
complete feature equality.

>   it's really quite simple, but has to take in a hell of a lot of
> factors into consideration.
>
>   the server area's one i still can't quite get my head round, though.
>
>> So instead you cripple the standard by excluding the possibility of
>> using anything with PCIe?
>
>   no gordan, there's no excluding of anything.  please don't put words
> into my mouth.  i'm asking for people to contribute and discuss in an
> open fashion - not accuse people of "crippling" anything.

I didn't mean to accuse you of anything - perhaps I worded it poorly, 
and if that is the case, then I sincerely apologize. However - the point 
I was making remains (and remains unclarified). That point was that by 
extension of "no optional interfaces" approach you are effectively either:

1) Excluding SoCs that don't have all the required features (e.g. PCIe)

or

2) Excluding the possibility of use of features that a lot of (but not 
all of) the SoCs have (for example, but not limited to, PCIe).

Gordan