subject:"\[tor\-relays\] consensus"

Totally agree with your analysis on this- my concern is that if that were true 
I'd see Nifty's 15 percent drop like a rock too...  and drop from 7-8gbit/sec 
to 2-3gb/sec is weird.

You'd think that I'd be saturated.  I've been running these nodes approximately 
three years and I've never seen this.

John

On Jan 7, 2020, at 11:28, r1610091651  wrote:

?
consensus means what fraction of traffic will pass over your nodes, 
statistically speaking.
Hence a steady drop of consensus value, with no infra changes on your end, 
could also be explained by a stead rise of total bandwidth available: since 
your part is fixed and total grows, your fraction reduces.


Regards

On Tue, 7 Jan 2020 at 14:04, John Ricketts 
mailto:j...@quintex.com>> wrote:
Hello,

I have been watching the consensus weight and bandwidth of all of my 50 exit 
nodes drop consistently over the past few months. I have not made any hardware 
changes in my data center and actual customers have not complained about any 
performance issues.

Operating systems and Tor version are up to date. I'm dedicating a significant 
portion of bandwidth to these nodes - 10gbit/sec.

Am I having issues with the bandwidth authorities?

I'm growing frustrated with my performance to resources ratio, I should be 
doing far better than this.

Please throw ideas at me - open to any ideas.

Thanks!
John
Quintex Alliance Consulting
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

2020-01-07 Thread r1610091651

Consensus & usage are independent
consensus: based on available bandwidth
load: based on usage by tor clients.

if total available bw increases but load doesn't, observed load on a node
will drop.

On Tue, 7 Jan 2020 at 17:27, John Ricketts  wrote:

> I also would like to add to this - if it were just the Tor network
> increasing in size I could see my consensus weight dropping and my
> bandwidth staying the same.  I'm simply not getting the 7-8gbit/sec traffic
> I was.  Truly odd.
>
> -Original Message-
> From: tor-relays  On Behalf Of
> Toralf Förster
> Sent: Tuesday, January 7, 2020 7:30 AM
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] Consensus Weight Dropping/Authority Issues?
>
> On 1/7/20 1:57 PM, John Ricketts wrote:
> > I have been watching the consensus weight and bandwidth of all of my 50
> exit nodes drop consistently over the past few months. I have not made any
> hardware changes in my data center
>
>
> Which correlates to https://metrics.torproject.org/bandwidth.html - your
> fraction just decreases if more and more relays join the party.
>
> --
> Toralf
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

2020-01-07 Thread niftybunny

Months ago John beat my exit consensus weight. The Tor network didn’t grew 
substantially in this timeframe but he lost around 2/3 of his traffic while I 
was stable.

> On 7. Jan 2020, at 14:30, Toralf Förster  wrote:
> 
> Signed PGP part
> On 1/7/20 1:57 PM, John Ricketts wrote:
>> I have been watching the consensus weight and bandwidth of all of my 50 exit 
>> nodes drop consistently over the past few months. I have not made any 
>> hardware changes in my data center
> 
> 
> Which correlates to https://metrics.torproject.org/bandwidth.html - your 
> fraction just decreases if more and more relays join the party.
> 
> --
> Toralf
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

2020-01-07 Thread r1610091651

consensus means what fraction of traffic will pass over your nodes,
statistically speaking.
Hence a steady drop of consensus value, with no infra changes on your end,
could also be explained by a stead rise of total bandwidth available: since
your part is fixed and total grows, your fraction reduces.


Regards

On Tue, 7 Jan 2020 at 14:04, John Ricketts  wrote:

> Hello,
>
> I have been watching the consensus weight and bandwidth of all of my 50
> exit nodes drop consistently over the past few months. I have not made any
> hardware changes in my data center and actual customers have not complained
> about any performance issues.
>
> Operating systems and Tor version are up to date. I'm dedicating a
> significant portion of bandwidth to these nodes - 10gbit/sec.
>
> Am I having issues with the bandwidth authorities?
>
> I'm growing frustrated with my performance to resources ratio, I should be
> doing far better than this.
>
> Please throw ideas at me - open to any ideas.
>
> Thanks!
> John
> Quintex Alliance Consulting
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

I also would like to add to this - if it were just the Tor network increasing 
in size I could see my consensus weight dropping and my bandwidth staying the 
same.  I'm simply not getting the 7-8gbit/sec traffic I was.  Truly odd.

-Original Message-
From: tor-relays  On Behalf Of Toralf 
Förster
Sent: Tuesday, January 7, 2020 7:30 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

On 1/7/20 1:57 PM, John Ricketts wrote:
> I have been watching the consensus weight and bandwidth of all of my 50 exit 
> nodes drop consistently over the past few months. I have not made any 
> hardware changes in my data center

Which correlates to https://metrics.torproject.org/bandwidth.html - your 
fraction just decreases if more and more relays join the party.

-- 
Toralf

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

It seems disproportionate though.  I'm only using 2gbit/sec of my circuit and I 
have plenty of hardware ceiling left. Feels like i'm doing something else wrong.



> On Jan 7, 2020, at 07:30, Toralf Förster  wrote:
> 
> On 1/7/20 1:57 PM, John Ricketts wrote:
>> I have been watching the consensus weight and bandwidth of all of my 50 exit 
>> nodes drop consistently over the past few months. I have not made any 
>> hardware changes in my data center
> 
> 
> Which correlates to https://metrics.torproject.org/bandwidth.html - your 
> fraction just decreases if more and more relays join the party.
> 
> -- 
> Toralf
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Dropping/Authority Issues?

2020-01-07 Thread Toralf Förster

On 1/7/20 1:57 PM, John Ricketts wrote:
> I have been watching the consensus weight and bandwidth of all of my 50 exit 
> nodes drop consistently over the past few months. I have not made any 
> hardware changes in my data center


Which correlates to https://metrics.torproject.org/bandwidth.html - your 
fraction just decreases if more and more relays join the party.

-- 
Toralf



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus Weight Dropping/Authority Issues?

Hello,

I have been watching the consensus weight and bandwidth of all of my 50 exit 
nodes drop consistently over the past few months. I have not made any hardware 
changes in my data center and actual customers have not complained about any 
performance issues.

Operating systems and Tor version are up to date. I'm dedicating a significant 
portion of bandwidth to these nodes - 10gbit/sec.

Am I having issues with the bandwidth authorities?

I'm growing frustrated with my performance to resources ratio, I should be 
doing far better than this.

Please throw ideas at me - open to any ideas.

Thanks!
John
Quintex Alliance Consulting
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight low when compared to Advertised Bandwidth

2019-12-16 Thread Matt Westfall

Consensus weight is no lo ger based on advertised bandwidth to prevent abuse.

It is based on measured and observed actual throughput.


-- 
Matt Westfall
President & CIO 
ECAN Solutions, Inc. 
804.592.1672 

On December 16, 2019 1:30:48 PM EST, Neel Chauhan  wrote:
>Hi,
>
>After having my Primcast.com dedicated server suspended, I signed up
>for 
>a dedicated server from Psychz Networks in their Dallas location to run
>
>a FreeBSD-powered Tor exit relay.
>
>https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F
>
>While Psychz is a bit more expensive than Primcast/ServerRoom (and that
>
>is with an special offer), I get a slightly faster server and far
>better 
>customer support.
>
>One problem is that the consensus weight value is rather low in 
>proportion to the advertised bandwidth value, when they should be 
>approximately similar.
>
>In fact, my server's CPU usage never goes beyond 1%.
>
>Is this normal now that sbws is being deployed? Or is it bad peering on
>
>my relay?
>
>-Neel
>
>===
>
>https://www.neelc.org/
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight low when compared to Advertised Bandwidth

2019-12-16 Thread Matt Westfall

Also you didn't migrate your fingerprint. So it's a new server and will take 
weeks if not months for the consensus weight to creep up.


-- 
Matt Westfall
President & CIO 
ECAN Solutions, Inc. 
804.592.1672 

On December 16, 2019 1:30:48 PM EST, Neel Chauhan  wrote:
>Hi,
>
>After having my Primcast.com dedicated server suspended, I signed up
>for 
>a dedicated server from Psychz Networks in their Dallas location to run
>
>a FreeBSD-powered Tor exit relay.
>
>https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F
>
>While Psychz is a bit more expensive than Primcast/ServerRoom (and that
>
>is with an special offer), I get a slightly faster server and far
>better 
>customer support.
>
>One problem is that the consensus weight value is rather low in 
>proportion to the advertised bandwidth value, when they should be 
>approximately similar.
>
>In fact, my server's CPU usage never goes beyond 1%.
>
>Is this normal now that sbws is being deployed? Or is it bad peering on
>
>my relay?
>
>-Neel
>
>===
>
>https://www.neelc.org/
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight low when compared to Advertised Bandwidth

2019-12-16 Thread Roman Mamedov

On Mon, 16 Dec 2019 13:30:48 -0500
Neel Chauhan  wrote:

> After having my Primcast.com dedicated server suspended, I signed up for 
> a dedicated server from Psychz Networks in their Dallas location to run 
> a FreeBSD-powered Tor exit relay.
> 
> https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F

> Is this normal now that sbws is being deployed? Or is it bad peering on my 
> relay?

If you click that, it says:

"This relay appears to be less than 2 weeks old. This blog post explains the
lifecycle of a new relay, and why it will not be immediately fully used to
capacity."

and gives a link to https://blog.torproject.org/lifecycle-new-relay

That's all there's to it, just wait and see if there's still any problem after
at least a month or a couple.

-- 
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus Weight low when compared to Advertised Bandwidth

2019-12-16 Thread Neel Chauhan


Hi,

After having my Primcast.com dedicated server suspended, I signed up for 
a dedicated server from Psychz Networks in their Dallas location to run 
a FreeBSD-powered Tor exit relay.


https://metrics.torproject.org/rs.html#details/9B6672E247BC4656915DF03A470D4B5BC2E7601F

While Psychz is a bit more expensive than Primcast/ServerRoom (and that 
is with an special offer), I get a slightly faster server and far better 
customer support.


One problem is that the consensus weight value is rather low in 
proportion to the advertised bandwidth value, when they should be 
approximately similar.


In fact, my server's CPU usage never goes beyond 1%.

Is this normal now that sbws is being deployed? Or is it bad peering on 
my relay?


-Neel

===

https://www.neelc.org/
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus-health - Guard flag

2019-05-08 Thread lists


Hello,

I do not understand why relay A751D8BEE222564B7BA657F74B6658836FF1AEEA 
does not get a guard status.
A few weeks ago I set AccountingMax on this relay. This is off for about 
3 weeks. All servers are configured the same.


https://metrics.torproject.org/rs.html#search/TorOrDie4privacyNET

--
Ciao Marco!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight drops continuously 28h after getting guard flag

2019-01-12 Thread teor

Hi,

> On 12 Jan 2019, at 01:44, Ilka Schulz  wrote:
> 
> Is there actually any detailed documentation on how consensus weight is 
> calculated?

Consensus weight is calculated using a relay's self-reported peak bandwidth
usage, and measurements from ~6 bandwidth authorities around the world.

The process is slightly different on some of the bandwidth authorities, because
we are migrating to a newer system.

There is detailed documentation here:

5/6 bandwidth authorities run torflow:

https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/README.spec.txt#n298

1/6 bandwidth authorities run sbws:

https://github.com/juga0/sbws/blob/master/docs/source/specification.rst#simple-result-processing
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n656

