[tor-bugs] #2866 [Analysis]: Analyze bridges in the "reserved" bucket

[Tor Bug Tracker & Wiki]

#2866: Analyze bridges in the "reserved" bucket
----------------------+-----------------------------------------------------
 Reporter:  karsten   |          Owner:                
     Type:  task      |         Status:  needs_revision
 Priority:  normal    |      Milestone:                
Component:  Analysis  |        Version:                
 Keywords:            |         Parent:                
   Points:            |   Actualpoints:                
----------------------+-----------------------------------------------------

Comment(by peer):

 Replying to [comment:8 karsten]:
 > Sounds like we missed a few bridge pool assignment files when collecting
 them using metrics-db.  If this turns out to be problematic for your
 analysis, I can have a look why that happened.

 December 2012 was examined because the data was relatively clean. Aside
 from the missing files, there were no files during that month with zero
 entries, but intact header information.

 Regarding data, there might have been corruption in April 2012 with times
 2012-04-17 07:00:24 and 2012-04-29 01:00:13 where the assignment pool for
 one entry each appears to be truncated to one character.

 > I'm unclear why you count uptime sessions of the same bridge as distinct
 entries.  I'd think that bridges in the email or https buckets have higher
 overall uptime in the considered months than unallocated buckets.

 As mentioned and as illustrated in the
 [https://trac.torproject.org/projects/tor/attachment/ticket/2866/pool_counts.png
 pool counts plot], there is some noise and there are files with zero
 entries. Using sessions seemed to be a reasonable proxy as the same
 measure was used across the pools.

 > In theory, bridges are not re-assigned to other buckets.

 Good to know. The proportion of bridges in the unallocated pool appears to
 decrease over time. Have the proportions changed?

 > The fact that there are fewer entries for the unallocated pool may
 indicate that these bridges don't come back as often as bridges in the
 other pools.  See my comment above about counting uptime sessions of the
 same bridge more than once.

 Will consider cumulative uptime along with dropping the files with zero
 entries. The session counts are fairly similar across the pools, diverging
 for mean, Q3, and max.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2866#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online