Saturday, November 29, 2008

Two and a half weeks to count Instant Runoff Voting in Pierce Co and San Francisco

Not so Instant Runoff Voting. 2 and 1/2 weeks later, they were STILL counting the instant runoff votes from the November 4th election. I guess that is why San Francisco changed the name to "Ranked Choice Voting" as did Pierce County. These jurisdictions requested exceptions to their states' standards for voting systems in order to get IRV compatible voting software. These machines were used even though Pierce County found 3 separate and serious flaws in the software.

As of Friday, Nov 23rd, Pierce County was still tabulating the votes:
"Official algorithm results available Tuesday, November 25, 2008."

As of Friday, Nov 23rd, San Francisco's seven districts were still counting IRV ballots:

No candidate in this contest has received a majority of first-choice selections from the ballots counted as of today.

In order to release this preliminary report, the ranked-choice voting method was applied to this contest using the votes counted as of today. No candidate is being declared the winner or being eliminated from the contest. As in all elections, the Department will count all ballots cast in the election for this contest before determining the winner.

This is a preliminary report and it does not represent the final result for this contest
Last Updated: 11/21/2008

3rd bug found in Pierce County Instant Runoff Voting System

Pierce County Washington is up to "software bug number 3" in their new Instant Runoff Voting system. We blogged earlier this year about two other major software bugs in Pierce County's IRV voting system, first in June and then in September of 2008. Now there is a report of a third software bug in Pierce County's instant runoff voting software. This time it is a capacity issue - the software can't handle more than 200,000 votes at a time. This is a real problem since with IRV you end up with often 3 times as many votes as normal, capacity is a very real issue. These flaws may also affect San Francisco's IRV voting systems, as the voting systems are Sequoia Insight Optical scanners using WinEDS tabulating software. And San Francisco has around 430,000 registered voters.

Once you legislate IRV, you are backed into a corner. Politicians and the media press hard for "instant results" that can't be provided for weeks.

When a jurisdiction adopts "instant runoff voting" they find out that it is too laborious and complicated to count by hand. That leaves them searching for voting machines that can do the job. Right now, there are no voting systems in the US that are federally certified to count IRV. Earlier this year, Pierce County officials requested emergency certification of IRV software that had bugs in it because "they tried hand-counting just 14 RCV ballots with seven ranked contests and found that it was “horrendous.” Using software to tally this sort of balloting was absolutely essential." Ironically, it took Pierce County Washington and San Francisco California several weeks to count their "instant runoffs".

Bug number 2: Saturday, September 13, 2008 Pierce County Instant Runoff System has new bug, says Washington SOS - may affect San Francisco ...This email from the Secretary of State of Washington outlines another bug in the new IRV voting system for Pierce County. It affects "rank choice voting" (IRV/Instant Runoff) only.

Bug number 1: Friday, June 27, 2008 Instant runoff forces Pierce County Washington to use uncertified voting systems ... As you can imagine, we objected to having a system certified when, in testing, it reported that there were "zero votes" to start, but actually had 56 votes already in its secret, unobservable "ballot box"!

The Sequoia IRV software has a capacity issue in uploading and tabulating about 200,000 votes. Here is communication from an office of the Washington Secretary of State's office regarding the problem.


Bug number 3: From John Gideon on November 10, 2008

For those of you who are in states that use Sequoia and that may, in the future, be using WinEDS 4.0 here is some information from WA state where that version was used to support IRV in Pierce Co, WA. This is a string of emails between Ellen and a member of the SOS voting systems staff:

F.Y.I. – Sequoia has updated their documentation regarding the issue Pierce County ran into on Election Night -

Section 7.2.2 now contains the following recommendation:

Note: Excessively large 400-C batch loads may impede tally performance on election night. In extreme cases, the SQL memory, which is utilized for processing the tally, may be exceeded. In this situation, the following error message will display:

Tally process terminated early because of a trappable error.