> Also, my bandwidth (as well as my cpu, etc.) is only used to a fraction of 
> its capacity, even though my relay is three weeks old now. The 
> RelayBandwidthRate option does not limit here...

Tor is a connection-oriented, reliable-transport, low-latency network, so it 
will
never use your full bandwidth capacity. If it did, latency would suffer.

Here are some initial steps for troubleshooting:
https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

T

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight drops continuously 28h after getting guard flag

2019-01-11 Thread niftybunny

https://blog.torproject.org/comment/54651 


Everything will be alright :)

> On 11. Jan 2019, at 16:44, Ilka Schulz  wrote:
> 
> Hi,
> 
> approx. 28 hours after getting the guard flag, my relay 
> 's
>  consensus weight hit a peak and has declined rather rapidly since then 
> (again 28 hours ago).
> 
> Did I do something wrong? Is it because I restarted the relay 52 hours ago? 
> Is there actually any detailed documentation on how consensus weight is 
> calculated?
> 
> Also, my bandwidth (as well as my cpu, etc.) is only used to a fraction of 
> its capacity, even though my relay is three weeks old now. The 
> RelayBandwidthRate option does not limit here...
> 
> Regards,
> Ilka
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus weight drops continuously 28h after getting guard flag

2019-01-11 Thread Ilka Schulz

Hi,

approx. 28 hours after getting the guard flag, my relay
's
consensus weight hit a peak and has declined rather rapidly since then
(again 28 hours ago).

Did I do something wrong? Is it because I restarted the relay 52 hours
ago? Is there actually any detailed documentation on how consensus
weight is calculated?

Also, my bandwidth (as well as my cpu, etc.) is only used to a fraction
of its capacity, even though my relay is three weeks old now. The
/RelayBandwidthRate/ option does not limit here...

Regards,
Ilka



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health.html and fallback dirs

2018-12-20 Thread teor

> On 16 Dec 2018, at 17:01, starlight.201...@binnacle.cx wrote:
> 
> The cause is
> 
> https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766
> 
> https://trac.torproject.org/projects/tor/ticket/24803
> 
> Would be appreciated if the Tor project published outputs
> of UpdateFallbackDirs.py job runs used when rebuilding
> the list.  Thus operators who have expended effort to keep
> their relays eligible will know why when dropped.

We usually attach the logs to the relevant ticket.

This time, I saved the logs, but accidentally overwrote them.
And I didn't ask Colin to attach his logs.

We'll try to do better next time: I've added a note on the ticket
for 2019.

> On 17 Dec 2018, at 10:45, starlight.201...@binnacle.cx wrote:
> 
> Ran the script: output is attached to this message for anyone
> interested.  Live-network test results will vary by time and by
> the location of tester.  Attached run was made over Tor
> itself using 'torsocks'.

Thanks!

> I was bit by having disabled the unencrypted DIR port for
> one day recently as an experiment.

We rely on onionoo's last changed field:
https://metrics.torproject.org/onionoo.html#details_relay_last_changed_address_or_port

Changing or removing a published address or port resets the
last changed date. Adding an IPv6 address does not reset the
last changed date.

I realise that it's disappointing for relay operators to lose a flag.
But we're not too worried if a fallback drops out of the list for a
release or two: changing the fallback list regularly makes it
harder to block. And that's good for users.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health.html and fallback dirs

2018-12-16 Thread starlight . 2018q2

Ran the script: output is attached to this message for anyone
interested.  Live-network test results will vary by time and by
the location of tester.  Attached run was made over Tor
itself using 'torsocks'.

I was bit by having disabled the unencrypted DIR port for
one day recently as an experiment.


>Felix zwiebel at quantentunnel.de
>Sun Dec 16 10:03:33 UTC 2018
>
>>> I wonder how we can come from 116 running fallbacks to 155 within
>>> one week (without a new release)
>
>Am 16.12.2018 um 08:01 schrieb starlight.2018q2 at binnacle.cx:
>> The cause is
>> 
>> https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766
>
>Ah, great! This makes sense. It's a transient to the list update.
>
>
>
>> https://trac.torproject.org/projects/tor/ticket/24803
>
>The upcoming one seems to be:
>https://trac.torproject.org/projects/tor/ticket/28795
>
>-- 
>Cheers, Felix
>

fallback_dirs.log.xz
Description: Binary data
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health.html and fallback dirs

2018-12-16 Thread Felix


>> I wonder how we can come from 116 running fallbacks to 155 within
>> one week (without a new release)

Am 16.12.2018 um 08:01 schrieb starlight.201...@binnacle.cx:
> The cause is
> 
> https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766

Ah, great! This makes sense. It's a transient to the list update.



> https://trac.torproject.org/projects/tor/ticket/24803

The upcoming one seems to be:
https://trac.torproject.org/projects/tor/ticket/28795

-- 
Cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health.html and fallback dirs

2018-12-15 Thread starlight . 2018q2

The cause is

https://gitweb.torproject.org/tor.git/commit/?id=78e177d622f5f3b24023d04458f5948275a44766

https://trac.torproject.org/projects/tor/ticket/24803

Would be appreciated if the Tor project published outputs
of UpdateFallbackDirs.py job runs used when rebuilding
the list.  Thus operators who have expended effort to keep
their relays eligible will know why when dropped.



>Felix zwiebel at quantentunnel.de
>Sat Dec 15 23:59:03 UTC 2018
>
>Hi everybody
>
>Reading [1] shows the following statistics about the fallback dirs:
>
>Dec 5:
>Running116
>Not Running0
>Missing34
>
>Dec 13:
>Running155
>Not Running0
>Missing2
>
>Today (Dec 16) shows:
>Running151
>Not Running0
>Missing6
>
>I wonder how we can come from 116 running fallbacks to 155 within one
>week (without a new release):
>
>
>Then I checked for some fallbacks and found:
>
>The relay with the fp F9246DEF2B653807236DA134F2AEAB103D58ABFE was a
>fallback acc. fallback_dirs.inc until around 3.2.8rc, then it changed
>ip. It is still in 2.9.x lts but with the old ip, recommended but
>actually useless.
>
>Since around Dec 13 it is listed again [1] where it wasn't through 2018.
>
>The same with 8FA37B93397015B2BC5A525C908485260BE9F422.
>
>Are the two relays newly counted as running in [1], where they are
>useless because of the changed ips? The new ips aren't in any
>fallback_dirs.inc's and [2] shows no fallback flag.
>Would thereby [1] look better than it is?
>
>
>[1] https://consensus-health.torproject.org/consensus-health.html
>[2] 
>https://metrics.torproject.org/rs.html#details/F9246DEF2B653807236DA134F2AEAB103D58ABFE
>
>-- 
>Cheers, Felix

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] consensus-health.html and fallback dirs

2018-12-15 Thread Felix

Hi everybody

Reading [1] shows the following statistics about the fallback dirs:

Dec 5:
Running 116
Not Running 0
Missing 34

Dec 13:
Running 155
Not Running 0
Missing 2

Today (Dec 16) shows:
Running 151
Not Running 0
Missing 6

I wonder how we can come from 116 running fallbacks to 155 within one
week (without a new release):


Then I checked for some fallbacks and found:

The relay with the fp F9246DEF2B653807236DA134F2AEAB103D58ABFE was a
fallback acc. fallback_dirs.inc until around 3.2.8rc, then it changed
ip. It is still in 2.9.x lts but with the old ip, recommended but
actually useless.

Since around Dec 13 it is listed again [1] where it wasn't through 2018.

The same with 8FA37B93397015B2BC5A525C908485260BE9F422.

Are the two relays newly counted as running in [1], where they are
useless because of the changed ips? The new ips aren't in any
fallback_dirs.inc's and [2] shows no fallback flag.
Would thereby [1] look better than it is?


[1] https://consensus-health.torproject.org/consensus-health.html
[2]
https://metrics.torproject.org/rs.html#details/F9246DEF2B653807236DA134F2AEAB103D58ABFE

-- 
Cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

2018-04-23 Thread Keifer Bly

Torix, thanks you very much. Nice to see someone who has experience with this 
reaching out. I got a response saying that most relays are run at data centers, 
not at homes, which allows them to stay stable all the time. It seems like it 
would be extremely difficult to impossible to maintain the stable flag on a 
home connection. Good to know I’m not the only one having this trouble, good to 
contribute nonetheless. For keeping the relay as stable as possible, what would 
be your recommendations? Would you agree with what I said? I ask this because 
to me, relay stability seems difficult to calculate. Again thanks very much.
From: to...@protonmail.com
Sent: Monday, April 23, 2018 5:52 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Consensus Weight Definiton

Dear Keifer,

I run a small relay at home as well.  (I've never had more than 4,000/4,500 
connections, and my home router seems to have had no problem.)  However, 
guessing from the tor docs on my ISP that I should keep my monthly throughput 
to 1TB or so, I put some daily bandwidth limits on it.  Before the dos 
mitigation came out a couple of months ago, I would hit the limits every other 
day or so, and my relay would shut down until midnight.  So I never had a 
stable flag for months, and still had plenty of traffic.  

HTH,

--torix

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On April 22, 2018 2:05 PM, Keifer Bly  wrote:

> Thank you. However another thing that is confusing me a little is that based 
> off of my research, relays without the stable flag shouldn’t recurve much 
> traffic; mine says it’s received a few gigabytes since the downtime 1 day 
> ago. Thank you. It is acceptable not to have the stable flag and still be 
> useful to the network correct? Thank you very much.
> 
> Sent from my iPhone
> 
> On Apr 22, 2018, at 10:39 AM, Valter Jansons valter.jans...@gmail.com wrote:
> 
> > > I guess not every relay has the stable flag, would be curious to know 
> > > what the general percentage is
> > 
> > You can check with Tor Metrics how many relays have the Running
> > 
> > flag and how many have the Stable flag. By looking at the graph I
> > 
> > would estimate around 80% of Running relays have the Stable flag right
> > 
> > now.
> > 
> > -- 4096R/A83CE748 Valters Jansons
> > 
> > tor-relays mailing list
> > 
> > tor-relays@lists.torproject.org
> > 
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> tor-relays mailing list
> 
> tor-relays@lists.torproject.org
> 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

2018-04-23 Thread torix

Dear Keifer,

I run a small relay at home as well.  (I've never had more than 4,000/4,500 
connections, and my home router seems to have had no problem.)  However, 
guessing from the tor docs on my ISP that I should keep my monthly throughput 
to 1TB or so, I put some daily bandwidth limits on it.  Before the dos 
mitigation came out a couple of months ago, I would hit the limits every other 
day or so, and my relay would shut down until midnight.  So I never had a 
stable flag for months, and still had plenty of traffic.  

HTH,

--torix


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On April 22, 2018 2:05 PM, Keifer Bly  wrote:

> Thank you. However another thing that is confusing me a little is that based 
> off of my research, relays without the stable flag shouldn’t recurve much 
> traffic; mine says it’s received a few gigabytes since the downtime 1 day 
> ago. Thank you. It is acceptable not to have the stable flag and still be 
> useful to the network correct? Thank you very much.
> 
> Sent from my iPhone
> 
> On Apr 22, 2018, at 10:39 AM, Valter Jansons valter.jans...@gmail.com wrote:
> 
> > > I guess not every relay has the stable flag, would be curious to know 
> > > what the general percentage is
> > 
> > You can check with Tor Metrics how many relays have the Running
> > 
> > flag and how many have the Stable flag. By looking at the graph I
> > 
> > would estimate around 80% of Running relays have the Stable flag right
> > 
> > now.
> > 
> > -- 4096R/A83CE748 Valters Jansons
> > 
> > tor-relays mailing list
> > 
> > tor-relays@lists.torproject.org
> > 
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> tor-relays mailing list
> 
> tor-relays@lists.torproject.org
> 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

