Hi Alexander,
I am a customer of Wedos Internet, and originally ordered this virtual
machine back in 2014, as far as I know no hardware updates to the
hypervisor were ever performed, so it's likely some older Intel Xeon
(clocked at 2133.408MHz), guess with that information you can find the
exact C
It sure is a problem for those on virtualized machines with only a single core.
As far as offloading to a different worker thread goes, it should be
very easy to implement code wise, Tor already does off-load some
crypto stuff to a different thread when NumCPU's is set / detected
appropriately.
2
On 2020/05/19 15:59, William Kane wrote:
> Right after, diffs were compressed with zstd and lzma, causing the CPU
> usage to spike.
Thank you for debugging this William.
Tor behaves in the way it is designed to here. Tor uses a number of
worker threads to handle compression (and a couple of other
To me it sounds like there isn't actually a problem. This is the way Tor
works now (now == since consensus diffs were added). It's unfortunate
that Tor isn't more multithreaded, so much happens in the same main
loop, and client throughput is momentarily impacted, but that's the way
it is and there
Another thing, from the change-log:
- Update the message logged on relays when DirCache is disabled.
Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.
If I understand this correctly, my relay would no longer be a Guard if
I choos
Okay, so your suspicion was just confirmed:
consdiffmgr_rescan_flavor_(): The most recent ns consensus is
valid-after 2020-05-19T15:00:00. We have diffs to this consensus for
0/25 older ns consensuses. Generating diffs for the other 25.
Right after, diffs were compressed with zstd and lzma, causi
Dear Alexander,
I have added 'Log [dirserv]info notice stdout' to my configuration and
will be monitoring the system closely.
Tor was also upgraded to version 0.4.3.5, and the linux kernel was
upgraded to version 5.6.13 but I do not think this will change
anything.
Expect a follow-up within the
Not at fixed intervals*, sorry for the typo.
William
2020-05-17 18:20 GMT, William Kane :
> Hi there,
>
> I am the operator of the following relay:
>
> https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
>
> The relay is running on my Arch Linux server running
Hi there,
I am the operator of the following relay:
https://metrics.torproject.org/rs.html#details/47E1157F7DA6DF80EC00D745D73ACD7B0A380BCF
The relay is running on my Arch Linux server running kernel version 5.6.11.
This is my tor configuration file:
ORPort 37.157.195.83:38619
ORPort [2a02:2b8
Hello,
On 2020/05/17 18:20, William Kane wrote:
> Occasionally, the CPU usage hit's 100%, and the maximum throughput
> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
> randomly and not a fixed intervals which makes it pretty hard to
> profile.
One of the subsystem's that I can
10 matches
Mail list logo
