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

# RE: Ballot Station v4.0.11 "anomaly" and other JoCo questions

- To: <support@gesn.com>
- Subject: RE: Ballot Station v4.0.11 "anomaly" and other JoCo questions
- From: "Ken Clark" <ken@gesn.com>
- Date: Fri, 26 Apr 2002 09:38:26 -0800
- Importance: Normal
- In-reply-to: <2ce801c1ed3e$d9280b40$1404a8c0@TIredale>

Just as a mental note on this, we need to do some comprehensive testing on this whole “removed before transfer was complete” catch all explanation of problems. It has been the standard excuse for various corruption problems since the IMARK days. Even if the user yanks a card, it should not crash the system. There should be a well behaved message to the user of the problem, an internal log entry of the problem, and a request for the user to retry the operation. At the end of the night we upload the logs and say “ahh, there was a problem writing the audit log at 8:15pm on machine 127642, I wonder if that was the problem”. Right now we have none of this. Ken -----Original Message----- From: owner-support@gesn.com [mailto:owner-support@gesn.com] On Behalf Of Talbot Iredale Sent: Friday, April 26, 2002 8:25 AM To: Support Subject: Re: Ballot Station v4.0.11 "anomaly" and other JoCo questions I am taking this to the "Support" list where I think this discussion should take place. Lesley, First, as for any error that was displayed on election night, I was informed that an "SEH Error" was reported but I have not been able to find out any information about when this occured or any other information about this error. Rob had indicated he though the error might have been the result of a memory card being removed before the transfer was complete, i.e. while the AVTS was trying to write the audit log entry, since the upload did actually complete. Secondly, a laymans description of the problem. During "Transfer" the AVTS unit, for performance reasons, stores race and candidate information for the vote center in memory (caches) rather that reading from the memory card. When a new card is inserted for "Transfer" this data should have been cleared but was not. Therefore when the next memory card was inserted the cached data was incorrect, if the memory card was for a different vote center, and therefore the race and candidate identifiers for the counts were potentially incorrect. The problem did not accure when using the "Accumulator" since only the memory cards from a single vote center were transferred during a "Transfer" session. I have added additional comments below. Tab ----- Original Message ----- From: Lesley Thompson To: Talbot Iredale Sent: Thursday, April 25, 2002 8:04 PM Subject: Re: Ballot Station v4.0.11 "anomaly" and other JoCo questions Tab, my apologies, I just put the To: field on my view so I can see what groups are conversing...I'm still trying to navigate through all the "systems" here. Yet and still, can you offer a clearer explanation of what happened so I can understand from a "layman logic" viewpoint? And, I know we discussed an R6 error alert election night...do you have a record of what that code was and if it was caused by the 4.0.11 bug (Transfer vs. Accumulator)? JoCo requests more information than is currently in the report of findings. I know it seems as though we are beating a dead horse, but I've got to be able to "draw a picture" of this occurence. Can you help me? If I should be directing these questions to someone else, please advise. Lesley Talbot Iredale <tiredale@gesn.com> wrote: Lesley, This is not a bug so please do not send these type of discussions to bugtrack. This should have been sent to support instead. Tab ----- Original Message ----- From: "Lesley Thompson" To: Cc: "stevem" ; "barry" Sent: Thursday, April 25, 2002 3:54 PM Subject: RE: Ballot Station v4.0.11 "anomaly" and other JoCo questions > > Hello Jeff, > > R6 ERROR MESSAGES: at the risk of contradicting...while we did not receive > error messages on the GEMS side, we did receive error messages on the > AVTS-R6 units during the upload using the Transfer function. Specifically, > Connie then asked what she should do when the error message occurred and the > machine locked up. I seem to remember that she was told to leave off the > machine she was working on and use the one next to it. She and Kris > continued to receive error code messages during the upload, and moved around > through the three units as they were brought back up. The next day Robert > Chen was able to recreate the error message once. Since this was not > mentioned in the report, I am now being asked what the error messages were > and what they meant. If you continually recieve error messages on an operation this is a very good indicator of some problem and should be investigated. > > CENTRAL UPLOAD ONLY: I am also concerned, because due to this incident, > JoCo is opting to NOT modem in results from regional substations, much less > precincts. They are planning to set up parallel GEMS server systems to > upload all PC cards centrally, twice. That way they have two reports from > the same data loaded into separate systems to compare and audit. Is there > no way we can provide some kind of report off the Regional upload units that > can be compared to some kind of report from GEMS to be accountable that an > "anomaly" has NOT occurred? What is our "standard" check and balance proof > for returns on election night? Not doing modem uploads from the regions seems like a strange response to their problem since the region uploads did not have any problem. As for doing duplicate uploads, this would not have found the problem since, if they uploaded the memory cards in the same order on each machine, they would have identical (erronous) results in both databases. > > ELECTION SETUP DATABASE TECH REVIEW: During the discussions around the JoCo > April 2 election, I have come to understand that a "typical practice" used > by technical support reps is to review the customer's database prior to the > initial ballot order generation. I understand that JoCo > (Connie/Kris/Debbie) sent you the May all-mail election database for review. > They were concerned that you turned around your comments back to them in > less that "5 minutes." Exactly what in the database do we look for when > reviewing? Are there certain checkpoints or typical mistakes that you look > for? Do you run ballot styles off the database to make sure they work? Do > we have a laundry list of review elements? I am being asked to provide > documentation describing what our election setup database review covers, can > anybody help me with the basic elements? How do we know a customers > database will actually perform as intended? Do we also cover the election > night report styles the customer wants to generate election night so we can > make sure the database is setup to accommodate their expectations? I'm just > trying to understand. > > LOGIC AND ACCURACY PRETEST METHODOLOGY: A reference has been made to be > sure that a regional upload client be sure to include that functionality in > the logic and accuracy pretest. Do we have documentation on all the > functionalities that should be included in our logic and accuracy testing? > Is there a checklist to use to prepare the test and then to run the test? > For the optical scan test deck, why are we not sending out the algorithms > being used to created the test deck? If we at least send out "how the test > was prepared" we could account for NOT sending out a "Test Deck Report" to > compare the L&A report to. > > Thanks. Les > > > > > -----Original Message----- > From: owner-bugtrack@gesn.com [mailto:owner-bugtrack@gesn.com]On Behalf > Of Jeff Hintz > Sent: Thursday, April 25, 2002 4:28 PM > To: bugtrack@gesn.com > Cc: stevem; barry > Subject: RE: Ballot Station v4.0.11 "anomaly" > > > Hi Lesley, > > There was no Error Message received for this problem that occurred on > Election Night. The transferring of the results to the GEMS host computer > went through without any error messages displaying a problem. The problem, > as Tab wrote up in the e-mail that Frank sent out to Connie, is that during > the direct transferring process, the information on the first Vote Center > that was transferred, was stored in the Cache memory of the AVTS unit, when > the second, or subsequent, Vote Center was inserted and then transferred, > the AVTS unit was then transferring those new totals, but with previously > stored Race ID's as well as the new Race ID's, and GEMS being confused, > simply put the totals into the Races where it thought the totals should go. > > That is the best explanation that I can give you. For a better and clearer > picture, you will have to refer to Ken or Tab. > > Jeff > > -----Original Message----- > From: owner-bugtrack@gesn.com [mailto:owner-bugtrack@gesn.com]On Behalf > Of Lesley Thompson > Sent: Thursday, April 25, 2002 2:31 PM > To: BugTrack@gesn.com > Cc: stevem; barry > Subject: Ballot Station v4.0.11 "anomaly" > > > Jeff Hintz, Ken, Tab, or Robert Chen... > > What were the ballot station error code messages that were received during > the central upload of the election day vote centers? Johnson County still > has questions and I am trying to finalize the Report of Findings. Also, can > you explain to me what the statement: > > "This problem only occurred when the second, or subsequent, Vote Centers > being uploaded during the same transmission session, had the same Race as a > previously uploaded Vote Center." > > And, why would the Leawood Mayor's race, which was not on any of the vote > center PC cards uploading centrally, end up with errant votes? And, where > did the 300 votes go that were not accounted for in the initially released > report? > > Can someone draw me a picture? > > Thanks! Les > > Lesley Thompson Customer Service Project Manager Diebold Election Systems, Inc. 800-433-8683 512-413-7618 Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more

- References:
  - Re: Ballot Station v4.0.11 "anomaly" and other JoCo questions
    - From: "Talbot Iredale" <tiredale@gesn.com>

- Prev by Date: Re: Ballot Station v4.0.11 "anomaly" and other JoCo questions
- Next by Date: RE: current Spyrus software (1.1.2)
- Index(es):
  - Chronological
  - Thread