2018-04-22 Thread Keifer Bly

Thank you. However another thing that is confusing me a little is that based 
off of my research, relays without the stable flag shouldn’t recurve much 
traffic; mine says it’s received a few gigabytes since the downtime 1 day ago. 
Thank you. It is acceptable not to have the stable flag and still be useful to 
the network correct? Thank you very much.

Sent from my iPhone

On Apr 22, 2018, at 10:39 AM, Valter Jansons  wrote:

>> I guess not every relay has the stable flag, would be curious to know what 
>> the general percentage is
> 
> You can check with [Tor Metrics][] how many relays have the Running
> flag and how many have the Stable flag. By looking at the graph I
> would estimate around 80% of Running relays have the Stable flag right
> now.
> 
> [tor metrics]: 
> https://metrics.torproject.org/relayflags.html?start=2018-01-22&end=2018-04-22&flag=Running&flag=Stable
> 
> -- 4096R/A83CE748 Valters Jansons
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

2018-04-22 Thread Valter Jansons

> I guess not every relay has the stable flag, would be curious to know what 
> the general percentage is

You can check with [Tor Metrics][] how many relays have the Running
flag and how many have the Stable flag. By looking at the graph I
would estimate around 80% of Running relays have the Stable flag right
now.

[tor metrics]: 
https://metrics.torproject.org/relayflags.html?start=2018-01-22&end=2018-04-22&flag=Running&flag=Stable

-- 4096R/A83CE748 Valters Jansons
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

2018-04-22 Thread Keifer Bly

Maybe that’s it, unfortunately I have nowhere else I can possibly run it. 
What’s also not helpful is our electrical service isn’t good as it goes out 
every time there is some bad weather, which does not help. I guess not every 
relay has the stable flag, would be curious to know what the general percentage 
is haha.



> On Apr 21, 2018, at 11:34 PM, teor  wrote:
> 
> 
> 
>> On 22 Apr 2018, at 12:40, Keifer Bly  wrote:
>> 
>> Thank you. I am just a little confused as I seem to get the stable flag 
>> randomly, sometimes after 2 days, sometimes after 4 days, sometimes longer; 
>> what I'm saying is it seems completely random.
> 
> Perhaps your network is unstable.
> Most people can't run Tor relays a home, their home router doesn't handle the 
> load.
> 
>> My relay appears to be under " maatuska",
> 
> That's the median bandwidth authority, it has nothing to do with the Stable 
> flag.
> 
>> despite this I seem to get the stable after various numbers of days and have 
>> it suddenly revoked. Thank you very much for your help, I guess all you can 
>> do is just let the network do it's thing. It just seems like you'd need to 
>> have a wifi network and computer that basically never fail to have the 
>> stable flag.
> 
> Most relay operators run their relays in data centres.
> 
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton



> On 22 Apr 2018, at 12:40, Keifer Bly  wrote:
> 
> Thank you. I am just a little confused as I seem to get the stable flag 
> randomly, sometimes after 2 days, sometimes after 4 days, sometimes longer; 
> what I'm saying is it seems completely random.

Perhaps your network is unstable.
Most people can't run Tor relays a home, their home router doesn't handle the 
load.

> My relay appears to be under " maatuska",

That's the median bandwidth authority, it has nothing to do with the Stable 
flag.

> despite this I seem to get the stable after various numbers of days and have 
> it suddenly revoked. Thank you very much for your help, I guess all you can 
> do is just let the network do it's thing. It just seems like you'd need to 
> have a wifi network and computer that basically never fail to have the stable 
> flag.

Most relay operators run their relays in data centres.

T
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

Thank you. I am just a little confused as I seem to get the stable flag
randomly, sometimes after 2 days, sometimes after 4 days, sometimes longer;
what I'm saying is it seems completely random. My relay appears to be under
" maatuska", despite this I seem to get the stable after various numbers of
days and have it suddenly revoked. Thank you very much for your help, I
guess all you can do is just let the network do it's thing. It just seems
like you'd need to have a wifi network and computer that basically never
fail to have the stable flag.

On Sat, Apr 21, 2018 at 7:22 PM, teor  wrote:

>
> > On 22 Apr 2018, at 12:08, Keifer Bly  wrote:
> >
> > On https://consensus-health.torproject.org/, I found this information.
> I am curious, where it says  stable-uptime=, the following number is in
> minutes correct?
>
> It is in seconds:
>
> > On 12 Apr 2018, at 08:33, teor  wrote:
> >
> > On 12 Apr 2018, at 01:33, Keifer Bly  wrote:
> >
> >> Is there a way I can find out what the current weighted mbtf is? Thank
> you.
> >
> > The thresholds vary on each directory authority. They are
> > stable-uptime (~15 days) and stable-mtbf (~26 days) in this table:
> > https://consensus-health.torproject.org/#flagthresholds
> > Each figure is in seconds.
>
> T
>
> --
> teor
>
> teor2345 at gmail dot com
> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
> ricochet:ekmygaiu4rzgsk6n
> 
>
>
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton


> On 22 Apr 2018, at 12:08, Keifer Bly  wrote:
> 
> On https://consensus-health.torproject.org/, I found this information. I am 
> curious, where it says  stable-uptime=, the following number is in minutes 
> correct?

It is in seconds:

> On 12 Apr 2018, at 08:33, teor  wrote:
> 
> On 12 Apr 2018, at 01:33, Keifer Bly  wrote:
> 
>> Is there a way I can find out what the current weighted mbtf is? Thank you.
> 
> The thresholds vary on each directory authority. They are
> stable-uptime (~15 days) and stable-mtbf (~26 days) in this table:
> https://consensus-health.torproject.org/#flagthresholds
> Each figure is in seconds.

T

-- 
teor

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n






___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

My apologies if I seem worried, I am not trying to sound that way at all,
just trying to understand how all of this works.

On https://consensus-health.torproject.org/, I found this information. I am
curious, where it says  stable-uptime=, the following number is in minutes
correct?

Thank you.

Known flags 
maatuska known-flags Authority BadExit Exit Fast Guard HSDir Running Stable
V2Dir Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
tor26 known-flags Authority BadExit Exit Fast Guard HSDir Running Stable
V2Dir Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
longclaw known-flags Authority BadExit Exit Fast Guard HSDir Running Stable
V2Dir Valid FallbackDir Unmeasured DescriptorMismatch
dizum known-flags Authority Exit Fast Guard HSDir Running Stable V2Dir
Valid FallbackDir Unmeasured DescriptorMismatch
bastet known-flags Authority Exit Fast Guard HSDir Running Stable V2Dir
Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
gabelmoo known-flags Authority BadExit Exit Fast Guard HSDir Running Stable
V2Dir Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
moria1 known-flags Authority BadExit Exit Fast Guard HSDir Running Stable
V2Dir Valid FallbackDir Unmeasured DescriptorMismatch
dannenberg known-flags Authority Exit Fast Guard HSDir Running Stable V2Dir
Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
faravahar known-flags Authority BadExit Exit Fast Guard HSDir Running
Stable V2Dir Valid ReachableIPv6 NoIPv6Consensus FallbackDir Unmeasured
DescriptorMismatch
consensus known-flags Authority BadExit Exit Fast Guard HSDir NoEdConsensus
Running Stable V2Dir Valid ReachableIPv6 NoIPv6Consensus FallbackDir
Unmeasured DescriptorMismatch
Flag Thresholds 
maatuska flag-thresholds guard-bw-exc-exits=839
guard-bw-inc-exits=997 guard-tk=691200 stable-uptime=1508364
enough-mtbf=1 fast-speed=72000 guard-wfu=0.98 stable-mtbf=2727600
ignoring-advertised-bws=1
tor26 flag-thresholds guard-bw-exc-exits=5422000 guard-bw-inc-exits=6576000
guard-tk=691200 stable-uptime=1497887 enough-mtbf=1 fast-speed=102000
guard-wfu=0.98 stable-mtbf=2015184 ignoring-advertised-bws=0
longclaw flag-thresholds guard-bw-exc-exits=5242000
guard-bw-inc-exits=640 guard-tk=691200 stable-uptime=1454621
enough-mtbf=1 fast-speed=102000 guard-wfu=0.98 stable-mtbf=2850956
ignoring-advertised-bws=0
dizum flag-thresholds guard-bw-exc-exits=5242000 guard-bw-inc-exits=6424000
guard-tk=691200 stable-uptime=1464944 enough-mtbf=1 fast-speed=102000
guard-wfu=0.98 stable-mtbf=2783063 ignoring-advertised-bws=0
bastet flag-thresholds guard-bw-exc-exits=745
guard-bw-inc-exits=906 guard-tk=691200 stable-uptime=1497887
enough-mtbf=1 fast-speed=75000 guard-wfu=0.98 stable-mtbf=2619896
ignoring-advertised-bws=1
gabelmoo flag-thresholds guard-bw-exc-exits=5242000
guard-bw-inc-exits=6436000 guard-tk=691200 stable-uptime=1458892
enough-mtbf=1 fast-speed=102000 guard-wfu=0.98 stable-mtbf=2801856
ignoring-advertised-bws=0
moria1 flag-thresholds guard-bw-exc-exits=5242000
guard-bw-inc-exits=6422000 guard-tk=691200 stable-uptime=175
enough-mtbf=1 fast-speed=102000 guard-wfu=0.98 stable-mtbf=2750090
ignoring-advertised-bws=0
dannenberg flag-thresholds guard-bw-exc-exits=5327000
guard-bw-inc-exits=6553000 guard-tk=691200 stable-uptime=1455937
enough-mtbf=1 fast-speed=102000 guard-wfu=0.98 stable-mtbf=2162701
ignoring-advertised-bws=0
faravahar flag-thresholds guard-bw-exc-exits=727
guard-bw-inc-exits=847 guard-tk=691200 stable-uptime=1510855
enough-mtbf=1 fast-speed=101000 guard-wfu=0.98 stable-mtbf=2578082
ignoring-advertised-bws=1


On Sat, Apr 21, 2018 at 6:40 PM, teor  wrote:

> Hi,
>
> You talked about using homebrew to automatically update tor.
> How do you launch tor?
> Des homebrew restart tor when it is updated?
>
> Because tor doesn't update to the new version until you restart it.
>
> On 22 Apr 2018, at 11:06, Keifer Bly  wrote:
>
> Thank you. And I’m not asking for a for sure response, just generally what
> you think, would an about 40 minute downtime (what I had this morning)
> majorly effect my time between failures after about 106 hours of solid
> uptime?
>
>
> If your relay fails after 106 hours, the average time before failure will
> get closer to 106 hours.
>
> If you want to know how this might affect the stable flag, you can
> find the thresholds on consensus-health, and check if they are more
> or less than 106 hours. Read people's previous responses to your
> emails for details.
>
> Sorry to keep emailing but trying to keep my relay as useful as possible
> to the network.
>
>
> The tor network has significant redundancy.
> There are thousands of relays.
> Clients adapt to changes and just use another relay.
>
> You seem really worried, so I'm going to repeat some advice from

Re: [tor-relays] Consensus Weight Definiton

Hi,

You talked about using homebrew to automatically update tor.
How do you launch tor?
Des homebrew restart tor when it is updated?

