Opened 5 years ago

Closed 5 years ago

#14128 closed enhancement (fixed)

GETINFO bw-samples to give recent BW events

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

Description

#13988 raises the interval at which bandwidth measurements are sampled. That's a pain for arm, which wants to use this information to prepopulate the bandwidth graph.

atagar asks for a means to get similar information from the last 1-5 minutes.

Child Tickets

Change History (10)

comment:1 Changed 5 years ago by nickm

Status: newneeds_review

Possible implementation in "ticket14128" in my tor repository.

Spec changes in "ticket14128" in my torspec repository.

Please review?

comment:2 Changed 5 years ago by atagar

Damn that was quick - thanks!

A space-separated summary of recent BW events in chronological order.

Please specify newest-to-oldest or oldest-to-newest.

Each event is represented by a comma-separated tuple of "MS,R,W", where MS is the number of milliseconds elapsed since the previous entry

That seems like an odd return value. I was thinking something like 'up to 300 R,W tuples where each represents a second worth of data'. No big whoop though. If this is what tor has handy then controllers can convert it into what they need.

Entries where R==W==0 are omitted.

Is that ok? An entry of...

'532,143,498 390,601,4331'

... says between 390-532 ms ago we wrote 143 bytes and wrote 498. This is different from...

'532,143,498 4189,0,0 390,601,4331'

... where that happened 4579-5111 ms ago.

comment:3 Changed 5 years ago by nickm

I removed some of the overengineering from those branches. Now it's one per (approx) second, zeroes not omitted. Like them better now?

comment:4 Changed 5 years ago by atagar

Looks good to me! Only nitpick left is that the spec should probably say it's up to 5 minutes worth of data.

comment:5 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.5.x-final

Actually, I'd prefer that any number of seconds be treated as conformant here.

(Merging to master; marking for possible backport. For backport, "bug14128_squashed" is the thing to cherry-pick)

comment:6 Changed 5 years ago by nickm

Actually, that should have said "ticket14128_squashed"

comment:7 Changed 5 years ago by arma

If we keep #13988 out of 0.2.5, then we can keep this one in 0.2.6 too, yes?

comment:8 Changed 5 years ago by nickm

Yes, but see cypherpunks's comment on #13988.

comment:9 Changed 5 years ago by nickm

Cherry-picked; I believe #13988 is potentially important.

comment:10 Changed 5 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed
Note: See TracTickets for help on using tickets.