[tor-bugs] #27135 [Core Tor/sbws]: Write descriptor bandwidths average in raw results

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Aug 20 03:33:12 UTC 2018


#27135: Write descriptor bandwidths average in raw results
---------------------------+-------------------------------------
 Reporter:  juga           |          Owner:  juga
     Type:  defect         |         Status:  assigned
 Priority:  Medium         |      Milestone:  sbws 1.0 (MVP must)
Component:  Core Tor/sbws  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:  #27108         |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-------------------------------------

Comment (by teor):

 Replying to [comment:12 juga]:
 >
 > > 1. Set the decay constant (R) to a number in (0, 1).
 > >
 > >     We get a descriptor every 12-18 hours, and there is a daily cycle
 in Tor bandwidths.
 >
 > If i just get the descriptor every 12h, after 5 days will have 10 values
 for it, and if it changes, then i think would be enough to get the mean of
 them.

 Descriptors can change every hour, and bandwidths can change for new
 relays every 3 hours. So it would be better to get the descriptor every
 hour.

 I don't think you should use the mean, because old values are much less
 relevant than newer values. (But if you want to write code that takes 10
 values and calculates the mean, I can rewrite it to calculate a decaying
 weighted average.)

 > > So we want to average over a few days, to smooth out spikes. A good
 value for R is 0.98 every hour, because the decaying average for 15 hour
 bandwidths is 26% B1 + 19% B2 + 14% B3 + 11% B4 + 30% B5-10. (B11 is less
 than 1%.)
 >
 > Where these numbers (0.98, 26, 19,...) are coming from?. Mathematics
 might help

 0.98 is an arbitrarily chosen constant K that seems to produce a
 reasonable decay over a few days.

 The percentages are a geometric progression based on K, over a week of
 15-hour average descriptor times.

 In python, they are:
 {{{
 >>> K = 0.98
 >>> K15 = 0.98**15
 >>> for i in xrange(0,(7*24)/15):
 ...   print "(1 - K15)*(K15**{}) =".format(i), (1 - K15)*(K15**i)
 ...
 (1 - K15)*(K15**0) = 0.261430897355
 (1 - K15)*(K15**1) = 0.193084783263
 (1 - K15)*(K15**2) = 0.142606455109
 (1 - K15)*(K15**3) = 0.105324721581
 (1 - K15)*(K15**4) = 0.0777895851047
 (1 - K15)*(K15**5) = 0.0574529840659
 (1 - K15)*(K15**6) = 0.0424329988859
 (1 - K15)*(K15**7) = 0.0313397019097
 (1 - K15)*(K15**8) = 0.0231465355166
 (1 - K15)*(K15**9) = 0.0170953159659
 (1 - K15)*(K15**10) = 0.0126260721723
 }}}

 > > 4. When voting:
 >
 > By when voting you mean when we generate the bandwidth list file?

 Yes.

 > > > btw, it seems that the answer to my question in [1] is that 1/45 ~=
 1/e
 > >
 > > Can you explain what you mean by `e`?
 > >
 > > The base of the natural logarithm is `e ~= 2.72`, so `1/e ~= 0.37`.
 >
 > i meant the natural logarithm, exactly that ^

 I still don't understand. But I don't think it's important.

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


More information about the tor-bugs mailing list