Because tor doesn't update to the new version until you restart it.

> On 22 Apr 2018, at 11:06, Keifer Bly  wrote:
> 
> Thank you. And I’m not asking for a for sure response, just generally what 
> you think, would an about 40 minute downtime (what I had this morning) 
> majorly effect my time between failures after about 106 hours of solid 
> uptime? 

If your relay fails after 106 hours, the average time before failure will
get closer to 106 hours.

If you want to know how this might affect the stable flag, you can
find the thresholds on consensus-health, and check if they are more
or less than 106 hours. Read people's previous responses to your
emails for details.

> Sorry to keep emailing but trying to keep my relay as useful as possible to 
> the network.

The tor network has significant redundancy.
There are thousands of relays.
Clients adapt to changes and just use another relay.

You seem really worried, so I'm going to repeat some advice from
an earlier email:

Do your best to run a relay.
Keep it updated.
Stop worrying.
Just relax.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

Thank you. And I’m not asking for a for sure response, just generally what you 
think, would an about 40 minute downtime (what I had this morning) majorly 
effect my time between failures after about 106 hours of solid uptime? 

Sorry to keep emailing but trying to keep my relay as useful as possible to the 
network.

Sent from my iPhone

> On Apr 21, 2018, at 4:25 PM, teor  wrote:
> 
> Hi,
> 
>> On 22 Apr 2018, at 08:35, Keifer Bly  wrote:
>> 
>> Hello,
>>  
>> I am wondering, could you please explain exactly what “Consensus Weight” is? 
>> I had had a good uptime, about five days, then my darn computer that I run 
>> my relay off of froze for about 40 minutes this morning and I had no choice 
>> but to reboot the tor software, setting my current uptime back to 0 days. 
>> However, it has a consensus weight of 523, is this a good rating? Does this 
>> have an effect on things such as what flags a relay has (mine currently 
>> being Fast, V2Dir, Running, and Valid)?
>>  
>> The relay in question can be found here: 
>> https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E72132684096EEE779D30
> 
> Here is the definition of consensus weight:
> https://metrics.torproject.org/glossary.html#consensus-weight
> 
> If you still have more questions, search the archives of
> tor-relays@lists.torproject.org for the words "bandwidth" and "consensus 
> weight":
> https://lists.torproject.org/pipermail/tor-relays/
> 
> Please feel free to ask more specific questions after reading these things.
> 
>> I know the stable flag (which I have had on and off since  starting my 
>> relay, don’t currently have it but relay seems to receive traffic 
>> nonetheless) depends on uptime history, not exact current uptime, but am 
>> curious, is there an easy to check my current uptime history?
> 
> As someone said in response to your last email, no, there is not.
> 
> But you can see your consensus weight and flags history as graphs on:
>> https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E72132684096EEE779D30
> 
> You can get an idea of your uptime from these graphs.
> 
> But please ignore the 1 month bandwidth graph, it might be empty,
> and it will go away soon. The longer graphs will stay.
> (Relays recently stopped reporting bandwidth in detail for security
> reasons. Search the list archives for details.)
> 
>> Also, I thought I’d share an applescript I wrote to automatically update the 
>> tor relay software and homebrew one minute after midnight every day.
> 
> It looks like it would work on macOS.
> 
> Most people use cron for scheduled tasks, because it works on Linux and BSDs 
> as well.
> 
> T
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight Definiton

Hi,

> On 22 Apr 2018, at 08:35, Keifer Bly  wrote:
> 
> Hello,
>  
> I am wondering, could you please explain exactly what “Consensus Weight” is? 
> I had had a good uptime, about five days, then my darn computer that I run my 
> relay off of froze for about 40 minutes this morning and I had no choice but 
> to reboot the tor software, setting my current uptime back to 0 days. 
> However, it has a consensus weight of 523, is this a good rating? Does this 
> have an effect on things such as what flags a relay has (mine currently being 
> Fast, V2Dir, Running, and Valid)?
>  
> The relay in question can be found here: 
> https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E72132684096EEE779D30

Here is the definition of consensus weight:
https://metrics.torproject.org/glossary.html#consensus-weight

If you still have more questions, search the archives of
tor-relays@lists.torproject.org for the words "bandwidth" and "consensus 
weight":
https://lists.torproject.org/pipermail/tor-relays/

Please feel free to ask more specific questions after reading these things.

> I know the stable flag (which I have had on and off since  starting my relay, 
> don’t currently have it but relay seems to receive traffic nonetheless) 
> depends on uptime history, not exact current uptime, but am curious, is there 
> an easy to check my current uptime history?

As someone said in response to your last email, no, there is not.

But you can see your consensus weight and flags history as graphs on:
> https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E72132684096EEE779D30

You can get an idea of your uptime from these graphs.

But please ignore the 1 month bandwidth graph, it might be empty,
and it will go away soon. The longer graphs will stay.
(Relays recently stopped reporting bandwidth in detail for security
reasons. Search the list archives for details.)

> Also, I thought I’d share an applescript I wrote to automatically update the 
> tor relay software and homebrew one minute after midnight every day.

It looks like it would work on macOS.

Most people use cron for scheduled tasks, because it works on Linux and BSDs as 
well.

T___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus Weight Definiton



Hello,

I am wondering, could you please explain exactly what “Consensus Weight” is? I 
had had a good uptime, about five days, then my darn computer that I run my 
relay off of froze for about 40 minutes this morning and I had no choice but to 
reboot the tor software, setting my current uptime back to 0 days. However, it 
has a consensus weight of 523, is this a good rating? Does this have an effect 
on things such as what flags a relay has (mine currently being Fast, V2Dir, 
Running, and Valid)?

The relay in question can be found here: 
https://metrics.torproject.org/rs.html#details/DB1AF6477BB276B6EA5E72132684096EEE779D30


I know the stable flag (which I have had on and off since  starting my relay, 
don’t currently have it but relay seems to receive traffic nonetheless) depends 
on uptime history, not exact current uptime, but am curious, is there an easy 
to check my current uptime history? 

Also, I thought I’d share an applescript I wrote to automatically update the 
tor relay software and homebrew one minute after midnight every day.

Here is the source code (written using AppleScript editor)

do shell script "$ which brew
/usr/local/bin/brew update"
do shell script "$ which brew
/usr/local/bin/brew upgrade tor"
end


When it runs, it comes up with this error, saying tor is already up to date.




sh: $: command not found
Error: tor 0.3.2.10 already installed (1)

As this is the only error that appears, I’d take it that the script works

It can be scheduled to run automatically at midnight every night via this 
method I found here:



https://apple.stackexchange.com/questions/24862/how-can-i-configure-my-computer-to-run-an-applescript-at-a-specific-time-caveat

I am curious to know what you all think of this tactic if you will, please let 
me know as you can give it to others if you wish. Thank you.


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-07-01 Thread Vort

Finally, I have made my test program and found that I was
  wrong about two things:

1. Low weight relays (< 30) rarely give fast speed (> 150 KiB/s) on
  two-hop circuits. With three hops, fast speed even more rare thing.

2. Windows version of Tor really have some problems.


I don't quite understand the factors, which have influence on
  circuit speed, but, at least, I have found how it is possible to
  obtain the low bandwidth estimate for my relay.

I have selected two entry nodes and two exit nodes:
refEntry1 D665C959571041972EA8C0DD77559EF5579BA112
refEntry2 13B2354C74CCE29815B4E1F692F2F0E86C7F13DD
refExit1  5CECC5C30ACC4B3DE462792323967087CC53D947
refExit2  07C05ED4825F51D5BE4CDBBAA80BFA484132A2F5

Then launched four circuits:
refEntry1, myNode, refExit1
refEntry1, myNode, refExit2
refEntry2, myNode, refExit1
refEntry2, myNode, refExit2

And measured their bandwidth:
1. 117 KiB/s
2. 122 KiB/s
3. 59  KiB/s
4. 51  KiB/s

That was pretty strange.
Previous tests with speedtest.net showed that 500-1000 KiB/s
  speeds are not a problem for my connection.

Next idea was to measure the neighbor relay (from the same city and ISP).
And this resulted in following speeds:
1. 356 KiB/s
2. 392 KiB/s
3. 375 KiB/s
4. 271 KiB/s

Not too fast, but definitely better than result for my relay.

So one of the limiting factors is located somewhere on my computer.
Connection count is fine, RAM and CPU are also good enough.

The only difference left is operating system.

It is possible for me to boot from USB stick with some Linux.
But first I have decided to make a test with virtual machine.

Port forwarding was set, Ubuntu and new Tor relay are
  launched and here is the result:
1. 452 KiB/s
2. 375 KiB/s
3. 141 KiB/s
4. 163 KiB/s

Usually adding a virtual machine leads to worse results.
But not this time.

So the next question is:
How Linux version inside Windows can perform three times
  better than Windows version alone?

And what is the real limit for my configuration?
Even if 100 KiB/s speed changes to 300 KiB/s, this will be still
  far from 1 MiB/s, 5 MiB/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

Re: [tor-relays] Consensus Weight calculation

2017-06-29 Thread Vort

> We tried to unstick some of the lowest bandwidth relays (below 1000),

You mean 0..1 weight (1 KiB/s and lower)?
They may be really bad.

I guess, that good test range is 10..20 (or 5..30).


> and our initial results are:
> * most (15) of relays we tried are actually very slow, or down,
> * some (3) relays that we tried went down before we could see if we had
>   changed anything,

Relays can be additionally filtered by Stable flag (or uptime).
If relay haven't rebooted for weeks, there is a big chance that it will
  stay online during the tests too.


> We are trying on a larger set now.

I hope this will give more successful attempts.


> But these results indicate that most relays
> that are measured slow are actually slow for tor clients.
> (Which is what matters.)

If larger set will not give better results, I will try to make
  my own test 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.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-29 Thread teor

> On 29 Jun 2017, at 16:03, Vort  wrote:
> 
> In order to estimate the effect of relays unstuck
>  measures, I have made some graphs.
> 
> The first graph shows how many relays in the network have
>  weight < 20 (in percents, relative to total measured, valid and running 
> count):
> 
> https://s8.hostingkartinok.com/uploads/images/2017/06/e905280414853a800031e7ffbeba02c0.png
> 
> And I see some drop at June, 15: from ~7.4% to ~6.6%.
> This corresponds to increase of my relay weight: from ~10 to ~20.
> Looks like this is the effect of increasing the minimum test file size.

No, we have not changed the minimum test file size yet.
This is probably just random measurement variation.

The only thing we have started testing over the last few days is:
> * making an automatic process to un-stick stuck relays

We tried to unstick some of the lowest bandwidth relays (below 1000),
and our initial results are:
* most (15) of relays we tried are actually very slow, or down,
* some (3) relays that we tried went down before we could see if we had
  changed anything,
* 1 relay that we tried increased its bandwidth 10x, but we don't
  know if it was because of us, or something else.

We are trying on a larger set now. If we get better results, maybe we
will make it automatic. But these results indicate that most relays
that are measured slow are actually slow for tor clients.
(Which is what matters.)

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-28 Thread Vort

In order to estimate the effect of relays unstuck
  measures, I have made some graphs.

The first graph shows how many relays in the network have
  weight < 20 (in percents, relative to total measured, valid and running 
count):

https://s8.hostingkartinok.com/uploads/images/2017/06/e905280414853a800031e7ffbeba02c0.png

And I see some drop at June, 15: from ~7.4% to ~6.6%.
This corresponds to increase of my relay weight: from ~10 to ~20.
Looks like this is the effect of increasing the minimum test file size.


