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-rel...
The newly added prop328 fields in oninoo appear to break with that convention https://metrics.torproject.org/onionoo.html#details_relay_overload_general_t...
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
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)
kind regards, nusenu
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-rel...
The newly added prop328 fields in oninoo appear to break with that convention https://metrics.torproject.org/onionoo.html#details_relay_overload_general_t...
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_ratelim...
[2] https://metrics.torproject.org/onionoo.html#bandwidth_bridge_overload_fd_exh...
kind regards, nusenu
Said this I will update both the timestamp and the protocol version for consistency.
thanks, appreciated. nusenu
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.
Is there a gitlab issue where this is tracked?
btw: "DNS timeout reached" can probably be removed from: https://metrics.torproject.org/onionoo.html#details_relay_overload_general_t...
kind regards, nusenu
-
nusenu -
Silvia/Hiro