[Date Prev][Date Next] [Chronological] [Thread] [Top]

# Re: Logging Scanner Jams (was: Audit trail improvement suggestions)

- To: <rcr@dieboldes.com>
- Subject: Re: Logging Scanner Jams (was: Audit trail improvement suggestions)
- From: "Ian Piper" <ian@dieboldes.com>
- Date: Fri, 10 Dec 1999 12:26:51 -0600
- References: <003f01bf4262$637d0870$6e03a8c0@globalelection.com> <384FDB8C.E392EFAE@dieboldes.com> <006a01bf42b5$fd90c3e0$48ddfc9e@default>

Excuse me while I play the devil's advocate here. Is this "jam event record" something we want to have displayed or recorded at all? If there is a problem with the count totals between the AccuVote display and the ballots in the Ballot Box, why do you want to so quickly use it as an excuse? What would you do if there was no jam event recorded and yet there was still a mismatch between ballots in the box and the counter on the AccuVote? What would you get from a jam event record? That a jam happened? But who was at fault: the poll worker or the machine? How do you know if the mismatch was caused by that jam. Would they call into question the results of an election if a unit showed multiple jams yet the ballots totals matched the counters? I understand it would be great to have the detail for troubleshooting, but do you think they would find the fault due to the poll worker when they have a machine that could be perceived as "at fault" instead? I think less info is better under these circumstances. What kind of interpretation would someone make when seeing that detail? Example "Oh, look here! The paper tape shows it jammed during the day. The machine must be responsible for the error in the totals." If we provide this "jam event record" as an excuse, wouldn't it throw doubt onto the integrity of the machine and its programming. I believe it is better to leave answers for these unsubstantiated anomalies to the discretion of the election supervisor. Outside of the "O" level ROMS, when a ballot is processed into a Ballot Box by the AccuVote, it is counted. If a reader takes a ballot, it accurately scans that ballot and deposits it into the Ballot Box. If there is any problem with the reader (i.e., hung or failed Self Test), it will not process the ballot into the Ballot Box. Play out an election night scenario in your head with these kind of questions arising. Now imagine there is nobody there from Global to explain the information provided. Let's not consider every user's request as an absolute. Perhaps the user is just as much in the dark about the ramifications of that request as we are. Ian ----- Original Message ----- From: Steve Knecht To: Guy Lancaster ; Kerry Martin Cc: rcr@dieboldes.com Sent: Thursday, December 09, 1999 8:26 PM Subject: Re: Logging Scanner Jams (was: Audit trail improvement suggestions) I think the statistical approach would be adequate, although the log with a date and time stamp would be the preference. I think that saving these for the 2.0 release is OK in the sense that we might be able to "sell" the upgrade, vs having it be required. However, it might mean the AV would have to be recertified in many states. Not good. Other thoughts? ----- Original Message ----- From: Guy Lancaster <glanca@dieboldes.com> To: Kerry Martin <kerry@dieboldes.com> Cc: <rcr@dieboldes.com> Sent: Thursday, December 09, 1999 8:40 AM Subject: Re: Logging Scanner Jams (was: Audit trail improvement suggestions) > Some form of logging scanner jams has been brought up > before and I think that I spoke with Steve about a month ago > about it. This may also be related to Jane's RCR: Print > Vote Centers Activity of Oct 27, 1999. > > The problem, as Monica stated, is that the officials need > statistical support when trying to resolve discrepencies > between the number of ballots in the ballot box and the > number recorded by the Accu-Vote. I can see three possible > ways of providing this, each with pros and cons. > > 1) Add a stats counter for the number of jams experienced > since the counters were last cleared. While we're at it, we > could have separate counters for counted and returned ballot > jams. This would be my preference since it provides the > required statistics while consuming the minimum of > resources. However it requires a memory card format change > and so would only be available in major new releases such as > the upcoming version 2.0. These statistics would appear on > the audit reports and could be uploaded for reporting by > GEMS. > > 2) Print a log entry on the internal printer for each jam. > This could be selectively enabled and disabled from GEMS' > Accu-Vote parameters and would not affect the memory cards. > Downsides include having to prevent the tape from jamming > while it's locked in the printer compartment and having to > count the entries on the tape to gather the statistics. The > upside is that it would provide a timestamp on each entry > which could help with resolving the problems. > > 3) Record an entry in the audit log for each jam. This one > scares me a little because we have limited space on the > memory card for the audit log and currently we allow for > about 400 entries. The purpose of the log is to record > critical operations such as inserting the memory card, > powering on the unit, the starting and ending of counting, > printing reports, and a few others. Although possible, it > is very unlikely that we would overflow the audit log with > these entries. Events like jams are far less predictable > and a problem with a machine could cause a large number of > jams. Should the log overflow, the oldest entries are lost. > > Some would suggest that we increase the size of the audit > log or dynamically allow it to grow to use available memory > card space. The latter is technically difficult especially > if we want to record events starting from the beginning of > the download operation as we do currently. Allocating more > space for log entries comes at the expense of less space for > ballot information and counters which will affect those > counting absentee ballots. It seems less of an issue for > 128K memory cards than for 32K but once we decide to log > jams, we have to allow for it in all systems. > > My suggestion is to add support for optionally printing a > jam log message in the next 1.94 release. For version 2, we > would continue to support this plus add statistics counters > for jams. Unless people feel both that it is critical that > we record the time of each jam and that managing the printer > tape is not acceptable, I would avoid adding this to the > audit log. > > Guy > >

- Follow-Ups:
  - Re: Logging Scanner Jams (was: Audit trail improvement suggestions)
    - From: "Steve Knecht" <skglobal@earthlink.net>

- References:
  - Fw: Audit trail improvement suggestions
    - From: "Kerry Martin" <kerry@dieboldes.com>
  - Re: Logging Scanner Jams (was: Audit trail improvement suggestions)
    - From: Guy Lancaster <glanca@dieboldes.com>
  - Re: Logging Scanner Jams (was: Audit trail improvement suggestions)
    - From: "Steve Knecht" <skglobal@earthlink.net>

- Prev by Date: RE: Logging Scanner Jams (was: Audit trail improvement suggestions)
- Next by Date: Re: Logging Scanner Jams (was: Audit trail improvement suggestions)
- Index(es):
  - Chronological
  - Thread