Second graph is the same, but for weight < 100:

https://s8.hostingkartinok.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.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-28 Thread Vort

>> Windows does not limit connection count for processes and users.
>> There are also no system-wide limit for sockets.
>> Except for available dynamic port range (1025-64510 on my computer).

> Depending on your Windows version, the limit may be around 2000-4000,
> check this article:
> http://smallvoid.com/article/winnt-tcpip-max-limit.html

1. This article is from year 2004. Most described parameters are
  removed on modern systems.

2. Available port range on my computer is 64510 - 1025 = 63485 ports.
  But this limits only outbound connection count. Inbound connection
  count is unlimited.
  
https://msdn.microsoft.com/en-us/library/windows/desktop/ms739169(v=vs.85).aspx 
:
  "The Microsoft Winsock provider limits the maximum number of sockets
  supported only by available memory on the local computer."

3. Half-open connections limit, mentioned in article, was removed
  starting from Windows 7.


> You should also check how many connections your relay is actually
> making.

Jun 28 01:30:51.000 [notice] Since startup, we have initiated 0 v1 connections, 
0 v2 connections, 0 v3 connections, and 384 v4 connections; and received 26 v1 
connections, 0 v2 connections, 0 v3 connections, and 639 v4 connections.
Jun 28 07:30:51.000 [notice] Since startup, we have initiated 0 v1 connections, 
0 v2 connections, 0 v3 connections, and 664 v4 connections; and received 46 v1 
connections, 0 v2 connections, 0 v3 connections, and 1200 v4 connections.
Jun 28 13:30:51.000 [notice] Since startup, we have initiated 0 v1 connections, 
0 v2 connections, 0 v3 connections, and 725 v4 connections; and received 63 v1 
connections, 1 v2 connections, 0 v3 connections, and 1469 v4 connections.


> Ok, so if your relay is in the 16MB bucket, it should be measured
> at at least 200 after a few weeks. But it's hard to tell which
> bucket each relay is in, that depends on the bandwidth authority.

If my relay resurrects, that would be great.
But more important goal is to prevent the possibility of such stuck.
Instead of + 1 MiB/s this can yield + 1 GiB/s.


> That might unstick your relay.
> We need to know if this happens, because it helps us to know what to do
> to fix stuck relays.

Yes, it can.
Some relays are already unstuck (9FC2673BB2704C2AAB851F8334938565DF1D0819,
  143BC876D403003FBEF2AA843942DC4D248E3872 for example).
But some stuck even deeper (B918EB3FA4D03A4F9F632AA17F217A6C04044EF7,
  BD4354E76929C90B7004FF149A3C52189A3B4634).
So my fear is that routers are get unstuck at the expense of some getting stuck.
If this is not the case, that is great!


> We are working on it a few different ways:
> * 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 your work.


-- Vort

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-28 Thread teor


> On 28 Jun 2017, at 15:39, Vort  wrote:
> ...
>> What is the connection / handle limit on the tor process and the user
>> you are using for the tor process?
> 
>> For a non-exit relay, it needs to be around 10,000.
>> For an large exit relay, it needs to be 50,000 or so.
> 
> Windows does not limit connection count for processes and users.
> There are also no system-wide limit for sockets.
> Except for available dynamic port range (1025-64510 on my computer).

Depending on your Windows version, the limit may be around 2000-4000,
check this article:
http://smallvoid.com/article/winnt-tcpip-max-limit.html

You should also check how many connections your relay is actually
making.

>> Now check the latency and bandwidth to these directory authorities.
>> But only do to once, they have a lot of load already.
> 
>> Also, use gabelmoobwauth, rather than gabelmoo.
>> And check Faravahar.
> 
> Latency (ping):
> longclaw   / 199.254.238.53 : 187 ms
> gabelmoobwscan / 131.188.40.189 : 44 ms
> moria1 / 128.31.0.34: 128 ms
> faravahar  / 154.35.175.225 : 147 ms
> 
> Bandwidth (via PrivacyRepublic0001 and 16M file from 38.229.72.16):
> longclaw: 285 KiB/s
> gabelmoobwscan  : 1195 KiB/s
> moria1  : 404 KiB/s
> faravahar   : 141 KiB/s

Ok, so if your relay is in the 16MB bucket, it should be measured
at at least 200 after a few weeks. But it's hard to tell which
bucket each relay is in, that depends on the bandwidth authority.

>> Ok, the next limit will be the observed bandwidth.
> 
> After the yesterday test #5, observed bandwidth changed to 1.12 MiB/s.

That might unstick your relay.
We need to know if this happens, because it helps us to know what to do
to fix stuck relays.

>> You need to be patient.
> 
> That's not a problem if I know that something will definitely
>  change in the future.

We are working on it a few different ways:
* 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

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-27 Thread Vort

> This could be part of your issue.
> The code for tor relays on Windows is not maintained very well.

There are many relays on Windows, which are not stuck.
And many relays on Linux, which are stuck.


> What is the connection / handle limit on the tor process and the user
> you are using for the tor process?

> For a non-exit relay, it needs to be around 10,000.
> For an large exit relay, it needs to be 50,000 or so.

Windows does not limit connection count for processes and users.
There are also no system-wide limit for sockets.
Except for available dynamic port range (1025-64510 on my computer).


> Now check the latency and bandwidth to these directory authorities.
> But only do to once, they have a lot of load already.

> Also, use gabelmoobwauth, rather than gabelmoo.
> And check Faravahar.

Latency (ping):
longclaw   / 199.254.238.53 : 187 ms
gabelmoobwscan / 131.188.40.189 : 44 ms
moria1 / 128.31.0.34: 128 ms
faravahar  / 154.35.175.225 : 147 ms

Bandwidth (via PrivacyRepublic0001 and 16M file from 38.229.72.16):
longclaw: 285 KiB/s
gabelmoobwscan  : 1195 KiB/s
moria1  : 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 definitely
  change in the future.


-- Vort

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-27 Thread teor


> On 27 Jun 2017, at 23:52, Vort  wrote:
> ...
> 
>> I made a wiki page to tell people how to do that:
>> https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow
>> ...
> 
>> 1. Check RAM, CPU, and socket/file descriptor usage on your relay
> 
> Private bytes amount for tor.exe process is 116 MiB,

This could be part of your issue.
The code for tor relays on Windows is not maintained very well.

>  ...
> 
> Tor process have 573 handles open and about 380 established TCP
>  connections. But this is unusual activity, related to Faravahar
>  downtime and, respectively, obtaining of Fast and HSDir flags.
> Usually, it have only 20-30 connections established.

What is the connection / handle limit on the tor process and the user
you are using for the tor process?

For a non-exit relay, it needs to be around 10,000.
For an large exit relay, it needs to be 50,000 or so.

> ...
> 
>> 3. Check each of the votes for your relay on consensus-health
>>  (large page), and check the median:
> 
> Consensus was published 2017-06-27 12:00:00.
> longclaw: bw=34
> gabelmoo: bw=41
> moria1  : bw=23
> 
> *median*: bw=34

This is the limit on your relay.

Now check the latency and bandwidth to these directory authorities.
But only do to once, they have a lot of load already.

Also, use gabelmoobwauth, rather than gabelmoo.
And check Faravahar.

>> 4. Check your relay's observed bandwidth and bandwidth rate (limit).
> 
> Bandwidth rate: 1 MiB/s
> Bandwidth burst   : 3 MiB/s
> Observed bandwidth: 250.77 KiB/s

Ok, the next limit will be the observed bandwidth.

> ...
>> 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.

If you just write to me, that won't change.
You need to be patient.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-27 Thread Vort

> Before we investigate the measurements:
> * We need to know if anything on your relay or at your provider
>   is making your relay slow,
> * We need to be know which measurement of your relay is slow.

> I made a wiki page to tell people how to do that:
> https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

> Please go through the steps, and let us know what results you get.
> Then someone can help you more.

> 1. Check RAM, CPU, and socket/file descriptor usage on your relay

Private bytes amount for tor.exe process is 116 MiB,
  3.4 GiB of system memory is available (out of 8 GiB total).
Log shows that: "Based on detected system memory, MaxMemInQueues
  is set to 2048 MB. You can override this by setting MaxMemInQueues by hand."

Tor is using 0-1% of CPU resource on the average.
Sometimes it consumes 25% of CPU (100% of 1 core) for 10 seconds.
And then returns back to normal 0-1% usage.

Tor process have 573 handles open and about 380 established TCP
  connections. But this is unusual activity, related to Faravahar
  downtime and, respectively, obtaining of Fast and HSDir flags.
Usually, it have only 20-30 connections established.


> 2. Check the internet peering (bandwidth, latency) from your relay's
>   provider to other relays.

Latency (ping):
hviv104 / 192.42.116.16  : 40 ms
PrivacyRepublic0001 / 178.32.181.96  : 39 ms
Unnamed / 185.170.41.8   : 36 ms
McCormickRecipes/ 18.85.22.204   : 135 ms
PhantomTrain4   / 65.19.167.131  : 184 ms

