From owner-freebsd-hackers@freebsd.org  Wed Sep 16 01:23:50 2015
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A74A9C2934;
 Wed, 16 Sep 2015 01:23:50 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 6D598157B;
 Wed, 16 Sep 2015 01:23:50 +0000 (UTC)
 (envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
 by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t8G1NdvM023263;
 Tue, 15 Sep 2015 18:23:43 -0700 (PDT)
 (envelope-from truckman@FreeBSD.org)
Message-Id: <201509160123.t8G1NdvM023263@gw.catspoiler.org>
Date: Tue, 15 Sep 2015 18:23:39 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
Subject: Re: ECC support
To: jim@netgate.com
cc: igor@hybrid-lab.co.uk, freebsd-hackers@freebsd.org, dieterbsd@gmail.com,
 freebsd-hardware@freebsd.org
In-Reply-To: <8435FBF3-2F8E-4A25-ABEA-B7038AFFE372@netgate.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-2022-jp
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Sep 2015 01:23:50 -0000

On 15 Sep, Jim Thompson wrote:
> 
>> On Sep 15, 2015, at 5:19 PM, Igor Mozolevsky <igor@hybrid-lab.co.uk>
>> wrote:
>> 
>> On 15 September 2015 at 22:52, Jim Thompson <jim@netgate.com
>> <mailto:jim@netgate.com>> wrote:
>> 
>> <snip>
>> 
>> Errors are corrected "on-the-fly," corrected data is almost never
>> placed back in memory. If the same corrupt data is read again, the
>> correction process is repeated. Replacing the data in memory would
>> require processing overhead that could accumulate and significantly
>> diminish system performance. If the error occurred because of random
>> events and isn't a defect in the memory, the memory address will be
>> cleaned of the error when the data is overwritten with other data.
>> 
>> <snip> 
>> 
>> Just to correct a small oversight- most (if not all?) boards have an
>> option to scrub ECC memory in the background so as to prevent single
>> bit (recoverable) errors from turning into double bit (irrecoverable
>> but detectable) errors ;-)
> 
> I think you’ll find that the default for ‘scrub’ is off on most
> (perhaps all) boards.  There are reasons, and these relate directly to
> “significantly diminish system performance”, (above), as well as the
> greatly increased RAM sizes in use today.

The Gigabyte AM3+ motherboards that I'm using have all sorts of knobs
for controlling the scrub rate, with different knobs for cache scrubbing
vs. main memory scrubbing.  My somewhat more recent Asus AM3+ board with
different BIOS brand basically just has an ECC on/off knob.