[tor-dev] Dealing with frequent suspends on Android
teor at riseup.net
Wed Nov 28 22:24:35 UTC 2018
> On 27 Nov 2018, at 07:46, Nick Mathewson <nickm at alum.mit.edu> wrote:
> On Wed, Nov 21, 2018 at 5:10 PM Michael Rogers <michael at briarproject.org> wrote:
>> On 20/11/2018 19:28, Nick Mathewson wrote:
>>> Hi! I don't know if this will be useful or not, but I'm wondering if
>>> you've seen this ticket:
>>> The goal of this branch is to create a "dormant mode" where Tor does
>>> not run any but the most delay- and rescheduling-tolerant of its
>>> periodic events. Tor enters this mode if a controller tells it to, or
>>> if (as a client) it passes long enough without user activity. When in
>>> dormant mode, it doesn't disconnect from the network, and it will wake
>>> up again if the controller tells it to, or it receives a new client
>> The comments on the pull request
>> (https://github.com/torproject/tor/pull/502) ...
>> One of the comments mentions a break-even point for consensus diffs,
>> where it costs less bandwidth to fetch a fresh consensus than all the
>> diffs from the last consensus you know about. Are diffs likely to remain
>> available up to the break-even point, or are there times when it would
>> be cheaper to use diffs, but you have to fetch a fresh consensus because
>> some of the diffs have expired?
> This shouldn't be a problem: directory caches will (by default) keep
> diffs slightly beyond the break-even point.
> (I think. I haven't measured this in a while.)
We measured the number of cached consensuses after a collector outage in
Some relays had ~16 consensuses, others had ~24 or ~48.
If a relay is using lzma, zstd, and gzip compression, then it will only
store about 16 past consensuses:
If my sums are correct, that is:
128 files / 2 consensus flavours / (1 consensus + 3 compressed diffs) = 16 consensuses
Should we increase cache_max_num to 196?
Should we increase cache_max_num when the sandbox isn't being used?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Message signed with OpenPGP
More information about the tor-dev