Bandwidth (via dopper / 192.42.113.102 and bwauth's 16M file):
hviv104  : 50 KiB/s
PrivacyRepublic0001  : 1.3 MiB/s
Unnamed  : 155 KiB/s
McCormickRecipes : 947 KiB/s
PhantomTrain4: 899 KiB/s


> 3. Check each of the votes for your relay on consensus-health
>   (large page), and check the median:

Consensus was published 2017-06-27 12:00:00.
longclaw: bw=34
gabelmoo: bw=41
moria1  : bw=23

*median*: bw=34


> 4. Check your relay's observed bandwidth and bandwidth rate (limit).

Bandwidth rate: 1 MiB/s
Bandwidth burst   : 3 MiB/s
Observed bandwidth: 250.77 KiB/s


> 5. Run a test using tor to see how fast tor can get on your network/CPU:

This will alter observed bandwidth. But okay.
Depending on exit node, result varies from 117 KiB/s to 1 MiB/s. Example:

$ curl --socks5-hostname localhost:9050 --insecure -O 
https://38.229.72.16/bwauth.torproject.org/16M
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 16.0M  100 16.0M0 0   857k  0  0:00:19  0:00:19 --:--:--  967k


> 6. Run a test using tor and chutney to find out how fast tor can get on
>   your CPU. Keep increasing the data volume until the bandwidth stops 
> increasing:

As this tool is designed for Linux, I can run it only within virtual machine.
But results are still good:

$ CHUTNEY_DATA_BYTES=104857600 ./chutney verify networks/basic-min
...
Single Stream Bandwidth: 99.46 MBytes/s
Overall tor Bandwidth: 397.85 MBytes/s

$ CHUTNEY_DATA_BYTES=1048576000 ./chutney verify networks/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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-27 Thread teor

> On 27 Jun 2017, at 14:57, Vort  wrote:
> 
> Hello, teor.
> 
> Is it worth to wait till you have time to investigate stuck relays problem?

You can help yourself!

Before we investigate the measurements:
* We need to know if anything on your relay or at your provider
  is making your relay slow,
* We need to be know which measurement of your relay is slow.

I made a wiki page to tell people how to do that:
https://trac.torproject.org/projects/tor/wiki/doc/MyRelayIsSlow

Please go through the steps, and let us know what results you get.
Then someone can help you more.

It might not be me that helps you.
So please talk to the list when you write back.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-26 Thread 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

Re: [tor-relays] Consensus Weight calculation

2017-06-21 Thread Vort

>> Are there any news regarding that problem?

> It's a complicated problem.
> We need to work out why it is happening before we can fix it.

I am not sure if I really can help with BwAuth's algorithms.


But that's what I would do in such situation:

First, most important thing, is a clear goal.
As BwAuth's task is to make a measurements, then theirs result must
  be clearly defined.
So, the question is - how an ideal "w" ([Consensus] Weight) looks like?

Suppose we have some perfectly measured parameters for relay:
  perfect_measured_bandwidth (KiB/sec) and perfect_measured_latency (sec).
Their exact definition can be omitted now for simplicity.

Then ideal_w should be equal to:
ideal_w = perfect_measured_bandwidth
ideal_w = k * perfect_measured_bandwidth
ideal_w = k * perfect_measured_bandwidth / perfect_measured_latency
  or, maybe, something else?

Once this question is clear, then it is possible to see how existent
  implementation is far from this ideal.


And here is part two: why it is different?
It is some noise that can't be eliminated?
Or algorithm for some reason converges to incorrect values?

BwAuths have some debug information.
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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-13 Thread Vort

> I think we will have to agree to disagree about this.

Ok, let's focus on the problem first.
Conclusions can be made later.


> Please help us find out which of these things impact one of your
> relays.

The only thing from your list, which can have effect - is the properties
  of other relays and theirs Internet connections.
But weight is assigned to single relay, so this differences must be
  filtered out somehow.


> Yes, the Tor network measures it from 4 different locations every few
> days.

And gives incorrect weight as a result.
Stable incorrect result.
It is needed to discuss what is a good weight.
But that can be done later.
My idea is that 1 KiB of load when 1000 KiB of bandwidth available is bad.
Just imagine that this 1 MiB/s are really can be used.
Of course, not to all network.
But if some dial-up node can't use it, this doesn't mean that no one can.


> What makes your measurement is more accurate?
1. I was checking this speed with random relays, which mean that
  high-speed relays was certainly included in the circuits.
  (this gives 100 instead of 58436)
2. I was used obtained value directly to decide if relay is good enough.
  (this gives 100 instead of 5000)


> Where are you measuring from?

Ukraine.

> Is it close to the relay?

I have made many measurements.
Some of them was close to relay, some are not.

> How long did it take to do the download?

Here are some results:
  extendcircuit 0 
$BD4354E76929C90B7004FF149A3C52189A3B4634,$A53C46F5B157DD83366D45A8E99A244934A14C46
  650 CIRC 10 BUILT 
$BD4354E76929C90B7004FF149A3C52189A3B4634~Hedgehog,$A53C46F5B157DD83366D45A8E99A244934A14C46~csailmitexit
 PURPOSE=GENERAL TIME_CREATED=2017-06-14T06:02:21.529447
  650 STREAM 13 CLOSED 10 38.229.72.16:443 REASON=DONE
  $ curl --socks5-hostname localhost:9050 --insecure -O 
https://38.229.72.16/bwauth.torproject.org/16M
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100 16.0M  100 16.0M0 0   856k  0  0:00:19  0:00:19 --:--:--  985k

But this relay is close to my location.
Let's select another:
  extendcircuit 0 
$38BF40B902ABC23B4E1503BE9131F1A3BF8EBAC5,$A53C46F5B157DD83366D45A8E99A244934A14C46
  650 CIRC 11 BUILT 
$38BF40B902ABC23B4E1503BE9131F1A3BF8EBAC5~bzerorelay1,$A53C46F5B157DD83366D45A8E99A244934A14C46~csailmitexit
 PURPOSE=GENERAL TIME_CREATED=2017-06-14T06:06:19.551317
  650 STREAM 17 CLOSED 11 38.229.72.16:443 REASON=DONE
  $ curl --socks5-hostname localhost:9050 --insecure -O 
https://38.229.72.16/bwauth.torproject.org/16M
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100 16.0M  100 16.0M0 0   268k  0  0:01:01  0:01:01 --:--:--  271k

Of course, it is slower.
But still far from utilized 2 KiB/s.

> Did you measure from different parts of the world?

I don't have control over multiple locations.


> 1. Choose a relay you control to focus on.
> 2. Send information about the relay's CPU and RAM and configured
>connection limit.

* CPU: Intel Core i5-4690
* RAM: Team Group Dark-1600, 8 GiB

* RelayBandwidthRate 1 MBytes
  RelayBandwidthBurst 3 MBytes


> 3. Measure the actual connection limit, bandwidth and latency from
>the rest of the Tor network. (Or from at least 2 locations in the
>US and Western Europe.)

I doubt if it is good to test with a loop connections, so I will post
  speedtest.net results. They give good estimate of my connection
  properties.

  http://www.speedtest.net/my-result/6375679554
  DOWNLOAD 94.86Mb/s
  UPLOAD 95.21Mb/s
  PING 24 ms
  SERVER SAINT PETERSBURG

  http://www.speedtest.net/my-result/6375676443
  DOWNLOAD 89.53Mb/s
  UPLOAD 94.51Mb/s
  PING 48 ms
  SERVER MILAN

  http://www.speedtest.net/my-result/6375670157
  DOWNLOAD 89.53Mb/s
  UPLOAD 94.54Mb/s
  PING 51 ms
  SERVER DRESDEN

  http://www.speedtest.net/my-result/6375655269
  DOWNLOAD 85.01Mb/s
  UPLOAD 24.01Mb/s
  PING 131 ms
  SERVER NEW YORK CITY, NY

  http://www.speedtest.net/my-result/6375666714
  DOWNLOAD 53.70Mb/s
  UPLOAD 16.19Mb/s
  PING 205 ms
  SERVER SAN FRANCISCO, CA

  http://www.speedtest.net/my-result/6375685977
  DOWNLOAD 24.69Mb/s
  UPLOAD 13.46Mb/s
  PING 291 ms
  SERVER TOKYO


Maybe Atlas graphs also can help:
https://s8.hostingkartinok.com/uploads/images/2017/06/caaccae1a967a838871cdea5739e9b7d.png
https://s8.hostingkartinok.com/uploads/images/2017/06/60ff981f51002bd177e8c991748205cf.png


> Or:

> Change they relay's keys, wait a few weeks, and let us know if
> the bandwidth measurement is better or worse.

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 thing, which is

Re: [tor-relays] Consensus Weight calculation

2017-06-13 Thread teor

> On 14 Jun 2017, at 02:01, Vort  wrote:
> ...

>> But most relays get low weights because:
>> * they can not get enough CPU or RAM,
>> * they can not keep enough connections open,
> 
> This is not a case for relays with 1 KiB/s load.
> 
>> * they go up and down a lot,
> 
> My examples was for stable relays.
> 
>> * they change IP address a lot, or
> 
> ExoneraTor is lagging, but 3 of 4 example relays was using
>  the same addresses month ago.

Please help us find out which of these things impact one of your
relays.

>> * they do not get good bandwidth over time,
>> * they do not get good bandwidth to the rest of the tor network,
>> * they have high latency to the rest of the tor network,
> 
> This can be measured.

Yes, the Tor network measures it from 4 different locations every few
days. What makes your measurement is more accurate?

Where are you measuring from?
Is it close to the relay?
How long did it take to do the download?
Did you measure from different parts of the world?

> ...
>> But this isn't enough information to work out what the problem is.
>> Maybe there is a problem with the relay, not the measurements.
>> We just can't tell.
> 
> What additional information can help?

1. Choose a relay you control to focus on.
2. Send information about the relay's CPU and RAM and configured
   connection limit.
3. Measure the actual connection limit, bandwidth and latency from
   the rest of the Tor network. (Or from at least 2 locations in the
   US and Western Europe.)

Or:

Change they relay's keys, wait a few weeks, and let us know if
the bandwidth measurement is better or worse.

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.

>> Maybe the relay has low CPU, international bandwidth, or connection
>> limits. We just don't know.
> 
> If it can retranslate a lot of traffic, then it have no such problems.

I think we will have to agree to disagree about this.

> ...
>> These measurements are updated over time.
>> Please check again after a few weeks.
> 
> They already shows that relay is more capable than it is rated.

I think we will have to agree to disagree about this.

>> I think this spike means:
> 
>> "You think your provider is giving you 100 Mbps, but they are
>> actually giving you much less. Talk to them about it."
>> ...
> 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 say this values are "proportional" enough.

I think we will have to agree to disagree about this.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-13 Thread Vort

> We know of relays that have improved their bandwidth measurements by
> changing their keys (this resets the measurements).

1. It is not possible to change keys for relays which you don't control.
2. It is better to have such algorithms, which can't stuck.


> But most relays get low weights because:
> * they can not get enough CPU or RAM,
> * they can not keep enough connections open,

This is not a case for relays with 1 KiB/s load.

> * they go up and down a lot,

My examples was for stable relays.

> * they change IP address a lot, or

ExoneraTor is lagging, but 3 of 4 example relays was using
  the same addresses month ago.

> * they do not get good bandwidth over time,
> * they do not get good bandwidth to the rest of the tor network,
> * they have high latency to the rest of the tor network,

This can be measured.
For example, BD4354E76929C90B7004FF149A3C52189A3B4634 is capable of
  serving 1 MiB/s (was made a circuit through it this morning):

r Hedgehog vUNU52kpyQtwBP8UmjxSGJo7RjQ BG894JEWmT0pcLmWTabGYlWT5Iw 2017-06-13 
06:08:30 212.26.140.81 443 0
...
w Bandwidth=1024 Measured=5

> * some other reasons that make them less useful to clients.

Looks like clients have no influence on BwAuth's decisions.


> But this isn't enough information to work out what the problem is.
> Maybe there is a problem with the relay, not the measurements.
> We just can't tell.

What additional information can help?


> Maybe the relay has low CPU, international bandwidth, or connection
> limits. We just don't know.

If it can retranslate a lot of traffic, then it have no such problems.


> We would need to talk to the operator to find out.

I would not raised this question if I wasn't such an operator.


> These measurements are updated over time.
> Please check again after a few weeks.

They already shows that relay is more capable than it is rated.


> I think this spike means:

> "You think your provider is giving you 100 Mbps, but they are
> actually giving you much less. Talk to them about it."

> Usually this is because the provider only tries to give everyone
> 100Mbps, or they limit everyone and don't tell them, or they don't
> pay enough to get good international bandwidth.

Exact number does not matter.
The problem is 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 say this values are "proportional" enough.


-- Vort

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-12 Thread teor

> On 13 Jun 2017, at 00:58, Vort  wrote:
> ...
>> This is a question that gets asked a lot:
>> "Many people set up new fast relays and then wonder why their bandwidth
>> is not fully loaded instantly…"
>> https://blog.torproject.org/blog/lifecycle-of-a-new-relay
> 
> Maybe this is correct in many cases.
> But definitely not in all of them.
> 
> For example, this line:
> "once the bwauths have measured you and the directory authorities lift
>  the 20KB cap, you'll attract more and more traffic"
> Events can go other way: bwauths will assign lower weight, and relay
>  will be getting less and less traffic.

We know of relays that have improved their bandwidth measurements by
changing their keys (this resets the measurements).

But most relays get low weights because:
* they do not get good bandwidth over time,
* they do not get good bandwidth to the rest of the tor network,
* they have high latency to the rest of the tor network,
* they can not get enough CPU or RAM,
* they can not keep enough connections open,
* they go up and down a lot,
* they change IP address a lot, or
* some other reasons that make them less useful to clients.

Here is more information about this:
https://lists.torproject.org/pipermail/tor-relays/2016-November/010928.html

> ...
>> I'm not sure if this is a problem. And I'm not sure how many relays it
>> impacts.
> 
> Hundreds, I guess.
> 
> Here is some examples:
> 
> https://atlas.torproject.org/#details/9FC2673BB2704C2AAB851F8334938565DF1D0819
> Now used bandwidth: 1KiB/s
> Advertised Bandwidth: 131.38 KiB/s
> Top used bandwidth:   250KiB/s
> Bandwidth rate:  4000KiB/s

Here are the measurements from each bandwidth authority (large page):
https://consensus-health.torproject.org/consensus-health-2017-06-12-22-00.html#9FBEB75E8BC142565F12CBBE078D63310236A334

And look at other relays in the same AS:
https://atlas.torproject.org/#search/as:AS8100

But this isn't enough information to work out what the problem is.
Maybe there is a problem with the relay, not the measurements.
We just can't tell.

> ...
> As you can see, most of them can handle a lot more traffic: 50x-4000x.
> Also don't see why they can have high latency.
> Good relays, on my opinion.

Maybe the relay has low CPU, international bandwidth, or connection
limits. We just don't know.

We would need to talk to the operator to find out.

> ...
> I have launched my own instance of BwAuthority and I see, that measured
>  "filt_bw" values are pretty close to "Advertised Bandwidth":
> ...

These measurements are updated over time.
Please check again after a few weeks.

> The problem is on the next step, I think.
> 
>>> The result has revealed some anomalies:
>>> https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8eaf3deb0d28a.png
>>> First, and most important, - a lot of relays have bandwidth estimate
>>> in range 0-50: 1082 of them.
> 
>> I don't know what each axis is on this graph.
> 
> x is KiB/s, y is count
> (yellow bars are for "Advertised Bandwidth", blue - for
> "Consensus Weight", grey mean both values)
> ...
> 
>>> Second - there are incorrect estimates
>>> for popular bandwidths of 5, 10 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 = ~1200.
> Low blue bars at the same point means that "Consensus Weight" model
>  did not take into account that there are many 1200 KiB/s nodes on
>  the network, which will result in theirs underload.

The consensus weight model does not fit relays to a curve.
It can have lots of relays at the same bandwidth.

I think this spike means:

"You think your provider is giving you 100 Mbps, but they are
actually giving you much less. Talk to them about it."

Usually this is because the provider only tries to give everyone
100Mbps, or they limit everyone and don't tell them, or they don't
pay enough to get good international bandwidth.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-12 Thread Vort

> Thanks for writing to us.

Thanks for the answers.


> This is a question that gets asked a lot:
> "Many people set up new fast relays and then wonder why their bandwidth
> is not fully loaded instantly…"
> https://blog.torproject.org/blog/lifecycle-of-a-new-relay

Maybe this is correct in many cases.
But definitely not in all of them.

For example, this line:
"once the bwauths have measured you and the directory authorities lift
  the 20KB cap, you'll attract more and more traffic"
Events can go other way: bwauths will assign lower weight, and relay
  will be getting less and less traffic.


> It can take a week or two for the bandwidth authorities to measure a
> relay.

Relay, which hit the problem, can be in underpowered state for months.


> I'm not sure if this is a problem. And I'm not sure how many relays it
> impacts.

Hundreds, I guess.

Here is some examples:

https://atlas.torproject.org/#details/9FC2673BB2704C2AAB851F8334938565DF1D0819
Now used bandwidth: 1KiB/s
Advertised Bandwidth: 131.38 KiB/s
Top used bandwidth:   250KiB/s
Bandwidth rate:  4000KiB/s

https://atlas.torproject.org/#details/B918EB3FA4D03A4F9F632AA17F217A6C04044EF7
Now used bandwidth: 1KiB/s
Advertised Bandwidth:  82.65 KiB/s
Top used bandwidth:   245KiB/s
Bandwidth rate:   800KiB/s

https://atlas.torproject.org/#details/DF1C6C645C5854780778A3E81D12F2A8FF65744B
Now used bandwidth: 1KiB/s
Advertised Bandwidth:  62.29 KiB/s
Top used bandwidth: 7KiB/s
Bandwidth rate:  3000KiB/s

https://atlas.torproject.org/#details/E2AF5879F39FF40DF8994E9B8FAEAB2518AEEBA4
Now used bandwidth: 1KiB/s
Advertised Bandwidth:  70.94 KiB/s
Top used bandwidth:   916KiB/s
Bandwidth rate:  1000KiB/s


As you can see, most of them can handle a lot more traffic: 50x-4000x.
Also don't see why they can have high latency.
Good relays, on my opinion.


> But we know there is a bias in Tor's measurements towards North America
> and Europe, because that's where most of the measurements are made from:

No, this have no impact in this case.

I have launched my own instance of BwAuthority and I see, that measured
  "filt_bw" values are pretty close to "Advertised Bandwidth":

node_id=$9FC2673BB2704C2AAB851F8334938565DF1D0819 nick=qq strm_bw=52732 
filt_bw=77967 circ_fail_rate=0.0 desc_bw=134537 ns_bw=13000
node_id=$9FC2673BB2704C2AAB851F8334938565DF1D0819 nick=qq strm_bw=61278 
filt_bw=70430 circ_fail_rate=0.0 desc_bw=85495 ns_bw=13000
node_id=$B918EB3FA4D03A4F9F632AA17F217A6C04044EF7 nick=TranTor strm_bw=40485 
filt_bw=47052 circ_fail_rate=0.0 desc_bw=84635 ns_bw=12000

The problem is on the next step, I think.


>> The result has revealed some anomalies:
>>  
>> https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8eaf3deb0d28a.png
>> First, and most important, - a lot of relays have bandwidth estimate
>>  in range 0-50: 1082 of them.

> I don't know what each axis is on this graph.

x is KiB/s, y is count
(yellow bars are for "Advertised Bandwidth", blue - for
 "Consensus Weight", grey mean both values)

> 20 is the default, 50 is the maximum for a relay's self-test.
> If a relay isn't measured, or measures very low, it usually gets a
> figure in this range.

I have excluded non-measured relays from this histogram.

>> Second - there are incorrect estimates
>>  for popular bandwidths of 5, 10 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 = ~1200.
Low blue bars at the same point means that "Consensus Weight" model
  did not take into account that there are many 1200 KiB/s nodes on
  the network, which will result in theirs underload.


-- Vort

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus Weight calculation

2017-06-10 Thread teor

Hi,

Thanks for writing to us. This is a question that gets asked a lot:

"Many people set up new fast relays and then wonder why their bandwidth
is not fully loaded instantly…"

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

I'll give short answers below, see the link for details.

> On 11 Jun 2017, at 15:33, Vort  wrote:
> 
> Hello.
> 
> Recently I have decided to create a new relay.
> After several days of waiting, I have realized that decision of
>  Bandwidth Authorities, that my bandwidth is 1000 times lower
>  than it should be, is pretty stable.

It can take a week or two for the bandwidth authorities to measure a
relay.

> That is bad on its own, but I was wandering - how many other relays
>  suffers from the same problem?
> Since all network data is open to analysis, I have decided to
>  calculate some statistics.
> As "Consensus Weight", theoretically, should correspond to relay's
>  bandwidth, first thought was to compare it with "Advertised Bandwidth"
>  value (assuming there not too many liars on the network).

The advertised bandwidth is the maximum a relay has seen itself use for
10 seconds in the past day or so.

The consensus weight is the median measured bandwidth over weeks for the
relay from 3-5 different bandwidth authorities.

> The result has revealed some anomalies:
>  
> https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8eaf3deb0d28a.png
> First, and most important, - a lot of relays have bandwidth estimate
>  in range 0-50: 1082 of them.

I don't know what each axis is on this graph.

20 is the default, 50 is the maximum for a relay's self-test.

If a relay isn't measured, or measures very low, it usually gets a
figure in this range.

> Second - there are incorrect estimates
>  for popular bandwidths of 5, 10 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?

> Next question was: what estimates was actually assigned to that
>  bandwidth spikes? Maybe all zeroes? This led me to another charts:
>  
> https://s8.hostingkartinok.com/uploads/images/2017/06/8cefb70fce667a1b89c783ed2bfc9442.png
>  
> https://s8.hostingkartinok.com/uploads/images/2017/06/2e42634ea3f9b71df8a7fd17c27660d9.png
>  x here is "Advertised Bandwidth", y is "Consensus Weight".
> I was expected to see something close to x = y line.

Thanks for doing these graphs!
They look as close to the x = y line as I would expect.
It doesn't surprise me that there is bias at the lower end.
This is less important than bias or variance at the high end.

> But result was
>  much worse. First problem (not too important) is a lot of randomness.
>  5 MiB relay can be easily detected as 1 MiB or 10 MiB.

This is normal: what a relay sees as its own maximum bandwidth is often
different from the sustained bandwidth the tor network can get out of
it.

> Second one is a thing, which, probably, steals a lot of available network
>  bandwidth: relays with low "Advertised Bandwidth" gets much less
>  traffic than they can handle. Almost no relay with speed < 500 KiB
>  is rated correctly. Similarly, high-speed relays have higher weight
>  than needed.

This is good for clients: high speed relays give low latencies.

> 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.

Bandwidth does not add in a simple way: we are trying to minimise the
bandwidth-delay product for clients, not maximise the bandwidth used.

Overloaded relays are slow, and under-used fast, nearby relays are a
waste. But this is hard to detect.

> Do anyone have ideas how to solve this problem?

I'm not sure if this is a problem. And I'm not sure how many relays it
impacts.

But we know there is a bias in Tor's measurements towards North America
and Europe, because that's where most of the measurements are made from:

https://trac.torproject.org/projects/tor/wiki/doc/BandwidthAuthorityMeasurements

We are working on fixing this by measuring from different places.
It will also help if we get more bandwidth authorities.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org

signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus Weight calculation

2017-06-10 Thread Vort

Hello.

Recently I have decided to create a new relay.
After several days of waiting, I have realized that decision of
Bandwidth Authorities, that my bandwidth is 1000 times lower
than it should be, is pretty stable.

That is bad on its own, but I was wandering - how many other relays
suffers from the same problem?
Since all network data is open to analysis, I have decided to
calculate some statistics.
As "Consensus Weight", theoretically, should correspond to relay's
bandwidth, first thought was to compare it with "Advertised Bandwidth"
value (assuming there not too many liars on the network).
The result has revealed some anomalies:

https://s8.hostingkartinok.com/uploads/images/2017/06/fed1cf8b57fc027223c8eaf3deb0d28a.png
First, and most important, - a lot of relays have bandwidth estimate
in range 0-50: 1082 of them. Second - there are incorrect estimates
for popular bandwidths of 5, 10 and 20 MBits.
Next question was: what estimates was actually assigned to that
bandwidth spikes? Maybe all zeroes? This led me to another charts:

https://s8.hostingkartinok.com/uploads/images/2017/06/8cefb70fce667a1b89c783ed2bfc9442.png

https://s8.hostingkartinok.com/uploads/images/2017/06/2e42634ea3f9b71df8a7fd17c27660d9.png
x here is "Advertised Bandwidth", y is "Consensus Weight".
I was expected to see something close to x = y line. But result was
much worse. First problem (not too important) is a lot of randomness.
5 MiB relay can be easily detected as 1 MiB or 10 MiB.
Second one is a thing, which, probably, steals a lot of available network
bandwidth: relays with low "Advertised Bandwidth" gets much less
traffic than they can handle. Almost no relay with speed < 500 KiB
is rated 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.

Do anyone have ideas how to solve this problem?

-- Vort

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] consensus-health

