[tor-bugs] #7359 [Tor]: Design/implement method for collecting/reporting statistics

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat May 25 17:57:13 UTC 2013


#7359: Design/implement method for collecting/reporting statistics
------------------------------------------------------------------------+---
 Reporter:  robgjansen                                                  |          Owner:                    
     Type:  enhancement                                                 |         Status:  needs_review      
 Priority:  normal                                                      |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor                                                         |        Version:                    
 Keywords:  performance, simulation, statistics, tor-relay, tor-client  |         Parent:  #7357             
   Points:                                                              |   Actualpoints:                    
------------------------------------------------------------------------+---
Changes (by karsten):

  * status:  needs_revision => needs_review


Comment:

 Replying to [comment:9 nickm]:
 > quick comments:

 I finally made it through the list!  Please see my updated morestats4
 branch.  It compiles, makes check-spaces happy, passes `--enable-gcc-
 warnings`, and runs in Shadow, but still I expect we'll need another
 iteration or two.  Below I'm replying to all comments that require more
 than just: "done."

 > General:
 >   * This needs to go along with a patch to control-spec.txt .

 Sure.  I converted proposal 218 into a control-spec.txt patch here:

 https://gitweb.torproject.org/user/karsten/torspec.git/shortlog/refs/heads/morestats4

 > e54d664f7bb1205162c1df3495f8ebc30c23d867
 >  * The last time we added K=V arguments in the middle of controller
 event, it created trouble for controllers, even though it wasn't supposed
 to do so, since the spec says we can.  Since nobody's actually hacking on
 Vidalia, would it be possible to just put the new K=V arguments at the
 end, to avoid possible trouble?

 rransom, I agree that sane controllers should handle this, but I also
 agree that we should change this, just to be safe.

 > 8d1f78c556abb570bb80ea84261c954d9746cf33
 >   * Instead of being controlled by TestingTorNetwork, should there be a
 separate option for EVENT_CONN_BW events?

 Added a new option TestingEnableConnBwEvent that depends on
 TestingTorNetwork being set, is 0 by default, and is changed to 1 if
 TestingTorNetwork is set.  I also added similar options for the other new
 events that are specified for test networks only.

 > c386d2d6ce4c4f58163acb385c7a5de1da8c5e30
 >  * cell_command_to_string doesn't really belong in control.c

 Moved to command.c, though I'm not entirely sure it belongs there.  If
 not, where would you want it to be?

 >  * append_cell_stats_by_command doesn't seem to document how long the
 arrays are.  I might be a bit more comfortable if it took a structure
 instead.  This

 Changed to a structure.  How does the last sentence end?

 >  * Is this really slow in practice? It seems like it's likely to be
 really slow.

 Do you mean slow or fast in your second sentence?

 If you refer to the comment explaining why we're re-using arrays for all
 circuits, maybe I didn't just mean slow, but also bad for memory
 fragmentation.

 >  * Prefer TOR_SIMPLEQ to manual list management for new queues.
 >  * This data structure ... how does it work out in practice? It looks
 like it's going to be hideously inefficient.

 I can't really think of a more efficient data structure.  What do you have
 in mind?  (I'll hold off changing the code to TOR_SIMPLEQ until I'm sure
 we want to use a queue there.)

 >  * This code needs unit tests and functional abstraction badly.

 I think functional abstraction is improved and code is now easier to test.
 I didn't write tests yet, because I'm not quite sure where to start.
 Would you mind writing one example test that I could use as a start for
 these functions?
  - connection_buckets_note_empty_ts in connection.c
  - bucket_millis_empty in connection.c
  - sum_up_cell_stats_by_command in control.c
  - append_cell_stats_by_command in control.c
  - format_cell_stats in control.c
 Are there any other new functions that need testing badly?

 Thanks!

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


More information about the tor-bugs mailing list