Opened 7 years ago

Closed 6 years ago

#8532 closed defect (implemented)

Make TestingTorNetwork produce consensuses quicker

Reported by: ln5 Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: SponsorF20131031 tor-auth
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

First, trim time intervals as much as possible while keeping
everything stable. The current 5 minutes between voting could perhaps
change to 2. We might need to adjust other timings -- exhcanging votes
and signatures. Also, we might need to revisit the directory refetch
schedule which is changing in #6752.

Second, let's add an option to Tor in which we can pass an offset, in
seconds, to generate a consensus following a custom schedule every 5
minutes (or whatever we might change that to), rather than having to
wait for the next 5-minute interval. Example: Offset 75s would mean
that the consensus would be from 00:01:15 rather than 00:00:00.

Child Tickets

Change History (8)

comment:1 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:2 Changed 6 years ago by nickm

Keywords: tor-auth added; tor-relay removed

comment:3 Changed 6 years ago by ln5

In order for clients and relays to be able to postpone the first
consensus download for about 10s (using
Testing*ConsensusDownloadSchedule), run_scheduled_events() needs to
call update_networkstatus_downloads() more often than once per minute
(CHECK_DESCRIPTOR_INTERVAL).

Would letting it run every second be scary in any way? I'm thinking
about things like hosing the tor doing this and also about hammering
other tors for network status documents.

In update_networkstatus_downloads(), dir auths call
update_v2_networkstatus_cache_downloads() which currently won't do
anything with a higher frequency than ten minutes
(AUTHORITY_NS_CACHE_INTERVAL). That looks safe to me.

Then, every kind of tor invokes
update_consensus_networkstatus_downloads() which seems to have a few
guards -- time_to_download_next_consensus[i],
download_status_is_ready() and
connection_dir_get_by_purpose_and_resource().

To conclude, I don't see that it would be harmful to have
update_networkstatus_downloads() being invoked every second but would
really like to hear from other people on this.

comment:4 in reply to:  3 Changed 6 years ago by ln5

Status: newneeds_review

Replying to ln5:

To conclude, I don't see that it would be harmful to have
update_networkstatus_downloads() being invoked every second but would
really like to hear from other people on this.

I ended up doing this only when TestingTorNetwork is set.

Please see branch bug8532 both in my Tor repo and in my Chutney repo.

comment:5 Changed 6 years ago by ln5

Note that the first part of this ticket, shortening the voting interval, has not been addressed yet. I think it'd be valuable for testing changes to consensus voting, like new consensus methods, but that's probably not the most common changes to tor. If we still want it, I'd like to create a separate ticket for it.

comment:6 Changed 6 years ago by nickm

Status: needs_reviewneeds_revision

Looks plausible. I would like "options->TestingTorNetwork ? 1 : CHECK_NETWORKSTATUS_DOWNLOAD_INTERVAL;" to be a function or a macro. I'd also like to have as few things as possible controlled by TestingTorNetwork directly.

We should also open a ticket for removing that logic entirely to just do this once every second or every few seconds, if it's not expensive, or if it can be made not-expensive. After all, the less our testing code paths diverge from our main code paths, the better. But for now, I'm a little scared to make that change, since in production Tor, that one-minute check interval provides a limit to the maximum rate at which a buggy client could hammer the directory servers. So let's do it like this for now

comment:7 Changed 6 years ago by ln5

Status: needs_revisionneeds_review

Updated branch bug8532. Created #9045.

Please see branch bug8532 in my public Chutney repo too.

comment:8 Changed 6 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Merged both; thanks!

Note: See TracTickets for help on using tickets.