2017-01-03 Thread David Goulet

On 03 Jan (18:24:07), Felix wrote:
> https:// consensus-health.torproject.org/
> (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00)
> shows
> * dannenberg: Missing entirely from consensus

The ed25519 key of dannenberg expired so it has to be fixed to resolved
the situation. I believe Andreas has been notified already of this.

> * faravahar: Missing Signature! Valid-after time of auth's displayed
> consensus: 2017-01-03 15:00:00

This will continue to be as long as faravahar doesn't update to 0.2.9.8+
as it's not understanding the consensus-method that the other dirauth
have voted on.

> * moria1: Sees only 2620 relays running

This is still a mystery... this happens sometimes when moria1 is run
under valgrind or maybe some network issues. Or maybe some bug in 0.3.0
so we'll see about it.

Cheers!
David

> 
> Is https://
> lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html
> ok ?
> 
> -- 
> imho - like always
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] consensus-health

2017-01-03 Thread Felix


https:// consensus-health.torproject.org/
(observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00)
shows
* dannenberg: Missing entirely from consensus
* faravahar: Missing Signature! Valid-after time of auth's displayed 
consensus: 2017-01-03 15:00:00

* moria1: Sees only 2620 relays running

Is https:// 
lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html 
ok ?


--
imho - like always
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight fraction dropping

