#24729: Find reason for 'null' values in Onionoo document -----------------------------+------------------------------ Reporter: Dbryrtfbcbhgf | Owner: karsten Type: defect | Status: needs_review Priority: High | Milestone: Component: Metrics/Onionoo | Version: Severity: Major | Resolution: Keywords: | Actual Points: Parent ID: #24155 | Points: Reviewer: iwakeh | Sponsor: -----------------------------+------------------------------
Comment (by karsten): Replying to [comment:12 iwakeh]: > The suggestion in comment:4 seems ok, technically all data for shorter graphs can be taken from there. Agreed. > Can the clients using the data provide all useful/needed graphs with this change and deal with possibly omitted data? As of now, clients cannot handle this yet. But I think that's #24831, so at least Relay Search will be handle to handle this at some point. However, I thought more about omitting data. Maybe we should not do that. Here's a new idea: - We add a 6 month history object with a data resolution of 1 day. (Same as above.) - We drop the shorter graphs from clients documents with a data resolution of 1 day. (Same as above.) - If we compile a graph from a history '''only''' containing entries with a data resolution that is too low for the graph (e.g., data is provided for 24 hours, but the graph shows data for 12 hours), we skip that graph. (Same as we do right now, same as above.) - If we compile a graph from a history '''also''' containing entries with a data resolution that is too low along with entries with the high-enough data resolution (e.g., data is provided for 4 hour intervals, then for 24 hour intervals, then again for 4 hour intervals), we include that graph and interpolate data as necessary. (This suggestion is new. The earlier suggestion was to drop this graph.) Here's why I think that this suggestion is better: - Even if we add a 6 month graph today, the data in current status files for 3 to 6 months ago is already compressed to a resolution of 2 days. We'd basically have to wait 3 months for 6 month graphs to first appear, or we'd have to re-import data. Ewww. - I'm worried that there are edge cases where we're compressing data in status files a tiny bit too early. The effect might be that we're not providing any graphs at all. Here's a possible issue that I see with this suggestion: - Whenever a relay changes its reporting interval, graphs will suddenly be a lot less volatile, which might confuse relay operators wondering what happened. But I think the explanation that their relay is now reporting data on a lower resolution should be obvious enough to quickly answer those questions. I did not implement this, because I'd still want us to resolve #16513 first. Raising priority on that even more, so that we can finally resolve this one. How does this plan sound? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24729#comment:13> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs