By: Paul A. Clayton (see.text.delete@this.endof.sig), September 1, 2007 7:39 am
Room: Moderated Discussions
Vincent Diepeveen (diep@xs4all.nl) on 9/1/07 wrote:
---------------------------
>Richard Cownie (tich@pobox.com) on 8/31/07 wrote:
>---------------------------
[snip]
>>I can't put a figure on it. It's just my experience from
>>being around various hardware/software developments that
>>the way to achieve low latency is to have few layers of
>>protocol and be ruthless about keeping it simple. And CSI
>>doesn't seem to have that flavor.
>>
>
>Well i agree that usually the KISS principle works best, that said, by now most
>KISS principles have been tried and improving upon it usually means making things more complex.
>
>I definitely see this protocol can save some power from idle nodes and in many
>companies, servers never get turned off and simply idle 14-23 hours of the day.
>
>Of course in hardware, comes more complexity, comes usually a higher production
>cost, causing that if you put something to the exponent production costs, then you've got your sales price.
Isolating functionality into more layers of a protocol can
make a design more manageable relative to fewer but more
complex layers. Of course, adding layers does tend to have a
performance cost. (Later tuning can virtualize or merge
layers or even migrate functionality.)
Just restating the obvious, I suppose.
Paul A. Clayton
non-programmer, non-architect, but not entirely ignorant
---------------------------
>Richard Cownie (tich@pobox.com) on 8/31/07 wrote:
>---------------------------
[snip]
>>I can't put a figure on it. It's just my experience from
>>being around various hardware/software developments that
>>the way to achieve low latency is to have few layers of
>>protocol and be ruthless about keeping it simple. And CSI
>>doesn't seem to have that flavor.
>>
>
>Well i agree that usually the KISS principle works best, that said, by now most
>KISS principles have been tried and improving upon it usually means making things more complex.
>
>I definitely see this protocol can save some power from idle nodes and in many
>companies, servers never get turned off and simply idle 14-23 hours of the day.
>
>Of course in hardware, comes more complexity, comes usually a higher production
>cost, causing that if you put something to the exponent production costs, then you've got your sales price.
Isolating functionality into more layers of a protocol can
make a design more manageable relative to fewer but more
complex layers. Of course, adding layers does tend to have a
performance cost. (Later tuning can virtualize or merge
layers or even migrate functionality.)
Just restating the obvious, I suppose.
Paul A. Clayton
non-programmer, non-architect, but not entirely ignorant
