[tor-relays] How to reduce tor CPU load on a single bridge?
Georg Koppen
gk at torproject.org
Mon Mar 7 09:15:24 UTC 2022
Gary C. New via tor-relays:
> Georg,
>>> Are there any "Issues" submitted for a similar change to Concensus Weight and Relay Probability to Tor Metrics on Onionoo? It appears these values are still only being reported for a Single Tor Node.
>
>> Hrm, good question. I don't think so and I am not sure yet, whether we
> should make such a change.
>
> Do you mind me asking what the reluctance might be to extending Tor Metrics to include correct reporting of Concensus Weight and Relay Probability for Loadbalanced Tor Relays? It would provide a more accurate assessment of Tor Network Resources and assist DirectoryAuthorities in making more informed decisions.
There is no real reluctance here on my side. It's just that I don't have
thought about yet what kind of extra work it would involve and what the
pros and cons of that actually are.
> I would be happy to open an "Issue" on the topic for official Request For Consideration.
Yes, please do. I think
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search is
a good project to file the issue and have some discussion and context in
and then we can open child tickets in other projects in case we need to
do work somewhere else as well to make your request happen.
> Thank you and the Tor Metrics Team for all that you do in improving the Tor Network.
You are welcome! Thanks for running relays.
Georg
> Respectfully,
>
> Gary—
> This Message Originated by the Sun.
> iBigBlue 63W Solar Array (~12 Hour Charge)
> + 2 x Charmast 26800mAh Power Banks
> = iPhone XS Max 512GB (~2 Weeks Charged)
>
> On Friday, March 4, 2022, 12:22:06 AM MST, Georg Koppen <gk at torproject.org> wrote:
>
> Gary C. New via tor-relays:
>> Georg,
>> Yes! That is precisely it!
>> Please know that the change appears to be working with my loadbalanced Tor Relay deployment as well.
>> Are there any "Issues" submitted for a similar change to Concensus Weight and Relay Probability to Tor Metrics on Onionoo? It appears these values are still only being reported for a Single Tor Node.
>
> Hrm, good question. I don't think so and I am not sure yet, whether we
> should make such a change.
>
>> A BIG Thank You to the Tor Metrics Team for the Issue-40022 implementation.
>
> You are welcome. It seems, though, the implementation was not correct.
> We therefore reverted it for now. However, we are on it. :)
>
> Georg
>
>> Respectfully,
>>
>> Gary—
>> This Message Originated by the Sun.
>> iBigBlue 63W Solar Array (~12 Hour Charge)
>> + 2 x Charmast 26800mAh Power Banks
>> = iPhone XS Max 512GB (~2 Weeks Charged)
>>
>> On Thursday, March 3, 2022, 1:28:12 PM MST, Georg Koppen <gk at torproject.org> wrote:
>>
>> Gary C. New via tor-relays:
>>> David,
>>> Has Tor Metrics implemented your RFC related to Written Bytes per Second and Read Bytes per Second on Onionoo?
>>
>> That's probably
>>
>> https://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/40022
>>
>> , no?
>>
>> Georg
>>
>>> As of the 27th of February, I've noticed a change in reporting that accurately reflects the aggregate of my Tor Relay Nodes opposed to the previously reported Single Tor Node. Are you seeing a similar change for snowflake.torproject.org?
>>> Additionally, other than the hourly stacktrace errors in the syslog, the secure_onion_key workaround seems to be working well without any ill side-effects. I've been able to operate with the same secure_onion_key for close to 5 weeks, now. Have you run into any issues?
>>> Thank you for your response.
>>> Respectfully,
>>>
>>> Gary—
>>> This Message Originated by the Sun.
>>> iBigBlue 63W Solar Array (~12 Hour Charge)
>>> + 2 x Charmast 26800mAh Power Banks
>>> = iPhone XS Max 512GB (~2 Weeks Charged)
>>>
>>> On Tuesday, February 8, 2022, 11:49:47 PM MST, Gary C. New via tor-relays <tor-relays at lists.torproject.org> wrote:
>>>
>>> David,
>>> Excellent Documentation and References!
>>> I hope the proposed RFC's (auth, key, and metrics) for loadbalanced Tor topologies are seriously considered and implemented by Tor Core and Tor Metrics.
>>> Great Work!
>>> Respectfully,
>>>
>>> Gary—
>>> This Message Originated by the Sun.
>>> iBigBlue 63W Solar Array (~12 Hour Charge)
>>> + 2 x Charmast 26800mAh Power Banks
>>> = iPhone XS Max 512GB (~2 Weeks Charged)
>>>
>>> On Tuesday, February 8, 2022, 10:02:53 AM MST, David Fifield <david at bamsoftware.com> wrote:
>>>
>>> The load-balanced Snowflake bridge is running in production since
>>> 2022-01-31. Thanks Roger, Gary, Roman for your input.
>>>
>>> Hopefully reproducible installation instructions:
>>> https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=6de6facbb0fd047de978a561213c59224511445f
>>> Observations since:
>>> https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40095#note_2774428
>>>
>>> Metrics graphs are currently confused by multiple instances of tor
>>> uploading descriptors under the same fingerprint. Particularly in the
>>> interval between 2022-01-25 and 2022-02-03, when a production bridge and
>>> staging bridge were running in parallel, with four instances being used
>>> and another four being mostly unused.
>>> https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F
>>> https://metrics.torproject.org/userstats-bridge-transport.html?start=2021-11-10&end=2022-02-08&transport=snowflake
>>> Since 2022-02-03, it appears that Metrics is showing only one of the
>>> four running instances per day. Because all four instances are about
>>> equally used (as if load balanced, go figure), the values on the graph
>>> are 1/4 what they should be. The reported bandwidth of 5 MB/s is
>>> actually 20 MB/s, and the 2500 clients are actually 10000. All the
>>> necessary data are present in Collector, it's just a question of data
>>> processing. I opened an issue for the Metrics graphs, where you can also
>>> see some manually made graphs that are closer to the true values.
>>> https://bugs.torproject.org/tpo/network-health/metrics/onionoo/40022
>>>
>>> I started a thread on tor-dev about the issues of onion key rotation and
>>> ExtORPort authentication.
>>> https://lists.torproject.org/pipermail/tor-dev/2022-February/thread.html
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>>>
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20220307/0f0f5ff8/attachment.sig>
More information about the tor-relays
mailing list