Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi, > On 26 Aug 2019, at 00:21, Felix wrote: > >> I found another relay [2] where at least 4 of the 9 authorities doesn't set >> the "Running" flag, which is needed for "Guard", right? >> That relay has a reasonable bw value to (23,000 , FWIW the value for [1] is >> about 90,000). >> >> So now I do wonder why the Running flag is lost after a year. >> >> [1] >> https://consensus-health.torproject.org/consensus-health-2019-08-24-07-00.html#509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 >> [3] >> https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA > > I have a similar experience like Toralf. Since a week all my relays (but > one) are middle relays. Which is fine because they push good traffic. The Guard flags is affected by the bandwidth authority measurements. > All are measured by maatu, gabel, moria1 and farav. But only one is > measured by longc and bastet. [1] > Why is that? longclaw and bastet run sbws, the other bandwidth authorities run torflow. There are 3 high-priority bugs that make sbws leave some useful relays out of its bandwidth file: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~sbws-majority-blocker These bugs stop us deploying sbws to more than 3 authorities. We expect to have funding to fix these bugs some time in the next month or two. Even after these changes, Torflow will still have more relays than sbws, because some of the relays that Torflow reports have been down for a long time. > My understanding is six of nine authorities measure bandwitdh. I can > download bandwidth files from all six from a _non_ measured server [2], > so connection is given. But I see about 2.4MB doc size from the ones > working for me and 4MB from the ones not working. > Any clue what is the difference between those? > > My family is [3]. The good relay is 402 and the `bad´ ones are between > 405 and 415. > > Don't get me wrong. If guard, middle or exit all relays are important. > But it's a little strange. I don't think the sbws bandwidth authorities are causing the issue that you're seeing with your consensus weight or flags. The consensus is based on majority votes, and 2/6 bandwidth authorities or 2/9 authorities are not a majority. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
Hi everybody Am 2019-08-24 um 11:38 AM schrieb Toralf Förster: On 8/19/19 4:56 AM, teor wrote: Yes, changing other relays' bandwidths can affect the Guard flag, because Guard is given to the fastest, most stable relays. I'm not convinced that this is the culprit for the mentioned relay [1]. I found another relay [2] where at least 4 of the 9 authorities doesn't set the "Running" flag, which is needed for "Guard", right? That relay has a reasonable bw value to (23,000 , FWIW the value for [1] is about 90,000). So now I do wonder why the Running flag is lost after a year. [1] https://consensus-health.torproject.org/consensus-health-2019-08-24-07-00.html#509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6 [3] https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA I have a similar experience like Toralf. Since a week all my relays (but one) are middle relays. Which is fine because they push good traffic. All are measured by maatu, gabel, moria1 and farav. But only one is measured by longc and bastet. [1] Why is that? My understanding is six of nine authorities measure bandwitdh. I can download bandwidth files from all six from a _non_ measured server [2], so connection is given. But I see about 2.4MB doc size from the ones working for me and 4MB from the ones not working. Any clue what is the difference between those? My family is [3]. The good relay is 402 and the `bad´ ones are between 405 and 415. Don't get me wrong. If guard, middle or exit all relays are important. But it's a little strange. PS: dannenberg has Missing Signature [1] https://consensus-health.torproject.org/consensus-health.html [2] CE47F0356D86CF0A1A2008D97623216D560FB0A8 [3] https://metrics.torproject.org/rs.html#search/family:1AE039EE0B11DB79E4B4B29CBA9F752864A0259E -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] AvoidDiskWrites
> On 25 Aug 2019, at 21:45, Roger Dingledine wrote: > > And as a last note, I think it's been a long time since anybody tuned > AvoidDiskWrites to have actually reasonable parameters. I wrote it long > ago as a potential feature that somebody might find useful, and I just > picked some numbers that seemed plausible back in 2007. Since 2007, we've seen some significant technological changes: * More devices with batteries * More devices with SSDs * Better disk forensics techniques So it might be a good idea to change the client default to AvoidDiskWrites 1: https://trac.torproject.org/projects/tor/ticket/31507 T___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] AvoidDiskWrites
On Sat, Aug 24, 2019 at 06:36:20AM +0200, Michael Gerstacker wrote:
> I would like to understand what Tor is NOT writing to disk anymore if set
> to 1 or what Tor IS writing to disk if set to 0 and if changing that have
> any effect for Tor users.
> As a relay operator i couldnt really see any difference enabled or not.
It doesn't make Tor write different things to disk. Rather, it controls
how often Tor checkpoints its files to disk.
For example, your 'state' file (in your DataDirectory) is where Tor keeps
track of some of its local statistics and configuration, like how many
bytes it has spent from your AccountingMax, and it writes that file to
disk periodically in case something goes wrong (e.g. the computer turns
off suddenly).
Tor doesn't write the file immediately after a change, though, because
often changes come in batches, so it waits a little while before writing
it. When AvoidDiskWrites is set, it waits longer. So the same files get
written to disk eventually, but there's a higher risk of losing some
changes if something goes wrong before it gets around to writing out
the file.
As for what files Tor writes, we tried to cover that in the "FILES"
section at the end of the Tor man page ("man tor"). That documentation
might be out of date though, so if you notice anything else, please do
file a ticket.
And as a last note, I think it's been a long time since anybody tuned
AvoidDiskWrites to have actually reasonable parameters. I wrote it long
ago as a potential feature that somebody might find useful, and I just
picked some numbers that seemed plausible back in 2007.
--Roger
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
On 8/25/19 10:36 AM, Roger Dingledine wrote: > So my current thought is intermittent overload, or perhaps some sort > of "rate limiting via iptables" firewall. Hhm, at least for the "zwiebeltoralf[2]" there's no rate limiting or any firewall rules rate limiting it. But I do have ~80 MByte/sec load at this 1 GBit/s network card (2 relays running at the same ip address), so maybe this is (but why suddenly?) the problem. The load were in the past always > 60 MByte/sec combined for both relays. Well, I do wonder if the latest vanilla kernel version (I do follow the stable series of Greg Kroah-Hartmann) has an impact here? Again, so a local problem with the system or the provider I do assume. -- Toralf PGP C4EACDDE 0076E94E signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] AvoidDiskWrites
Hi Torproject, i think about enabling AvoidDiskWrites 1 on all my relays and not only on my Pi because the prices for the VPS are anyway cheap as f*ck so i think saving the provider a few disk writes is a nice deal. In the manual it is described as: *AvoidDiskWrites* *0*|*1* If non-zero, try to write to disk less frequently than we would otherwise. This is useful when running on flash memory or other media that support only a limited number of writes. (Default: 0) ... which is not a very informative description on how it changes the behavior of Tor. I didnt found any more explanation about it. I would like to understand what Tor is NOT writing to disk anymore if set to 1 or what Tor IS writing to disk if set to 0 and if changing that have any effect for Tor users. As a relay operator i couldnt really see any difference enabled or not. Kind regards ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Measuring the Accuracy of Tor Relays' Advertised Bandwidths
On Sun, Aug 25, 2019 at 10:24:21AM +1000, teor wrote: > > I found another relay [2] where at least 4 of the 9 authorities doesn't set > > the "Running" flag, which is needed for "Guard", right? Correct, I believe we don't vote the Guard flag if we are not voting the Running flag: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2598 I think that is because of the definition of 'active'. > > [3] > > https://consensus-health.torproject.org/consensus-health-2019-08-24-08-00.html#0CDCFB0B6E1500E57BDD7F240543EBAEF81C11CA > > At the moment, 6/9 authorities can't reach this relay. Same possibilities. moria1 can reach this relay, but earlier today, and also at this moment, dizum is being listed as unable to reach the relay. But I checked with dizum's operator earlier today and he could reach that IP:orport via telnet. So my current thought is intermittent overload, or perhaps some sort of "rate limiting via iptables" firewall. (It doesn't look like ipv6 reachability questions should apply here, because I think this relay isn't offering ipv6.) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
