Hello.
Did anyone noticed unusual connection count spikes for their relays?
My relay encountered several ~1k spikes with rise time ~= 10 minutes:
https://imgur.com/a/6JvB7gp
Maybe it is someone trying to fool anti-DDoS protection?
-- Vort
___
tor
nces mean, but, maybe, this stats can
help to distinguish the sources of overload (or prove that they
are the same).
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> Each onion service has six relays each day that serve as the place for
> fetching its onion descriptor, and some onion services are super popular
Exactly after 24 hours connection count dropped to 2200 and
"assign_to_cpuworker failed" error stopped appearing.
T
assign_to_cpuworker failed. Ignoring.
...
Jul 27 19:09:11.000 [warn] assign_to_cpuworker failed. Ignoring.
...
Jul 27 20:10:11.000 [warn] assign_to_cpuworker failed. Ignoring.
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://l
uit handshake stats since last time: 5523/5523
TAP, 222378/222432 NTor.
Also there are too much "[warn] assign_to_cpuworker failed. Ignoring." lines in
the logs.
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproj
have identical spikes (I guess they belong to
NlaSvc system service).
Do anyone know why this can happen?
Here is the screenshot:
https://s8.hostingkartinok.com/uploads/images/2017/07/6fe01ab8601548f95ba47602de0f3739.png
-- Vort
___
tor-relays mailing
s, 10 MiB/s, which are possible with
my connection.
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
st program and launch it from my location.
Maybe different approach will give different results.
I am still sure, that low weight estimate is hiding many fast relays.
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.
ok.com/uploads/images/2017/06/7768344880b81c80442aaa383550e117.png
And there no effect can be seen at this scale.
(Don't know if this analysis can help, but, anyway, here it is)
-- Vort
___
tor-relays mailing list
tor-relays@lists.torprojec
gt; * increasing the minimum bandwidth authority file size
> * making an automatic process to un-stick stuck relays
> * getting more bandwidth authorities in more places
> * re-writing the bandwidth authority code
I saw some changes and was wondering if they are random or not.
Thanks for
: 404 KiB/s
faravahar : 141 KiB/s
> Ok, the next limit will be the observed bandwidth.
After the yesterday test #5, observed bandwidth changed to 1.12 MiB/s.
> You need to be patient.
That's not a problem if I know that something will def
rks/basic-min
...
Single Stream Bandwidth: 43.52 MBytes/s
Overall tor Bandwidth: 174.07 MBytes/s
> It might not be me that helps you.
> So please talk to the list when you write back.
But no one else shown the interest on answering to this topic.
-- Vort
Hello, teor.
Is it worth to wait till you have time to investigate stuck relays problem?
-- Vort
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
formation.
This can help to investigate problem.
There are also the possibility of doing manual checks.
Which then can be compared to debug logs of BwAuth.
Maybe my approach is not so good and you will choose another.
But, anyway, thanks for working on this problem.
-- Vort
___
I don't want to lose the state, which reproduces the bug.
> If it is better, then the relay was put in a low bucket, and was stuck
> in that bucket. This can happen at random, or if the relay was slow in
> the past.
My relay was never slow.
Possibility of such random stuck is a thi
that weight histogram have no equivalent spike.
Here is another histogram.
https://s8.hostingkartinok.com/uploads/images/2017/06/749e7e3be806c22f3dd5c0e9586304ab.png
(x, y and colors are the same)
Just filtered relays so theirs Advertised Bandwidth is in range
110..135.
I wouldn't s
and 20 MBits.
> I don't understand what you mean here. The advertised bandwidth is in
> kilobytes per second, and the consensus weight is dimensionless (but
> scaled from kilobytes per second).
> Can you point out the lines you mean?
Look at the yellow spike at x
correctly. Similarly, high-speed relays have higher weight
than needed.
If all 0-50KiB-estimated relays are capable of serving at least
100 KiB, fixing this problem will lead to ~ (100-25)*1082 = 82 MiB/s
increase of network bandwidth. But they have even more potential,
I think.
18 matches
Mail list logo
