[tor-relays] How to reduce tor CPU load on a single bridge?

Fri Mar 4 07:21:38 UTC 2022

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

-------------- 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/20220304/b1356fc6/attachment.sig>