[tor-dev] onionoo overload_general_timestamp (prop 328)

Silvia/Hiro hiro at torproject.org
Mon Nov 8 13:58:40 UTC 2021


Hi,

On 6/11/21 15:19, nusenu wrote:
> Hi,
>
> in onionoo all timestamps used to be in the format
> YYYY-MM-DD hh:mm:ss
>
> Proposal 328 has timestamps in this same format
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md 
>
>
> The newly added prop328 fields in oninoo appear to break with that 
> convention
> https://metrics.torproject.org/onionoo.html#details_relay_overload_general_timestamp 
>
>
> Here is an example for an onionoo overload_general_timestamp which 
> appears
> to be at millisecond granularity (the source has a granularity of an 
> hour):
> 1636038000000

Thanks for reporting this. You are right this is probably a carry over 
for how the field was read in metrics-lib. I will be changing it to a 
human readable format as per specs.


>
> Was there a particular motivation for this format change and granularity?
> And what do you think about changing it to use the YYYY-MM-DD hh:mm:ss
> format for consistency and having a direct human readable format here 
> as well?
>
> related:
> Karsten used to maintain onionoo protocol documentation/changelog and 
> versions:
> https://metrics.torproject.org/onionoo.html#versions
> Is that and the 'version' field in onionoo no longer maintained?
> (since it didn't change with the new fields)

Sure, we intend to maintain the version field, and since new fields have 
been added the protocol version should have been updated.

The reason I haven't updated it yet was that I wasn't very pleased that 
we had to add the overload_ratelimits [1] and overload_fd_exhausted [2] 
fields in the bandwidth document. We needed to expose these fields, but 
we also knew these didn't belong to this document. So the idea was to 
plan a bigger release with a little restructure of the onionoo internals 
and update the protocol version then.

Said this I will update both the timestamp and the protocol version for 
consistency.

Thanks for bringing this up.


Cheers,

-hiro

[1] 
https://metrics.torproject.org/onionoo.html#bandwidth_relay_overload_ratelimits

[2] 
https://metrics.torproject.org/onionoo.html#bandwidth_bridge_overload_fd_exhausted

> kind regards,
> nusenu
>
>


More information about the tor-dev mailing list