relay lost most of its consensus weight
Hi, I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration? Thanks for your help! https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration?
It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.) Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.) Am 13.09.2016 um 10:37 schrieb teor:
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration? It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
--- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.)
I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time? Tim
Am 13.09.2016 um 10:37 schrieb teor:
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration?
It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. www.avast.com
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements? The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine. Am 14.09.2016 um 02:10 schrieb teor:
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.) I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
Am 13.09.2016 um 10:37 schrieb teor:
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration?
It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. www.avast.com
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Addendum: Did a bit of research (or rather checked some random relays on Atlas). It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all. Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.) I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
Am 13.09.2016 um 10:37 schrieb teor:
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration?
It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. www.avast.com
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 14 Sep 2016, at 11:34, jensm1 <jensm1@bbjh.de> wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all.
I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate. But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820 https://collector.torproject.org/recent/relay-descriptors/votes/ The consensus has your weight as the low-median of these values: 394. https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-0... When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight. The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks). It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap? Tim
Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.)
I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
Am 13.09.2016 um 10:37 schrieb teor:
On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de>
wrote:
Hi,
I just realised that my relay 'itwasntme' lost most of its consensus weight yesterday morning. The relay is only three weeks old, but it was finally picking up some traffic, which now is gone again. What could be the cause for this? Is there a problem with my relay or configuration?
It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
Thanks for your help!
https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911...
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
www.avast.com
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
On 13 September 2016 at 20:34, jensm1 <jensm1@bbjh.de> wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes.
So it might be BWAuth related after all.
It's possible! (Likely even.) If you want to try and get a slightly deeper of level of understanding, I can suggest some things, but the general recommendation of "wait a few weeks" is still the main action to take. We're sorry for the dip, and we greatly appreciate you sticking it out while the network catches up with what you're able to contribute. If you want to investigate I would grab the recent votes and consensuses from collector (https://collector.torproject.org/). Look at the votes by the bwauths (maatuska, gabelmoo, moria1, Faravahar, and longclaw) and see how they measure you. Look also for when the figure changes (it should be every 2-4 days.) Look at what figure winds up in the consensus and confirm it dips with your measured traffic dip. You can watch these figures to see when you can expect your traffic to rise. And, if you're the truly pioneering sort, you could investigate integrating this type of measurement/analysis into Atlas or a similar tool. -tom
I apologize for what is probably bad form in replying to an older thread that has sort of fallen off, but I've been trying to figure out why I just can't seem to get any consensus weight on our middle relay (ByTORAndTheSnowDog). We moved in May to another city and have a different internet provider now. We had gigabit symmetrical internet at the last place and I *get* that a drop in bandwidth and consensus should be expected, but our internet bandwidth here is not that bad. 300mbit down/20mbit up. Consensus weight is mostly a function of your upstream bandwidth, right? Do the bandwidth auth testers ever "get it wrong"? I'm not sure where to look to see what kind of bandwidth is being measured from us. It seems unlikely however that we are only able to push out the paltry rates I see in our atlas entries. These are the rate limiting-related settings I'm running in torrc: RelayBandwidthRate 2300 KB RelayBandwidthBurst 2500 KB BandwidthRate 2300 KB BandwidthBurst 2500 KB Not using any MaxAdvertisedBandwidth settings anymore -- I commented them out a week or so ago at last restart after reading that you shouldn't set these if you are looking to get more traffic. The most likely explanation is, we just don't have the upstream bandwidth we think we do. But I consistently get speedtest.net upstream tests above 20 megabits/sec to different speedtest sites around eastern US "hubs" (atlanta, virginia, ie, places that have bandwidth). So I don't understand. Thanks On 09/13/2016 09:38 PM, teor wrote:
On 14 Sep 2016, at 11:34, jensm1 <jensm1@bbjh.de> wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all. I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate.
But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820 https://collector.torproject.org/recent/relay-descriptors/votes/
The consensus has your weight as the low-median of these values: 394. https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-0...
When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight.
The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks).
It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap?
Tim
Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.)
I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
Am 13.09.2016 um 10:37 schrieb teor:
> On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> > > wrote: > > Hi, > > I just realised that my relay 'itwasntme' lost most of its consensus > weight yesterday morning. The relay is only three weeks old, but it was > finally picking up some traffic, which now is gone again. > What could be the cause for this? Is there a problem with my relay or > configuration? > > It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.)
Tim
> Thanks for your help! > > > > > https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911... > > > > > _______________________________________________ > tor-relays mailing list > > > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
www.avast.com
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 14 Oct 2016, at 22:23, Tor User <toruser@lvwnet.com> wrote:
I apologize for what is probably bad form in replying to an older thread that has sort of fallen off, but I've been trying to figure out why I just can't seem to get any consensus weight on our middle relay (ByTORAndTheSnowDog).
I prefer context, and I prefer knowing you've read the old thread.
We moved in May to another city and have a different internet provider now. We had gigabit symmetrical internet at the last place and I *get* that a drop in bandwidth and consensus should be expected, but our internet bandwidth here is not that bad. 300mbit down/20mbit up.
Consensus weight is mostly a function of your upstream bandwidth, right?
Not quite, it's a function of your bandwidth to the bandwidth authorities, your latency to the bandwidth authorities, and the actual utilisation of your relay. The minimum of your downstream and upstream bandwidth can be used as a first approximation.
Do the bandwidth auth testers ever "get it wrong"?
Oh yes, they are consistently inaccurate, typically on a geographical or network basis. And they are somewhat random for individual servers over short timeframes. (The bandwidth authorities are in North America and Europe on 5 particular networks. If you're a long way from those networks, your measurements are lower than other servers with similar capacity.) We're working on some improvements right now.
I'm not sure where to look to see what kind of bandwidth is being measured from us.
https://collector.torproject.org/recent/relay-descriptors/votes/ w Bandwidth=344 Measured=19 w Bandwidth=344 Measured=49 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=232 (low-)median: 50 We could make this easier for relay operators by showing the measured bandwidth in consensus health. https://trac.torproject.org/projects/tor/ticket/20372
It seems unlikely however that we are only able to push out the paltry rates I see in our atlas entries.
Your relay's observed bandwidth is exactly the rate seen in your atlas entry: http://24.74.79.53:9030/tor/server/authority https://atlas.torproject.org/#details/B735643D239170947669269A78F8478EC53432...
These are the rate limiting-related settings I'm running in torrc:
RelayBandwidthRate 2300 KB RelayBandwidthBurst 2500 KB
BandwidthRate 2300 KB BandwidthBurst 2500 KB
Not using any MaxAdvertisedBandwidth settings anymore -- I commented them out a week or so ago at last restart after reading that you shouldn't set these if you are looking to get more traffic.
You can reload tor's config using: kill -HUP `cat /var/run/tor.pid` Or the equivalent service command on your OS/distribution. This avoids a restart.
The most likely explanation is, we just don't have the upstream bandwidth we think we do.
It would certainly seem that way. Or you have bad upstream connectivity to some ports or IP addresses. Or your provider limits the number of simultaneous connections you can make. Or your provider rate-limits your connections. Or your provider drops long-lived connections.
But I consistently get speedtest.net upstream tests above 20 megabits/sec to different speedtest sites around eastern US "hubs" (atlanta, virginia, ie, places that have bandwidth). So I don't understand.
I would say "ask your provider", but I doubt they'll be sympathetic. Perhaps finding another provider would help? Or a cheap VPS? Tim
Thanks
On 09/13/2016 09:38 PM, teor wrote:
On 14 Sep 2016, at 11:34, jensm1 <jensm1@bbjh.de> wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all.
I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate.
But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820
https://collector.torproject.org/recent/relay-descriptors/votes/
The consensus has your weight as the low-median of these values: 394.
https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-0...
When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight.
The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks).
It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap?
Tim
Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de>
wrote:
I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? (Not complaining, just genuinely curious.)
I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
Am 13.09.2016 um 10:37 schrieb teor:
>> On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> >> >> >> wrote: >> >> Hi, >> >> I just realised that my relay 'itwasntme' lost most of its consensus >> weight yesterday morning. The relay is only three weeks old, but it was >> finally picking up some traffic, which now is gone again. >> What could be the cause for this? Is there a problem with my relay or >> configuration? >> >> >> > It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. > We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. > But in any case, wait a week or two, and it will be back. > (If not, please let us know.) > > Tim > > > > >> Thanks for your help! >> >> >> >> >> >> https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911... >> >> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> >> >> >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > > > > > > > > > > _______________________________________________ > tor-relays mailing list > > > > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
www.avast.com
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------
Tim thank you for the reply. Lots of good info in there. It is not good news for me but at least now I understand. The main problem is likely my ISP (TWC). Traceroutes are typical for TWC, you have to go through at least 5-7 hops going anywhere before you get to leave their network.... This is the same tor box we had at the other place when we had much much better bandwidth measurement on our relay - reported bandwidth was a lot closer to what I had the limits set to in torrc. Google fiber is in mid-deployment now in our neck of the woods but I think we would probably have to move to be able to get it. The place we are now has a contract with TWC and... it wouldn't surprise me if they signed a long term contract, given the (ahem) quality of judgement we have seen demonstrated by management since we have been here. Brand new apartment complex that is falling apart, literally. Thanks again. On 10/15/2016 09:08 PM, teor wrote:
On 14 Oct 2016, at 22:23, Tor User <toruser@lvwnet.com> wrote:
I apologize for what is probably bad form in replying to an older thread that has sort of fallen off, but I've been trying to figure out why I just can't seem to get any consensus weight on our middle relay (ByTORAndTheSnowDog). I prefer context, and I prefer knowing you've read the old thread.
We moved in May to another city and have a different internet provider now. We had gigabit symmetrical internet at the last place and I *get* that a drop in bandwidth and consensus should be expected, but our internet bandwidth here is not that bad. 300mbit down/20mbit up.
Consensus weight is mostly a function of your upstream bandwidth, right? Not quite, it's a function of your bandwidth to the bandwidth authorities, your latency to the bandwidth authorities, and the actual utilisation of your relay. The minimum of your downstream and upstream bandwidth can be used as a first approximation.
Do the bandwidth auth testers ever "get it wrong"? Oh yes, they are consistently inaccurate, typically on a geographical or network basis. And they are somewhat random for individual servers over short timeframes.
(The bandwidth authorities are in North America and Europe on 5 particular networks. If you're a long way from those networks, your measurements are lower than other servers with similar capacity.)
We're working on some improvements right now.
I'm not sure where to look to see what kind of bandwidth is being measured from us. https://collector.torproject.org/recent/relay-descriptors/votes/
w Bandwidth=344 Measured=19 w Bandwidth=344 Measured=49 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=232
(low-)median: 50
We could make this easier for relay operators by showing the measured bandwidth in consensus health. https://trac.torproject.org/projects/tor/ticket/20372
It seems unlikely however that we are only able to push out the paltry rates I see in our atlas entries. Your relay's observed bandwidth is exactly the rate seen in your atlas entry: http://24.74.79.53:9030/tor/server/authority https://atlas.torproject.org/#details/B735643D239170947669269A78F8478EC53432...
These are the rate limiting-related settings I'm running in torrc:
RelayBandwidthRate 2300 KB RelayBandwidthBurst 2500 KB
BandwidthRate 2300 KB BandwidthBurst 2500 KB
Not using any MaxAdvertisedBandwidth settings anymore -- I commented them out a week or so ago at last restart after reading that you shouldn't set these if you are looking to get more traffic. You can reload tor's config using: kill -HUP `cat /var/run/tor.pid`
Or the equivalent service command on your OS/distribution. This avoids a restart.
The most likely explanation is, we just don't have the upstream bandwidth we think we do. It would certainly seem that way. Or you have bad upstream connectivity to some ports or IP addresses. Or your provider limits the number of simultaneous connections you can make. Or your provider rate-limits your connections. Or your provider drops long-lived connections.
But I consistently get speedtest.net upstream tests above 20 megabits/sec to different speedtest sites around eastern US "hubs" (atlanta, virginia, ie, places that have bandwidth). So I don't understand. I would say "ask your provider", but I doubt they'll be sympathetic.
Perhaps finding another provider would help? Or a cheap VPS?
Tim
Thanks
On 09/13/2016 09:38 PM, teor wrote:
On 14 Sep 2016, at 11:34, jensm1 <jensm1@bbjh.de> wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all.
I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate.
But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820
https://collector.torproject.org/recent/relay-descriptors/votes/
The consensus has your weight as the low-median of these values: 394.
https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-0...
When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight.
The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks).
It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap?
Tim
Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
> On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> > > wrote: > > I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? > (Not complaining, just genuinely curious.) > > I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time?
Tim
> Am 13.09.2016 um 10:37 schrieb teor: > > >>> On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> >>> >>> >>> wrote: >>> >>> Hi, >>> >>> I just realised that my relay 'itwasntme' lost most of its consensus >>> weight yesterday morning. The relay is only three weeks old, but it was >>> finally picking up some traffic, which now is gone again. >>> What could be the cause for this? Is there a problem with my relay or >>> configuration? >>> >>> >>> >> It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. >> We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. >> But in any case, wait a week or two, and it will be back. >> (If not, please let us know.) >> >> Tim >> >> >> >> >>> Thanks for your help! >>> >>> >>> >>> >>> >>> https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911... >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> >>> >>> >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> >> >> >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. > > > www.avast.com > > > > > _______________________________________________ > tor-relays mailing list > > > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On 19 Oct. 2016, at 21:47, Tor User <toruser@lvwnet.com> wrote:
Tim thank you for the reply. Lots of good info in there. It is not good news for me but at least now I understand. The main problem is likely my ISP (TWC). Traceroutes are typical for TWC, you have to go through at least 5-7 hops going anywhere before you get to leave their network.... This is the same tor box we had at the other place when we had much much better bandwidth measurement on our relay - reported bandwidth was a lot closer to what I had the limits set to in torrc.
Google fiber is in mid-deployment now in our neck of the woods but I think we would probably have to move to be able to get it. The place we are now has a contract with TWC and... it wouldn't surprise me if they signed a long term contract, given the (ahem) quality of judgement we have seen demonstrated by management since we have been here. Brand new apartment complex that is falling apart, literally.
For what it's worth, another relay operator on TWC was complaining about low bandwidth measurements today on IRC. Looks like the provider might be the common factor. Sorry we can't do much to help. Tim
Thanks again.
On 10/15/2016 09:08 PM, teor wrote:
On 14 Oct 2016, at 22:23, Tor User <toruser@lvwnet.com> wrote:
I apologize for what is probably bad form in replying to an older thread that has sort of fallen off, but I've been trying to figure out why I just can't seem to get any consensus weight on our middle relay (ByTORAndTheSnowDog).
I prefer context, and I prefer knowing you've read the old thread.
We moved in May to another city and have a different internet provider now. We had gigabit symmetrical internet at the last place and I *get* that a drop in bandwidth and consensus should be expected, but our internet bandwidth here is not that bad. 300mbit down/20mbit up.
Consensus weight is mostly a function of your upstream bandwidth, right?
Not quite, it's a function of your bandwidth to the bandwidth authorities, your latency to the bandwidth authorities, and the actual utilisation of your relay. The minimum of your downstream and upstream bandwidth can be used as a first approximation.
Do the bandwidth auth testers ever "get it wrong"?
Oh yes, they are consistently inaccurate, typically on a geographical or network basis. And they are somewhat random for individual servers over short timeframes.
(The bandwidth authorities are in North America and Europe on 5 particular networks. If you're a long way from those networks, your measurements are lower than other servers with similar capacity.)
We're working on some improvements right now.
I'm not sure where to look to see what kind of bandwidth is being measured from us.
https://collector.torproject.org/recent/relay-descriptors/votes/
w Bandwidth=344 Measured=19 w Bandwidth=344 Measured=49 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=232
(low-)median: 50
We could make this easier for relay operators by showing the measured bandwidth in consensus health.
https://trac.torproject.org/projects/tor/ticket/20372
It seems unlikely however that we are only able to push out the paltry rates I see in our atlas entries.
Your relay's observed bandwidth is exactly the rate seen in your atlas entry:
http://24.74.79.53:9030/tor/server/authority https://atlas.torproject.org/#details/B735643D239170947669269A78F8478EC53432...
These are the rate limiting-related settings I'm running in torrc:
RelayBandwidthRate 2300 KB RelayBandwidthBurst 2500 KB
BandwidthRate 2300 KB BandwidthBurst 2500 KB
Not using any MaxAdvertisedBandwidth settings anymore -- I commented them out a week or so ago at last restart after reading that you shouldn't set these if you are looking to get more traffic.
You can reload tor's config using: kill -HUP `cat /var/run/tor.pid`
Or the equivalent service command on your OS/distribution. This avoids a restart.
The most likely explanation is, we just don't have the upstream bandwidth we think we do.
It would certainly seem that way. Or you have bad upstream connectivity to some ports or IP addresses. Or your provider limits the number of simultaneous connections you can make. Or your provider rate-limits your connections. Or your provider drops long-lived connections.
But I consistently get speedtest.net upstream tests above 20 megabits/sec to different speedtest sites around eastern US "hubs" (atlanta, virginia, ie, places that have bandwidth). So I don't understand.
I would say "ask your provider", but I doubt they'll be sympathetic.
Perhaps finding another provider would help? Or a cheap VPS?
Tim
Thanks
On 09/13/2016 09:38 PM, teor wrote:
On 14 Sep 2016, at 11:34, jensm1 <jensm1@bbjh.de>
wrote:
Addendum: Did a bit of research (or rather checked some random relays on Atlas).
It seems like it's not only my relay that experienced a significant drop at the same time. I can't find anything obvious these relays have in common. new/old, large/small, guard/exit/middle, different countries and ASes. So it might be BWAuth related after all.
I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate.
But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820
https://collector.torproject.org/recent/relay-descriptors/votes/
The consensus has your weight as the low-median of these values: 394.
https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-0...
When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight.
The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks).
It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap?
Tim
Am 14.09.2016 um 02:49 schrieb jensm1:
That's exactly what baffles me. I didn't make any changes to the relay configuration since updating to 0.2.8.7. I've always had some fluctuations in the Advertised Bandwidth as reported by Atlas, but I assume these are from the BWAuth measurements?
The only thing on my end, that I could imagine, is that the VPS provider changed something in his configuration. But since I don't see any interruption of the servers uptime (neither in Tor, nor in Debian, nor in the VPS control panel), I assume this couldn't be anything drastic like moving the VM to a different host machine.
Am 14.09.2016 um 02:10 schrieb teor:
>> On 13 Sep 2016, at 23:30, jensm1 <jensm1@bbjh.de> >> >> >> wrote: >> >> I last restarted the relay five days ago (update to 0.2.8.7). Can a restart really cause the consensus weight to drop several days later? If it drops within a few hours, I'd get that, but what would delay that response that much? >> (Not complaining, just genuinely curious.) >> >> >> > I'm really not sure - any flag changes should have an impact within an hour. > Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? > Are its ports open to all other relays? > Can it open connections to other relays, regardless of their ports? > Did you make any other config changes at the same time? > > Tim > > > > >> Am 13.09.2016 um 10:37 schrieb teor: >> >> >> >>>> On 13 Sep 2016, at 18:05, jensm1 <jensm1@bbjh.de> >>>> >>>> >>>> >>>> wrote: >>>> >>>> Hi, >>>> >>>> I just realised that my relay 'itwasntme' lost most of its consensus >>>> weight yesterday morning. The relay is only three weeks old, but it was >>>> finally picking up some traffic, which now is gone again. >>>> What could be the cause for this? Is there a problem with my relay or >>>> configuration? >>>> >>>> >>>> >>>> >>> It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. >>> We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. >>> But in any case, wait a week or two, and it will be back. >>> (If not, please let us know.) >>> >>> Tim >>> >>> >>> >>> >>> >>>> Thanks for your help! >>>> >>>> >>>> >>>> >>>> >>>> >>>> https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911... >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> >>>> >>>> >>>> >>>> tor-relays@lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> Tim Wilson-Brown (teor) >>> >>> teor2345 at gmail dot com >>> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >>> ricochet:ekmygaiu4rzgsk6n >>> xmpp: teor at torproject dot org >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> >>> >>> >>> >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. >> >> >> >> www.avast.com >> >> >> >> >> >> _______________________________________________ >> tor-relays mailing list >> >> >> >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > > > > > > > > > > _______________________________________________ > tor-relays mailing list > > > > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------
_______________________________________________ tor-relays mailing list
tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------
participants (4)
-
jensm1 -
teor -
Tom Ritter -
Tor User