Opened 11 years ago

Closed 9 years ago

Last modified 7 years ago

#943 closed defect (fixed)

Tor's once-per-second events are not quite once-per-second?

Reported by: arma Owned by: nickm
Priority: Low Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version: 0.2.0.31
Severity: Keywords:
Cc: arma, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Mar 16 11:07:43.655 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:44.659 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:45.663 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:46.667 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:47.671 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:48.675 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:49.676 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:50.679 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0
Mar 16 11:07:51.683 [debug] QtDebugMsg: torcontrol: Control Event: 650 BW 0 0

My 'bw' events are getting sent out slightly more than one second
apart. Didn't we try to send them out every second? More broadly,
is libevent calling our once-a-second events every 1.004 seconds or
the like?

Maybe that evtimer_add() call in second_elapsed_callback() should be at
the beginning? That seems a bit more fragile in the case where it takes
a whole second to process stuff. But if it takes any non-trivial amount
of time to process stuff, then that function isn't reliably getting
called once a second. How big a problem is that?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (5)

comment:1 Changed 11 years ago by nickm

The original rationale for scheduling the heartbeat for a second after the last heartbeat was _finished_ was to ensure
that at least a second's worth of processing happened between each heartbeat. If the function took more than a second
to finish, we could be bunching stuff up. I don't think this is a big problem though.

If we really want to do this properly, then instead of scheduling the heartbeat for a second after the last heartbeat
_finished_ (what we do now), or scheduling it for a second after the last heartbeat _started_ (what you recommend above),
we should really schedule it for a second after the last heartbeat _was sheduled to start_. That way we run every
second regardless of delays in Tor _and_ delays in libevent.

This could be tricky, though, and any changes here might have unforseen consequences. Can this wait till 0.2.2.x?

comment:2 Changed 11 years ago by arma

it can wait til 0.2.2.x

comment:3 Changed 9 years ago by nickm

Milestone: post 0.2.1.xTor: 0.2.2.x-final
Owner: set to nickm
Status: newassigned

There's an easy fix here for everybody on Libevent 2.0: when on Libevent 2.0, use a periodic timer rather than a periodically re-added timeout, and everything will be fine.

With an older version of Libevent, we'll still get the current behavior, but that's not so bad given how long we've lived with it anyway.

comment:4 Changed 9 years ago by nickm

Resolution: Nonefixed
Status: assignedclosed

Fix applied as ad2d8ac073 for 0.2.2.x. It's a very good fix if you're on Libevent 2.0, and a mostly good fix if you aren't.

comment:5 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.