Thank you! That was very informative and educational compared to the other replies.
Best Regards, William Kane 2020-07-29 3:18 GMT, Sebastian Hahn <[email protected]>: > Hi William, > >> On 29. Jul 2020, at 00:45, Matt Traudt <[email protected]> wrote: >> >> The Guard flag conditions are >> https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2640 >> >> Given you're Fast and Stable, and have a good advertised bandwidth and >> weight, then I suspect you simply no longer have a Weighted Fractional >> Uptime that is at least the median for "familiar" relays. >> >> Thus just give it time. >> >> This has nothing to do with volunteering to be a fallback directory >> mirror. >> >> Thanks for running a relay, and for doing so at an unpopular provider. >> >> On 7/28/20 9:29 AM, William Kane wrote: >>> Please discard the previous (empty) email, it was an error on my end. >>> >>> Today, I noticed that my guard flag has been taken away: >>> >>> https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF >>> >>> Does this have to do with the recent two, major downtime's of the relay? >>> >>> While I wasn't monitoring the server, the kernel decided (or rather >>> oom-killer did) to reap the tor process for consuming too much memory >>> (keep in mind, this is a virtual machine with only 1GB of RAM which >>> running another daemon consuming about ~92MB's of RAM). >>> >>> I promptly restarted the relay, but the same thing happened again >>> yesterday. >>> >>> So today, I manually set a lower MaxMemInQueues value instead of >>> letting Tor calculate one for me - 640MB's instead of 732MB's. >>> >>> Still, I am confused as for why the guard flag has been taken away - I >>> recently opted in to be a fallback directory mirror, does this have >>> anything to do with it? >>> >>> The relay was stable and online for almost a year, so only 48 hours of >>> downtime shouldn't affect the variables qualifying a relay to become >>> and stay a guard that much? >>> >>> If this is because of the directory mirror thing, then please take my >>> relay out of that pool - I want to stay a guard for a number of >>> reasons - mainly because my host is only hosting about 10 tor relays >>> unlike all the other big hosters that are commonly used - network >>> variety is very important or so I've been taught, especially when it >>> comes to guard relays. >>> >>> If this is a mistake on Tor Project's end, I please ask for it to be >>> resolved - however, if it's the Directory Authorities disqualifying my >>> relay, then there's nothing to be done except to wait. >>> >>> Greetings, >>> William Kane > > according to gabelmoo's vote, it requires: > flag-thresholds stable-uptime=1202114 stable-mtbf=3679804 fast-speed=102000 > guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=18400000 > guard-bw-exc-exits=14400000 enough-mtbf=1 ignoring-advertised-bws=1 > > gabelmoo assigns your relay the following values: > R 47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF > +MTBF 4632038 0.93987 S=2020-07-27 21:47:42 > +WFU 4632038 4728633 > > As you can see, you barely do not make the WFU (required: 98%, you have > 97.95%). Note that more recent downtimes are given more weight (that's > what the W stands for in WFU). Very soon your flag should be back. > > Cheers > Sebastian > > > > _______________________________________________ > tor-relays mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > _______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
