Opened 17 months ago

Closed 5 weeks ago

#19254 closed enhancement (implemented)

Provide timestamps in the CIRC_BW and STREAM_BW events

Reported by: donncha Owned by: donncha
Priority: Medium Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-spec, tor-control, needs-decision, review-group-20
Cc: atagar Actual Points:
Parent ID: Points: 0.1
Reviewer: dgoulet Sponsor:

Description

Tor emits stream and circuit bandwidth events about once per second. However delays in the control port and controller libraries makes the event time not reliable enough for accurate bandwidth measurements.

It would be useful for making bandwidth authorities if both the STREAM_BW and CIRC_BW events included timestamps in the event.

Child Tickets

Change History (21)

comment:1 Changed 17 months ago by donncha

Status: newneeds_review

comment:2 Changed 17 months ago by nickm

Keywords: 029-proposed added

comment:3 Changed 17 months ago by nickm

I wonder if it might make sense to add a flag that made _all_ events get timestamps. Or would that be useless overgeneralization? Also I wonder if a fraction-of-seconds field would be helpful.

comment:4 Changed 17 months ago by donncha

I don't think it would be so straightforward to add timestamps to all the events. Some events are using keyword fields, and others use positional fields.

By fraction-of-seconds field to you mean having the microseconds from the timestamp listed in a separate field? Would that be much more helpful than just parsing the timestamp in the controller library you are using?

comment:5 Changed 17 months ago by cypherpunks

I have added event 1ms precision timestamps on a TCP control port client. Cross-checking against circuit events that include a TIME_CREATED field gives a perfect match.

So it seems the control protocol has low latency and clients already have the option of getting sufficiently accurate timestamps.

comment:6 Changed 17 months ago by donncha

cypherpunks: Thanks for checking that out. So a client with low load can get events quickly.

However I'm working on some asynchronous programming using Python Twisted. I think there are less guarantees of the program immediately getting and processing the event when it is emitted when using asynchronous style.

comment:7 Changed 16 months ago by nickm

Milestone: Tor: 0.2.???

comment:8 Changed 13 months ago by nickm

Keywords: 029-nickm-says-no added

comment:9 Changed 11 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:10 Changed 10 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:11 Changed 5 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 5 months ago by nickm

Keywords: 029-nickm-says-no removed

comment:13 Changed 4 months ago by nickm

Keywords: needs-spec tor-control needs-decision added; 029-proposed removed
Milestone: Tor: unspecifiedTor: 0.3.2.x-final

comment:14 Changed 4 months ago by nickm

Keywords: review-group-20 added

Creating review-group-20

comment:15 Changed 4 months ago by nickm

Owner: set to donncha
Status: needs_reviewassigned

setting owner

comment:16 Changed 4 months ago by nickm

Status: assignedneeds_review

comment:17 Changed 4 months ago by dgoulet

Points: 0.1
Reviewer: dgoulet
Status: needs_reviewmerge_ready

lgtm;

I've taken the tor patch to make it work on 032 (no change was needed): ticket19254_032_01

Spec patch needed a small change to say 032 and not 029: ticket19254_01

comment:18 Changed 4 months ago by nickm

Cc: atagar added

comment:19 Changed 4 months ago by dgoulet

Keywords: tor-spec added; needs-spec removed

comment:20 Changed 4 months ago by atagar

Spec change looks good to me - thanks!

comment:21 Changed 5 weeks ago by nickm

Resolution: implemented
Status: merge_readyclosed

merged!

Note: See TracTickets for help on using tickets.