|
There are two separate
issues/problems that are getting combined in this stream.
-----Original Message----- Steve Ricke has been running tests on a
specific unit from Seminole. He had a checksum error occur and had the
same result of the card resetting to pre-election mode and being able to reset
for election mode and continue. After that one error, he has since
run thousands of ballots through without a repeat of the error. The
original audit report for the Seminole corrupted memory card showed that
it had experienced the same error when Mickey Martin and company were
recounting ballots on November 9, 2000. Still testing. Below is the sequence of events for this
error. Hope it helps. Ian
Will continue to try with other cards and accu-votes from
other counties. Steve Ricke -----Original Message----- Thanks Guy, - the
pollworker did restart the unit and eventually put the unit back in election
mode. It did not require
redownloading the card. Am I
missing something in your explanation to understand this? John -----Original
Message----- This is an
overview on what memory card checksum errors are. Exactly what causes
them is a separate question. The memory card is very simply a
programmable memory device with a battery backup. The Accu-Vote accesses
this memory directly. If something goes wrong when the Accu-Vote is
writing new data to the memory card or if the Accu-Vote crashes (as computers
have been known to do) and writes to random memory locations, then the data on
the memory card may be corrupted (nasty word I know but it fits). All
this means is that the data is modified in an unintentional manner. This
could also happen without an Accu-Vote through static discharge or some types
of radiation (i.e. old airport scanners, cosmic rays???). There are several mechanisms that we could
use to detect this. We use the simplest of these which is to treat the
data as a series of numbers and store totals of sets of those numbers as
separate data known as checksums. If the data has been modified without
updating the checksums, then the checksums will fail to add up. The Accu-Vote keeps three different types
of checksums for three different classes of data. These are text,
counters, and precinct. The text checksums cover all the titles and names
that are used mostly just for printing reports. Since the text data does
not affect the other operations, we check it only occasionally and we allow
most operations to continue after a warning. The counters and precinct data are
considered critical and the Accu-Vote is largely inoperable when these
checksums fail. We do support the option to clear the counters if only
they have been affected and then counting may be restarted. However there
is no way to recover from corruption of the precinct data other than to clear
and re-download the memory card. All checksums are validated upon insertion
of a memory card or at power on. Thus this is the most common time to
detect problems. However the counter and precinct checksums are validated
every time a new ballot is scanned. If an error is detected, counting is
aborted. Now to Lana's questions. The above
should answer everything other than why erroneous data managed to upload.
I see two possible explanations. One is that the data was corrupted after
the checksums were validated. In this case the errors would show the next
time the checksums were checked. The other possibility is the miniscule
chance that the erroneous data managed to add up to the correct checksum.
The checksums are stored as totals ranging from 0 to 65535 so the chance of
this happening are less than 60,000 to 1 just based on that. Other
factors add to this to make it extremely unlikely. However in this case
the card would not later show checksum errors. So John, can you satisfy Lana's request
from this? I can't without more details.
Guy John McLaurin wrote: Please see below and let me know what you
think. Tab, one of these issues Please let me
know what you guys think. John -----Original
Message----- Hi Nel,
Sophie & Guy (you to John), |