Opened 2 years ago

Last modified 8 months ago

#28423 new defect

improve precision of finegrained periodic event scheduling?

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 040-deferred-201915
Cc: dgoulet, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The periodic.c events are scheduled with respect to the current time, via event_add() with a timeout. But libevent's periodic events are scheduled with respect to their last planned time, to prevent drift.

With the parent branch, I'm changing second_elapsed_callback() to just be a regular periodic event. Will the change in scheduling mechanism break anything?

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by nickm

I ran an experiment for a while to see how frequently second_elapsed_callback was called on a not-too-loaded desktop after we made it a periodic event:

Nov 13 13:31:52.000 [notice] Called 4560 times in 4564 seconds

We need to check whether this is ok.

comment:2 Changed 2 years ago by teor

Does this behaviour differ by OS?
I know that macOS tries to coalesce timers across the entire OS wherever possible.

comment:3 Changed 2 years ago by nickm

It probably does -- the issue here is the way in which timers are scheduled. Libevent's behavior for a periodic event with period P is to look at the time at which the event was last scheduled, and to reschedule the event P seconds later. The current behavior of periodic.c is to look at the current time, and then schedule the event P seconds later than the current time.

In other words, suppose that we have an event with a 60-second period, scheduled at noon. Suppose that because of delays, the event starts at 12:00:01 (a second after noon), and finishes at 12:00:02 (2 seconds after noon).

Libevent will schedule the event to run again at 12:01:00, since it was first scheduled for 12:00:00. Tor's periodic.c will schedule the event to run again at 12:01:02, since it finished at 12:00:02.

comment:4 Changed 2 years ago by nickm

Parent ID: #28335

comment:5 Changed 22 months ago by gaba

Sponsor: Sponsor8

comment:6 Changed 22 months ago by nickm

Keywords: 040-deferred-201915 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring some tickets from 0.4.0 without proposing them for later. Please tag with 041-proposed if you want to do them.

comment:7 Changed 17 months ago by nickm

Owner: nickm deleted

These tickets are not things I'm currently working on. They may be important, but they don't need to be done by me specifically. Un-assigning.

comment:8 Changed 8 months ago by teor

Status: assignednew

Change tickets that are assigned to nobody to "new".

Note: See TracTickets for help on using tickets.