[tor-relays] relay lost most of its consensus weight

[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 at 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 at 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/F46C312E279185364F46EA06C58F7925280911E2
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> tor-relays mailing list
>>>>
>>>> tor-relays at 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 at 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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160914/c6d61dd7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20160914/c6d61dd7/attachment.sig>