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

RE: Flagging a smart card as voted prior to the CAST BALLOT

What is the point of waiting until the CAST BALLOT screen button is pressed 
 
Attached. 
The reason for my request:
Jeff Hallmark told me today about an election experience with the AV-TS units in El Paso, TX.  The voter pressed the CAST BALLOT button and pulled the smart card out of the reader prior to the card being flagged as voted.   
 
Jeff, please demonstrate this for me.  The smart card is flagged just before the ballot is written to disk, so I doubt this could be the case.  It is possible there is a bug in there somewhere I am not aware of though.  Followups to bugtrack.
 
Ken
 

Title:

> Instead of Reading the Smart Card and then writing back to the
> Smart Cart to disable it, before we start the process of voting,
> could we read the card and then start the voting process of
> bringing up the instructions while the Card Reader is writing
> back to the Smart Card at the same time.  By doing this, we
> should be able to bring up the Voter Instructions in about 5
> seconds instead of 15 to 20 seconds.


Sorry for not responding to this sooner.  The intent was to reject the request, and I was going to make Tab do it since I hate having to field all the "we won't do that" RCRs.  The reasoning was going to be that optimizing AccuVote-TS access speed is hardly high priority given the real problems with the software.

I however got three calls yesterday explaining that this RCR will make-or-break the Riverside demo Tuesday.  If that is the case, I am sorely underpaid.  That notwithstanding, this RCR is now complete.

Jeff's suggestion is sound:  we can basically move the code to disable the card past the opening screen.  I have moved it to the "cast ballot" button in fact -- that is where it makes the most sense.  The card is not voted until we record the voter's votes.  If I read between the code lines, it looks like it was once actually done there.  If anyone knows why it was moved (if it was), or sees a problem with disabling the card at the end instead of the beginning, speak up.  Obviously, the cast ballot button takes longer now.  This is reasonable though;  it is easy to perceive that "recording the votes" somehow takes time. 

Unfortunately, only about 6 of the 16 seconds is spent disabling the card, and 10 seconds is still too long.  The code however spends most of its time bumbling around opening and closing things that are not necessary as far as I can tell. 

I have further optimized the code, and "fast pathed" the case of a CLXSA001 smart card (whatever that means).  The short story is that the startup time should now be 3 seconds instead of 16 when using the most common voter card type.  What "fast path" means though is that you don't get this for free.  The time it takes for manager and challenge cards is now greater, although only by a few seconds.  Ejecting the card might be a half a second longer too.  This seems a fair trade-off though.

These changes require testing.  My first attempt caused the voter card to get locked into the reader permanently if an already-voted card was inserted.  I am guessing that would not have gone over well in the demo.

> Also, could we start
> loading up the ballot image before you push the Start Button
> after reading the instructions. 


The time to fetch the ballot is actually negligible relative to the time to talk to the smart card.  It is just easier to explain to people that that is what the machine is doing -- fetching the ballot or recoding the votes.

Ken