On 9/25/13 5:45 AM, Damian Johnson wrote:
I think Roger uses it in his role as network debugger, not as authority operator. There may be more people wanting to help with network debugging who are not authority operators. And there may be expert relay operators who are wondering why their relay isn't listed or isn't listed with a given flag.
I would be really surprised if relay operators, even expert ones, find the table useful.
I disagree. It's useful information to know if some authorities don't assign flags or assign extra flags to a relay. That can help explain why the relay sometimes gets the flag if some of the authorities don't vote. Or in case of Named/Unnamed and Exit/BadExit, the flags contained in votes can help explain why a relay gets the Named or Exit flag. There may be more examples. Sure, this is like debug information, and not many relay operators will understand what's going on there. But saying that the information contained in the table is not useful is not correct.
That said, on irc Roger mentioned that he finds the table handy for finding trends he previously didn't know to look for. I suspect he's the only person using it for that, but it's both a reasonable use case and one that's frustratingly tricky to provide a good solution for that's also useful to others...
I have to say that I don't fully understand how skimming through the table provides an even basic understanding of trends. The table that shows the overlap between votes and consensuses would be a better start to discover trends:
https://metrics.torproject.org/consensus-health.html#overlap
(I didn't mention this, but I'd expect a replacement tool, CLI or web-based, to provide such a summary, too.)
A command-line tool doesn't sound too crazy. That tool (or suite of scripts) should be able to cache downloads and votes and share them among all queries we might want to ask it.
Agreed, this is a capability I'd *love* to have...
https://trac.torproject.org/projects/tor/ticket/9351
One bit I'm not sure how to address is cache invalidation. We can check when a descriptor has expired, but not when it is no longer the freshest.
Consensuses and votes contain these lines:
valid-after 2013-09-25 13:00:00 fresh-until 2013-09-25 14:00:00 valid-until 2013-09-25 16:00:00
You could invalidate consensuses and votes after fresh-until. Checking when a server descriptor or extra-info descriptor is not used anymore is slightly more difficult and probably requires looking at dir-spec.txt or the code. (We can move this discussion to the ticket. Feel free to paste this there if it's useful.)
$ ./doctor --download $ ./doctor --flag moria1:Running --flag maatuska:Running --noflag consensus:Running --count
I think you're misunderstanding my suggestion. My proposal is to *teach* Roger to write or adapt scripts to solve his questions. This would both empower him to answer more interesting questions than he presently can and, in the long run, save him time. I would be more than happy to write the first dozen, which he could then use to both learn stem and adapt to answer similar questions.
I'm not proposing a new tool. Rather, I'm suggesting that I teach a man to fish. ;)
Not sure if that's going to swim. Is it really a good use of Roger's time to write or adapt Python scripts? I guess he can answer that better than I (though I'm not sure it's a good use of his time to follow this thread ;)). However, we shouldn't be developing this tool just for Roger, because hopefully other people care about debugging the network, too. Just imagine what Tor devs would want to use whenever somebody shows up on #tor and asks why their relay doesn't have this or that flag, and imagine what's the easiest way to share results with the relay operator.
Thanks for your efforts here!
All the best, Karsten