If you receive this error, reduce the 400-C results batch size and re-import the results. Many factors, including the complexity of the election definition, can influence the allowable batch size that may be loaded. To ensure successful election night operations, Sequoia Voting Systems recommends loading 400-C results in batches not to exceed 25,000 ballots.

I have added this note to my certification folder so that we can make sure it is highlighted when we certify the WinEDS 4.0 system.


Patty Murphy Voting Systems Support

Office of the Secretary of State

(360) 902-4188 Fax (360) 664-4619

PO Box 40229 520 Union Ave NE Olympia, WA 98504

From: Murphy, Patty Sent: Monday, November 10, 2008 12:26 PM

To: 'Ellen Theisen' Cc: John Gideon; Miller, Paul; Hamlin, Shane

Subject: RE: Pierce County RCV

Hello Ellen,

Regarding the Nov. 6 article ( ) concerning delays with election results reporting in Pierce County – they were not hardware related. The memory that Pierce County added to the computer system was not actual physical memory. And it did not relate to the RCV algorithm, but it related to a miscommunication from the vendor to the county regarding moving results to the reporting system.

This is the vendor’s response -

Pierce encountered a delay on election night when they attempted to import their 400C results from WinETP (the tabulation server). WinEDS 4.0 (the reporting software) is designed to import 400C results in batch sizes on the order of 25,000 ballots or less. Pierce had consolidated all of their 400C results on WinETP into a single batch size of over 200,000 ballots. When they encountered the import constraint, we instructed them to increase their SQL Server memory configuration in order to successfully process the batch. This was a change made to the MS SQL Server configuration parameters only and had nothing to do with physical memory on the server computer.

This is another case of a vendor not communicating system usage limitations to a county. It was in no way Pierce County’s fault, but the vendor’s lack of proper communication regarding this upload protocol. However, the vendor responded quickly, and helped them solve the issue on election night. I’m sorry we didn’t catch this during testing – in retrospect, if I had thought to test combining all of our volume testing into one batch, and then uploading it to Win EDS for reporting, it may have caught this. This was partly an oversight on my part regarding the test scenario. I don’t think the national test laboratory would have caught this either because they would have uploaded results to Win EDS based on the vendor’s recommendation of 25,000 ballot batches.

So yes, reporting of results was delayed, but it was not due to a limitation in processing power, but a software limitation that was not properly communicated to the county. It is now properly documented in county procedures, and I have made a note to alert the other Sequioa counties to this protocol when the software is nationally certified and available for their use. (And when I say ‘limitation’ – it is not necessarily a bad thing. Uploading smaller batches has other benefits – more selective and efficient back out of batch loads, and audit comparison advantages when comparing Win ETP reports with Win EDS uploads.)

Let me know if you have any other questions. Patty Murphy Voting Systems Support Office of the Secretary of State (360) 902-4188 Fax (360) 664-4619 PO Box 40229 520 Union Ave NE Olympia, WA 98504

From: Ellen Theisen

Sent: Monday, November 10, 2008 9:24 AM To: Murphy, Patty Cc: John Gideon Subject: Pierce County RCV Patty, I was very disappointed to read in a November 6 news article regarding the memory that had to be added to the Pierce County system in the middle of tabulation:

"McCarthy said that while her office had tested the software previously, it did not test it with anywhere near the volume of ballots processed Tuesday. She said Pierce County is one of the first to use the software, so the problem could not have been foreseen."

But it was foreseen. If you remember, after the May hearing, I asked about that very issue.

I emailed you: "On the drive home, I was thinking about Denver in 2006, and trying to anticipate what RCV processing problems might come up that could be prevented. I began wondering whether the Pierce County system had sufficient processing power, disk storage, RAM, and cache to successfully do the processing required for 400,000 RCV ballots. It has to be significantly more stressful on a system than processing traditional ballots."

You responded: "Second, regarding processing power - the county purchased a new server, and when we extrapolated the processing power needed to cover the RCV ballots - they have plenty of power.

The RCV algorithm itself takes very little power in the CPU world." I do hope the extrapolation wasn't entrusted solely to Sequoia. Their estimate for what would be needed in Denver fell quite short. VotersUnite is in a position where we can sometimes pass on information to election officials based on the experiences of others. With that in mind, what else was learned from the experience in Pierce County that might be useful for other jurisdictions introducing RCV in the future?


Ellen Theisen Co-Director
-- John Gideon Co-Executive Director VotersUnite.Org

Instant runoff voting - counting by hand a nightmare?

Today in Voters Unite Daily news, John Gideon talks a little bit about IRV, aka Instant Runoff Voting. He says he has no opinion for or against IRV, but he does have a problem with the advocates who push for IRV even if it requires using voting machines and software that are proven to be defective (3 different bugs reported so far).. He also has a problem with a system that some election officials say is a nightmare to count by hand. (Emphasis below is mine.)

'Daily Voting News' For November 27 and 28, 2008

Guest Blogged by John Gideon of
I have been asked often about my position on Instant Runoff Voting [also known as Ranked Coice Voting]. My answer is always that I just haven’t formed an opinion on the basics of IRV. I do, however, have a problem with the fact that those who are avid supporters of IRV quite often favor IRV over voting system issues. They tend to be willing to turn a blind-eye to the use of voting systems that I would never support because there are no voting systems that actually support IRV that are federally certified. Two west-coast counties, Pierce in WA and San Francisco in CA, used Sequoia systems that were a mix and match of certified parts and tested parts that were never tested and certified to be used together. Officials in Minnesota are now talking about IRV for the future. When asked about a second or third count election officials said they would hand-count those ballots but officials who have done IRV say that would be a “huge nightmare”. One of the two west coast counties is even now thinking of going back to the voters to ask that IRV voting no longer be used. We agree with this position but only until there is a system that can actually count the ballots and not be a “huge nightmare”....

National: Hand-counting ballots in instant-runoff vote called 'huge nightmare’ http://www.startribune.c...aEP:kD:aUiD3aPc:_Yyc:aUU

The rest of John Gideon's daily news is over here at Brad Blog

IRV advocates argue that it is simple to hand count IRV ballots, that Ireland and Australia do it all of the time. Well these two countries often have no more than one or two items on the ballot, and it can take a long time to count.

Instant Runoff was a disaster in Cary North Carolina
Instant runoff voting was not so great in Cary North CarolinaEven "one of the best Boards of Elections in the state of North Carolina" had trouble counting IRV ballots in the Cary NC in Oct 2007 and provisional ballots weren't counted until after all rounds!:

It was difficult to count just 3,000 ballots correctly. Officials had to manually tally the IRV results for the Cary, NC “instant runoff”. There was confusion during the counting and ballots were miscounted and not properly allocated to the candidates. Friday, the day after the "runoff" or count of the 2nd round, the election director performed an audit, according to the media. Errors were discovered and the audit extended into a full blown recount...

....According to Chris Telesca who observed the IRV counting in Wake County, NC, to hand-process a little over 3000 paper ballots (after the first choice votes were counted on the op-scan machines) when there were only 3 candidates plus a few write-ins for the Cary district B, single member town council seat, and the counting went only two rounds

it took 6 sorting stacks for each of 12 ballot groupings or precincts (8 precincts plus absentee by mail in Cary, board of elections one-stop site, the Cary one-stop site, provisional ballots- Cary, and possibly some transfer votes from another county which were eligible to vote in the Cary IRV contest) or 12 times 6 stacks = 72 stacks.

Wake County officials decided to put each stack in a separate plastic bag to keep track. This would not be possible if there were more than one IRV contest because each contest requires independent sorting and stacking to count.

The procedure was very complicated, but it was there in print. Even so, the Wake Board of Elections (BOE) didn’t follow it. There was no overhead projector so that observers could follow the process. Non Board members were sorting the ballots into stacks which was hard to follow. Nonetheless, observers and the Board came up with different totals at the end of the day. The next day, the different totals were determined to be caused by a calculator error that was discovered in an “audit” – that also discovered a few missing votes...

Just 3,000 ballots!