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.
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.2015q1@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
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.
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.2015q1@binnacle.cx wrote:
At 21:51 1/31/2015 +0100, you wrote:
This has already been done.
Implicit in my post is that
- 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
- 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
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:
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.2015q1@binnacle.cx wrote:
At 21:51 1/31/2015 +0100, you wrote:
This has already been done.
Implicit in my post is that
- 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
- 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
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:
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.2015q1@binnacle.cx wrote:
At 21:51 1/31/2015 +0100, you wrote:
This has already been done.
Implicit in my post is that
- 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
- 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
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@lists.torproject.org
-
Josef 'veloc1ty' Stautner -
Network Operations Center -
starlight.2015q1＠binnacle.cx