Most energy efficient (home) setup

Douglas Otis dotis at mail-abuse.org
Thu Apr 19 22:31:43 UTC 2012


On 4/18/12 8:09 PM, Steven Bellovin wrote:
>
>  On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote:
> > Dear Jeroen,
> >
> > In the work that led up to RFC3309, many of the errors found on the
> > Internet pertained to single interface bits, and not single data
> > bits. Working at a large chip manufacturer that removed internal
> > memory error detection to foolishly save space, cost them dearly in
> > then needing to do far more exhaustive four corner testing.
> > Checksums used by TCP and UDP are able to detect single bit data
> > errors, but may miss as much as 2% of single interface bit errors.
> > It would be surprising to find memory designs lacking internal
> > error detection logic.
>
>  mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed
>  2,5d; date Request for Comments: 3309
>  Stanford September 2002
>
>  Wed Apr 18 23:07:53 EDT 2012
>
>  We are not in a static field... (3309 is one of my favorite RFCs --
>  but the specific findings (errors happen more often than you think),
>  as opposed the general lesson (understand your threat model) may be
>  OBE.
Dear Steve,

You may be right.  However back then most were also only considering 
random single bit errors as well.  Although there was plentiful evidence 
for where errors might be occurring, it seems many worked hard to ignore 
the clues.

Reminiscent of a drunk searching for keys dropped in the dark under a 
light post, mathematics for random single bit errors offer easier 
calculations and simpler solutions.  While there are indeed fewer 
parallel buses today, these structures still exist in memory modules and 
other networking components.  Manufactures confront increasingly 
temperamental bit storage elements, where most include internal error 
correction to minimize manufacturing and testing costs.  Error sources 
are not easily ascertained with simple checksums when errors are not random.

Regards,
Douglas Otis




More information about the NANOG mailing list