2015-04-08 Thread James Murphy

I too am experiencing a recent and significant drop in bandwidth, and
have previously had problems gaining and losing the guard flag
repeatedly (though not recently).

I wonder if these issues are somehow connected, or if there is some kind
of new attack/exploit that decreases relay consensus to allow e.g. a
Sybil attack to be more viable.

https://atlas.torproject.org/#details/18EAAF7CB6C2ABE8583841D305C06A509F8C1C82

On 04/08/2015 04:03 PM, Tim Sammut wrote:
> Hi.
>
> My relatively new, non-exit relay has seen its consensus weight fraction
> drop and a corresponding substantial drop in traffic.
>
> https://atlas.torproject.org/#details/83F56335F5E3615B8855EEC7AA5D6A0BAD010C56
>
> It briefly had and then lost the guard flag, so I don't believe the drop
> as described in [1]. Is it being affected by the bwauth issues talked
> about in [2] and [3]? If so, is there a remedy?
>
> Thank you!
>
> [1] https://blog.torproject.org/blog/lifecycle-of-a-new-relay
> [2]
> http://tor.stackexchange.com/questions/4913/my-exit-node-suddenly-lost-all-of-its-consensus-weight-i-dont-know-where-to-st
> [3]
> https://lists.torproject.org/pipermail/tor-relays/2015-January/006055.html
>
> hope you are well
> t
>

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus weight fraction dropping

2015-04-08 Thread Tim Sammut

Hi.

My relatively new, non-exit relay has seen its consensus weight fraction
drop and a corresponding substantial drop in traffic.

https://atlas.torproject.org/#details/83F56335F5E3615B8855EEC7AA5D6A0BAD010C56

It briefly had and then lost the guard flag, so I don't believe the drop
as described in [1]. Is it being affected by the bwauth issues talked
about in [2] and [3]? If so, is there a remedy?

Thank you!

[1] https://blog.torproject.org/blog/lifecycle-of-a-new-relay
[2]
http://tor.stackexchange.com/questions/4913/my-exit-node-suddenly-lost-all-of-its-consensus-weight-i-dont-know-where-to-st
[3]
https://lists.torproject.org/pipermail/tor-relays/2015-January/006055.html

hope you are well
t

-- 
Tim Sammut ~ @t1msammut ~ t...@teamsammut.com
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus dropped after 0.2.6.3-alpha upgrade

2015-03-08 Thread relayops

I haven't, is there a way for me to check to see if they're throttling me?
I suspect "are you throttling my tor relay" may fall on deaf ears of their
support.

This happened very soon after the upgrade to 0.2.6.3 which makes me
suspect that but that could be a coincidence.


> You checked with plusnet? I thought they were good but they still
> might've meddled without your permission and blocked your tor traffic.
>
> On 07/03/15 12:08, relay...@mail2tor.com wrote:
>> Any ideas why? Slowly dropped after upgrading.
>>
>> https://atlas.torproject.org/#details/113FCC01A29B4600A8BAA1CB72E6AB1FD899AC92
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus dropped after 0.2.6.3-alpha upgrade

2015-03-07 Thread Corey Wood

You checked with plusnet? I thought they were good but they still
might've meddled without your permission and blocked your tor traffic.

On 07/03/15 12:08, relay...@mail2tor.com wrote:
> Any ideas why? Slowly dropped after upgrading.
> 
> https://atlas.torproject.org/#details/113FCC01A29B4600A8BAA1CB72E6AB1FD899AC92
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Consensus dropped after 0.2.6.3-alpha upgrade

2015-03-07 Thread relayops

Any ideas why? Slowly dropped after upgrading.

https://atlas.torproject.org/#details/113FCC01A29B4600A8BAA1CB72E6AB1FD899AC92

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

2015-01-31 Thread Network Operations Center

What if one were to shut down the node for several days and then restart 
it. Wouldnt that maybe prompt the network to "rescan" the node?


On 31.01.2015 10:48 PM, Josef 'veloc1ty' Stautner wrote:

Hello List,

at this point I want to thank Bram de Boer for spending an unmetered
server. Dediacted servers with unmetered network is not cheap and 
should

be treated differently as a virtual server at OVH.
I can totally agree why he is disappointed about that.

Just deleting the identity is not a solution for me. The identity of a
server is also a certificate of the spend effort. If something like 
that

would happen to my relays I would be out of here. Especially I'm not
using Tor at all but want to help people who can not access the web 
like

I can do.

I recently tried to check why the consensus dropped by reviewing the
votes data and digged into the source but my knowledge about that is 
far

below the average. So I hope someone with more knowledge is reviewing
this case and post a solution or declare it as a general probleme and
write a bug report.

~Josef

Am 31.01.2015 um 22:35 schrieb Network Operations Center:

2)
This link has been posted:
http://freehaven.net/~arma/moria1-v3-status-votes
which is a collection of all 9 BWauth nodes. Currently there is
nothing a node operator can do bar deleting his keys. Atleast no other
solution has been posted in this thread.

On 31.01.2015 10:23 PM, starlight.201...@binnacle.cx wrote:

At 21:51 1/31/2015 +0100, you wrote:

This has already been done.


Implicit in my post is that

1) about 10 days have passed, so recent
data is more relevant than the earlier
work, especially an one BWauth operator
stated his node should be doing better;
and

2) no precise mention of how to obtain
the data was posted earlier and doing
so might enable Bram de Boer to examine
and track the situation directly.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

At 22:35 1/31/2015 +0100, Network Operations Center wrote:
>This link has been posted: 
>http://freehaven.net/~arma/moria1-v3-status-votes
>which is a collection of all 9 BWauth nodes.

This looks like the data from just
one BWauth, 'moria1'.

The full time series for the _four_ BWauth
votes is included along with the five other
consensus authorities, all found here

https://collector.torproject.org/recent/relay-descriptors/votes/

A link which was not previously posted
and which is a bit hard to find.  I can
find it because I remember the data
is in there somewhere, having used
it before the site was restructured.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

2015-01-31 Thread Josef 'veloc1ty' Stautner

Hello List,

at this point I want to thank Bram de Boer for spending an unmetered
server. Dediacted servers with unmetered network is not cheap and should
be treated differently as a virtual server at OVH.
I can totally agree why he is disappointed about that.

Just deleting the identity is not a solution for me. The identity of a
server is also a certificate of the spend effort. If something like that
would happen to my relays I would be out of here. Especially I'm not
using Tor at all but want to help people who can not access the web like
I can do.

I recently tried to check why the consensus dropped by reviewing the
votes data and digged into the source but my knowledge about that is far
below the average. So I hope someone with more knowledge is reviewing
this case and post a solution or declare it as a general probleme and
write a bug report.

~Josef

Am 31.01.2015 um 22:35 schrieb Network Operations Center:
> 2)
> This link has been posted:
> http://freehaven.net/~arma/moria1-v3-status-votes
> which is a collection of all 9 BWauth nodes. Currently there is
> nothing a node operator can do bar deleting his keys. Atleast no other
> solution has been posted in this thread.
>
> On 31.01.2015 10:23 PM, starlight.201...@binnacle.cx wrote:
>> At 21:51 1/31/2015 +0100, you wrote:
>>> This has already been done.
>>
>> Implicit in my post is that
>>
>> 1) about 10 days have passed, so recent
>> data is more relevant than the earlier
>> work, especially an one BWauth operator
>> stated his node should be doing better;
>> and
>>
>> 2) no precise mention of how to obtain
>> the data was posted earlier and doing
>> so might enable Bram de Boer to examine
>> and track the situation directly.
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

2015-01-31 Thread Network Operations Center


2)
This link has been posted: 
http://freehaven.net/~arma/moria1-v3-status-votes
which is a collection of all 9 BWauth nodes. Currently there is nothing 
a node operator can do bar deleting his keys. Atleast no other solution 
has been posted in this thread.


On 31.01.2015 10:23 PM, starlight.201...@binnacle.cx wrote:

At 21:51 1/31/2015 +0100, you wrote:

This has already been done.


Implicit in my post is that

1) about 10 days have passed, so recent
data is more relevant than the earlier
work, especially an one BWauth operator
stated his node should be doing better;
and

2) no precise mention of how to obtain
the data was posted earlier and doing
so might enable Bram de Boer to examine
and track the situation directly.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

At 21:51 1/31/2015 +0100, you wrote:
>This has already been done.

Implicit in my post is that

1) about 10 days have passed, so recent
data is more relevant than the earlier
work, especially an one BWauth operator
stated his node should be doing better;
and

2) no precise mention of how to obtain
the data was posted earlier and doing
so might enable Bram de Boer to examine
and track the situation directly.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

2015-01-31 Thread Network Operations Center

This has already been done. And I was under the impression that things 
would be changing soon. I still find it weird that the network is 
ignoring several nodes.


On 31.01.2015 09:23 PM, starlight.201...@binnacle.cx wrote:

At 20:54 1/31/2015 +0100, you wrote:

Consensus weight of my relays and those of others
is still near zero, and not improving. . .


I read the earlier discussion around this
issue with interest.  Have no specific
ideas about resolving the problem, but
I can recommend pulling the raw text
data files for the authority votes,
grep'ping your nodes, and looking at
the specific BWauth votes over time.

The data is found here

https://collector.torproject.org/archive/relay-descriptors/votes/

and while the files are a bit huge,
are easy to whack at with *nix
command line tools such as
egrep/awk/sed/perl etc.  In a
pinch one might apply Excel to the
problem, but first trim the data
set down to size with a grep or your
desktop and Excel will choke and
die.

I did this at the point where the
bandwidth for election to guard
status was increased greatly and
my node was shipped off to middle-
relay mediocrity.  Could see
clearly how it all transpired, but
of course I could do nothing about
it short of spending more $$ on
bandwidth.

With the raw data in hand, it will
be easier to campaign the operators
of the troublesome BWauths to correct
the problem.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped

also, for recent data. . .

https://collector.torproject.org/recent/

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Consensus weight dropped