I did another scan, this time with 3 seconds between each circuit
build and set the max connections to 50 with similar results as
yesterday:
9354 failure
2 timeout
544 success
most of the circuit build failures happened in under a second:
echo "select (end_time - start_time) / 1000 as duration
Gisle Vanem transcribed 1.0K bytes:
> I wrote:
>
> >Seems bench.c uses some mutex which is not initialised
> >with 'tor_mutex_init()'. I fail to see which that should
> >be.
>
> With this patch, I no longer get that crash:
>
> --- a/bench.c 2018-01-25 20:15:13
> +++ b/bench.c 2018-03-13 12:38:09
I wrote:
Seems bench.c uses some mutex which is not initialised
with 'tor_mutex_init()'. I fail to see which that should
be.
With this patch, I no longer get that crash:
--- a/bench.c 2018-01-25 20:15:13
+++ b/bench.c 2018-03-13 12:38:09
@@ -713,6 +713,8 @@
printf("Couldn't seed RNG; exi
teor writes:
> And where did you scan *from*?
> (It's hard to interpret the results without the latency and quality of your
> client connection.)
If I correctly understand what David's scanner is doing, so long as "a"
connection can make it to the first hop properly any other failure is
"the Tor
dawuud writes:
> Yes I am sure it failed. It would be cool if txtorcon can expose the
> 'reason' but I think that it cannot. I suppose it will show up in the
> tor log file if I set it to debug logging.
txtorcon does expose both the 'reason' and the 'remote_reason' flags
returned by the failure
dawuud writes:
>> your IP address. Try to stay under 50 connections to the same
>> relay from your IP address.
> hmm OK. I can limit the number of concurrenct circuits that are being
> built but I do not believe that txtorcon let's me control the number
> of "connections" that little-t tor makes
> And where did you scan *from*?
> (It's hard to interpret the results without the latency and quality of your
> client connection.)
It turns out I am recording circuit build latency. It is unclear to
me exactly what you'd like me to do with this information however
here's a some silly queries:
> Other questions I'd want to investigate:
>
> (A) Are the failures consistent, or intermittent? That is, does a
> failed link always fail, or only sometimes?
Yes this is what our new testing methodology should support.
My current scanner is not sufficient. We want to improve it.
> (B) Are you
> How much worse?
During the Montreal tor dev meeting I counted 1947 circuit build failures.
https://lists.torproject.org/pipermail/tor-project/2017-October/001492.html
> And where did you scan *from*?
I scaned from a server in the Netherlands.
> (It's hard to interpret the results without the
There is a crash in bench.exe. Running 'cdb -c g bench.exe':
ntdll!RtlpWaitOnCriticalSection+0x6b:
77a9cfd6 ff4014 inc dword ptr [eax+14h] ds:002b:0014=
ChildEBP RetAddr
0137f750 77aba38a ntdll!RtlpWaitOnCriticalSection+0x6b
0137f770 77aba259 ntdll!RtlpEnterCriticalSect
On Tue, Mar 13, 2018 at 02:55:12AM +, dawuud wrote:
> Out of 9900 possible two hop tor circuits among the top 100 tor relays
> only 935 circuit builds have succeeded. This is way worse than the last
> time I sent a report 6 months ago during the Montreal tor dev meeting.
The next step here wou
> On 13 Mar 2018, at 03:55, dawuud wrote:
>
> Out of 9900 possible two hop tor circuits among the top 100 tor relays
> only 935 circuit builds have succeeded. This is way worse than the last
> time I sent a report 6 months ago during the Montreal tor dev meeting.
How much worse?
And where did
12 matches
Mail list logo
