Re: [tor-relays] uptime and connections for my middle node relay
On 01/20/2015 12:04 AM, Malte Ketelsen wrote: > Hi, > I am running a relay about 5-6 weeks. > I have read the 'lifecycle-of-a-new-relay' and I am not over the 86 days, > but I still wonder me, at most, I have only inbound connections. > Sometimes outbound too, but rarely. > Can someone tell me why? > > And I have another question: > Can someone tell me how many hours a day uptime is minimum requirement > for a standard middle relay? > I have reed many posts, but there are not a exactly answer. > > Sorry for my english ... > greets Malte If everything were well, your relay would be fully mature by now. It would have been carrying significant bandwidth within a few days. Have you checked whether your firewall is blocking the outgoing connections? Either your system or your ISP's could be blocking certain ports. 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] uptime and connections for my middle node relay
Hi, I am running a relay about 5-6 weeks. I have read the 'lifecycle-of-a-new-relay' and I am not over the 86 days, but I still wonder me, at most, I have only inbound connections. Sometimes outbound too, but rarely. Can someone tell me why? And I have another question: Can someone tell me how many hours a day uptime is minimum requirement for a standard middle relay? I have reed many posts, but there are not a exactly answer. Sorry for my english ... greets Malte ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Mismatched fingerprints
Thanks all for your replies… this helps. Makes sense why the non-hashed fingerprint isn’t shown. Glad to know I was just misunderstanding the info on Globe/Atlas. I was worried there was something wrong with my node. -Pat > On Jan 19, 2015, at 1:39 AM, Karsten Loesing wrote: > > Signed PGP part > On 18/01/15 19:02, Patrick Scharmer wrote: > > Hi, > > > > I’ve been running a bridge for over a year and noticed recently > > that the fingerprint shown in ARM (and that actually works when > > connecting to the bridge) differs from the fingerprint displayed > > for my bridge on both Atlas and Globe. Any thoughts on why this > > would happen and how to fix it? I’m assuming the fingerprint > > published on Atlas & Globe is the same fingerprint that will be > > distributed by bridges.torproject, is that correct? > > arm displays your bridge's fingerprint, which is also distributed by > bridges.torproject.org. > > Atlas and Globe show your bridge's *hashed* fingerprint. The reason > that they're not showing the (non-hashed) fingerprint is that anyone > could ask the bridge authority for your bridge's current descriptor if > they had its (non-hashed) fingerprint, and that would reveal your > bridge's IP address. That's why Atlas and Globe hash your fingerprint. > > > Apologies if this is a common question… I’ve only recently joined > > the mailing list and couldn’t find a way to search the archives > > other than browsing. > > It's a valid question. If you have any ideas how to explain it better > on Atlas or Globe, please open a ticket. Thanks! > > All the best, > Karsten > > ___ > 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] MiB/s / metrics
+1 grarpamp bits with decimal prefixes is the only thing that makes sense in the networking world. On 20 Jan 2015 00:09, "grarpamp" wrote: > On Mon, Jan 19, 2015 at 5:55 AM, Sebastian Urbach > wrote: > > I opened a ticket recently with the intention to use a more common unit > than > > MiB/s for metrics. Karsten basically agrees but is waiting for more > input. > > > > https://trac.torproject.org/projects/tor/ticket/14257 > > Tor is at its core a network application, an interface to the > network, a router. In the real ISP world therein everyone speaks > in "mega bits per second" "10^n" (and now with 100Gbps > links, in Gbps). > > Only the downstream hosting world speaks in "mega bytes" > "2^n", "per" "whatever time unit they dream up". This comes > from attempts by hosters to appease people pushing their > disk files MiB's over the net at link rate, not spread over bandwidth > rate. In fact, the hosters have to convert that appeasement on their > backend to aggregated Mbps so they can talk to their real ISP's. > > I've suggested before that Tor project should use Mbit/s (or Mbps > or Mbit[s] where the slash presents a problem) as its primary default > representation for Tor client and all related projects that refer to > bandwidth. > Tor is a bandwidth app, especially at the relay level. There is no disk or > instantaneous link rate transfer need applying to Tor relay. (As opposed > to user level which is more of a mashup of rate usage contexts and > interests similar to bittorrent/webserving.) > > Then if people want MiB's or MB's so they can continue perpetuating > and interfacing with hosters who do the same, you could add a > few global prefix, unit and time options to switch all representations > over at once. (Tor client has recently added per stanza Mbps > configs which is a fine alternative to global. Yet again, the manpage > and even maybe the code still uses nonsense in regards to capitalization, > base 2 vs 10, crossed contexts, etc...) > > Start here, use the table in the upper right, ignore jedec, > and pick and apply 10^n or 2^n representations consistantly. > https://en.wikipedia.org/wiki/Binary_prefix > > " > BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits >A token bucket limits the average incoming bandwidth usage on > this >node to the specified number of bytes per second, and the > average >outgoing bandwidth usage to that same value. If you want to run > a >relay in the public network, this needs to be at the very least > 30 >KBytes (that is, 30720 bytes). (Default: 1 GByte) > Notably, "KBytes" can also be written as "kilobytes" or "kb"; > " > > No, "KBytes" is invalid, there is no capital "K", only "k (SI)" and > "Ki (binary)". > Nor is "b" ever a byte, nor is "Bit[s]" ever capitalized. > True network applications should also not be crossing network-like prefixes > with disk-like objects or vice versa, ie: "Gibit[s] (non-network > binary and single bit)", > or the "GBytes (network SI and binary multiples of bit)" above. > If you cross it up or make errors in context in one place that throws all > your > docs and configs into question. Even I still mess it up sometimes. > > " > it's easy to forget that "B" means bytes, not bits. > " > > Nope :) Abbr "B" means "byte" (now formally of width eight bits as in > "octet/o", > and still unfortunately caveat "bel/B" as in "dB"), and abbr "bit" means > "bit", > (and "b" is now just nothing but informal efficient shorthand for > "bit" if I recall). > > https://en.wikipedia.org/wiki/IEC_8-13 > https://en.wikipedia.org/wiki/Byte > https://en.wikipedia.org/wiki/Octet_(computing) > https://en.wikipedia.org/wiki/Bit > > Anyway, tor relay is network not disk, so I'd suggest megabits, > or kilo/giga as scale appropriate. > ___ > 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] MiB/s / metrics
On Mon, Jan 19, 2015 at 5:55 AM, Sebastian Urbach wrote: > I opened a ticket recently with the intention to use a more common unit than > MiB/s for metrics. Karsten basically agrees but is waiting for more input. > > https://trac.torproject.org/projects/tor/ticket/14257 Tor is at its core a network application, an interface to the network, a router. In the real ISP world therein everyone speaks in "mega bits per second" "10^n" (and now with 100Gbps links, in Gbps). Only the downstream hosting world speaks in "mega bytes" "2^n", "per" "whatever time unit they dream up". This comes from attempts by hosters to appease people pushing their disk files MiB's over the net at link rate, not spread over bandwidth rate. In fact, the hosters have to convert that appeasement on their backend to aggregated Mbps so they can talk to their real ISP's. I've suggested before that Tor project should use Mbit/s (or Mbps or Mbit[s] where the slash presents a problem) as its primary default representation for Tor client and all related projects that refer to bandwidth. Tor is a bandwidth app, especially at the relay level. There is no disk or instantaneous link rate transfer need applying to Tor relay. (As opposed to user level which is more of a mashup of rate usage contexts and interests similar to bittorrent/webserving.) Then if people want MiB's or MB's so they can continue perpetuating and interfacing with hosters who do the same, you could add a few global prefix, unit and time options to switch all representations over at once. (Tor client has recently added per stanza Mbps configs which is a fine alternative to global. Yet again, the manpage and even maybe the code still uses nonsense in regards to capitalization, base 2 vs 10, crossed contexts, etc...) Start here, use the table in the upper right, ignore jedec, and pick and apply 10^n or 2^n representations consistantly. https://en.wikipedia.org/wiki/Binary_prefix " BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits A token bucket limits the average incoming bandwidth usage on this node to the specified number of bytes per second, and the average outgoing bandwidth usage to that same value. If you want to run a relay in the public network, this needs to be at the very least 30 KBytes (that is, 30720 bytes). (Default: 1 GByte) Notably, "KBytes" can also be written as "kilobytes" or "kb"; " No, "KBytes" is invalid, there is no capital "K", only "k (SI)" and "Ki (binary)". Nor is "b" ever a byte, nor is "Bit[s]" ever capitalized. True network applications should also not be crossing network-like prefixes with disk-like objects or vice versa, ie: "Gibit[s] (non-network binary and single bit)", or the "GBytes (network SI and binary multiples of bit)" above. If you cross it up or make errors in context in one place that throws all your docs and configs into question. Even I still mess it up sometimes. " it's easy to forget that "B" means bytes, not bits. " Nope :) Abbr "B" means "byte" (now formally of width eight bits as in "octet/o", and still unfortunately caveat "bel/B" as in "dB"), and abbr "bit" means "bit", (and "b" is now just nothing but informal efficient shorthand for "bit" if I recall). https://en.wikipedia.org/wiki/IEC_8-13 https://en.wikipedia.org/wiki/Byte https://en.wikipedia.org/wiki/Octet_(computing) https://en.wikipedia.org/wiki/Bit Anyway, tor relay is network not disk, so I'd suggest megabits, or kilo/giga as scale appropriate. ___ 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
Karsten wrote: > Did you check whether the consensus weight *fraction* also > dropped? Yes, it dropped from 0.193553% to 0.00% > If all consensus weights dropped by a certain factor, > there's no change in the probability of clients choosing > your relay at all. My relay used to push 80 Mbps, now it is doing 0.05 Mbps, so I am very certain the probability of clients choosing my relay has changed! Thanks, Bram ___ 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
Yes, fraction dropped from 0,2% to 0.72% On 19.01.2015 08:45 PM, Karsten Loesing wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/01/15 20:14, Bram de Boer wrote: Sebastian wrote: One theory might be that the addition of a new bwauth has shifted which vote gets picked for the consensus. It's conceivable that bwauths rate relays which are placed topologically close higher than others. Thank you for your suggestion. I hope that is not the case and the drop in consensus weight is just a temporary glitch. I will post to the development mailing list to see if the techies can comment on this. Paying hundreds of dollars of my hard earned money for a relay that is not being used by the network is not something I will keep doing for long. I support the goals and ideology of Tor, but the project will lose me as a volunteer if consensus weight does not restore soon. Did you check whether the consensus weight *fraction* also dropped? If all consensus weights dropped by a certain factor, there's no change in the probability of clients choosing your relay at all. Take a look at Atlas' or Globe's consensus weight fraction graphs and see if they changed over the past weeks or months. All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUvV7zAAoJEJd5OEYhk8hIvWgIAJi002cwqJbZv03t67QGCs1L DlNt50+i00zoIaYw7eVZV5F6DtkO1WRRR9VRBHgfufz2q5xj1YccR5a/mMdtZvVV T1PT0b1lXox7Hhogj7SKuvYKTbpgbTZh0WIq66ysoMBS8LqY0ZFcwiLZQs9fwo/J D1F/xsPZzjgm3GiBktmQH479LZT588Y8qzt3LGpKBpu2aXQF81YLv8plbJAo9Oh7 atD4xTZlSpA7MntJ7Rnn67aChaYDn2QgERWH+b04rloU9NGhmkBXuDZxBBb4/EWo ShxOshZRNRlcicbbm8dcaHdEVpnxi1Pl7ztidkoK2jYxOSnAqVfkayWpW7BjiIs= =4doV -END PGP SIGNATURE- ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/01/15 20:14, Bram de Boer wrote: > Sebastian wrote: >> One theory might be that the addition of a new bwauth has >> shifted which vote gets picked for the consensus. It's >> conceivable that bwauths rate relays which are placed >> topologically close higher than others. > > Thank you for your suggestion. I hope that is not the case and the > drop in consensus weight is just a temporary glitch. I will post to > the development mailing list to see if the techies can comment on > this. > > Paying hundreds of dollars of my hard earned money for a relay that > is not being used by the network is not something I will keep doing > for long. I support the goals and ideology of Tor, but the project > will lose me as a volunteer if consensus weight does not restore > soon. Did you check whether the consensus weight *fraction* also dropped? If all consensus weights dropped by a certain factor, there's no change in the probability of clients choosing your relay at all. Take a look at Atlas' or Globe's consensus weight fraction graphs and see if they changed over the past weeks or months. All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUvV7zAAoJEJd5OEYhk8hIvWgIAJi002cwqJbZv03t67QGCs1L DlNt50+i00zoIaYw7eVZV5F6DtkO1WRRR9VRBHgfufz2q5xj1YccR5a/mMdtZvVV T1PT0b1lXox7Hhogj7SKuvYKTbpgbTZh0WIq66ysoMBS8LqY0ZFcwiLZQs9fwo/J D1F/xsPZzjgm3GiBktmQH479LZT588Y8qzt3LGpKBpu2aXQF81YLv8plbJAo9Oh7 atD4xTZlSpA7MntJ7Rnn67aChaYDn2QgERWH+b04rloU9NGhmkBXuDZxBBb4/EWo ShxOshZRNRlcicbbm8dcaHdEVpnxi1Pl7ztidkoK2jYxOSnAqVfkayWpW7BjiIs= =4doV -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New Arris TG1672 Cable Modem, relay not reachable...help!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/19/2015 10:45 AM, kbesig wrote: > > On 01/18/2015 02:18 PM, Kurt Besig wrote: >> I'm trying to narrow down my connectivity problem and am >> wondering if anyone is runniing a relay, or knows of someone >> successfully running a relay, that is currently using TWC's new >> Arris TG1672 modem. > Thanks ___ tor-relays > mailing list tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > [Solved] After more research I found TWC's new Arris TG1672 modem must be set to "Bridged" mode to allow for port forwarding, problem solved! when I called tech support they did want to know why I needed to forward ports and acted slightly suspicious,but after I told them I run several services that need forwarding they where fine with it and didn't ask for any specifics regarding my "services". Thanks to Sebastian Urbach for all the help in pointing me in the correct direction. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUvV52AAoJEJQqkaGlFNDP03cH/A9EhZ+gEx7Y/TXTJzDTetK1 QgMyJ82+fZI2kYtxJ2/Yh0yWSTGFjxnH//QYXnBtd/BW1UhNajZjJy5woavpJdjO d9X9RFa6NCYPachTiYMBIIvxOcqEqweFSt4THIHSJL2LWl2uxKrO7Y+ZGfHF2n5Y dvwUiGfI/4gUKPAh82Ihp1FADTHMxm89X4Yia2n2WwXKt46upVK+b/1vIekj6q3m uZTNKqUOiY8X6ESVgC2TZ5DG9Y2LnnYccu5ydXXJGiJ1CMWIBw/rjROoCEBLXsXb Udw0zemHocB4HqcpalLHzX+9Eekv5OtSi41bUobRBzWfS6etniVfR2EwKceSI+k= =mXqv -END PGP SIGNATURE- --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ 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
I concur. Maybe it's worth to also post to the bugtracker? On 19.01.2015 08:14 PM, Bram de Boer wrote: Sebastian wrote: One theory might be that the addition of a new bwauth has shifted which vote gets picked for the consensus. It's conceivable that bwauths rate relays which are placed topologically close higher than others. Thank you for your suggestion. I hope that is not the case and the drop in consensus weight is just a temporary glitch. I will post to the development mailing list to see if the techies can comment on this. Paying hundreds of dollars of my hard earned money for a relay that is not being used by the network is not something I will keep doing for long. I support the goals and ideology of Tor, but the project will lose me as a volunteer if consensus weight does not restore soon. Thanks, Bram Hey there, On 19 Jan 2015, at 10:03, eric gisse wrote: This is roughly consistent with what I've been seeing on my own node. Weird. On Mon, Jan 19, 2015 at 1:31 AM, Bram de Boer wrote: Update: generation of the http://nosur.com/consensus.txt list has completed now, and contains 3683 relays that exist half a year or more. Again the relays at the top of the list show the sharp drop in consensus weight end of december and a short spike around January 6th. figuring out what happened will likely involve looking at the directory authority votes to see if anything specific happened. One theory might be that the addition of a new bwauth has shifted which vote gets picked for the consensus. It's conceivable that bwauths rate relays which are placed topologically close higher than others. I'm looking forward to any analysis someone might do on this. Cheers Sebastian ___ 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
Sebastian wrote: > One theory might be that the addition of a new bwauth has shifted > which vote gets picked for the consensus. It's conceivable that > bwauths rate relays which are placed topologically close higher > than others. Thank you for your suggestion. I hope that is not the case and the drop in consensus weight is just a temporary glitch. I will post to the development mailing list to see if the techies can comment on this. Paying hundreds of dollars of my hard earned money for a relay that is not being used by the network is not something I will keep doing for long. I support the goals and ideology of Tor, but the project will lose me as a volunteer if consensus weight does not restore soon. Thanks, Bram > Hey there, > > On 19 Jan 2015, at 10:03, eric gisse wrote: >> This is roughly consistent with what I've been seeing on my own node. >> >> Weird. >> >> On Mon, Jan 19, 2015 at 1:31 AM, Bram de Boer >> wrote: >>> Update: generation of the http://nosur.com/consensus.txt list has >>> completed now, and contains 3683 relays that exist half a year or more. >>> Again the relays at the top of the list show the sharp drop in >>> consensus >>> weight end of december and a short spike around January 6th. > > figuring out what happened will likely involve looking at the directory > authority votes to see if anything specific happened. One theory might > be that the addition of a new bwauth has shifted which vote gets picked > for the consensus. It's conceivable that bwauths rate relays which are > placed topologically close higher than others. I'm looking forward to > any analysis someone might do on this. > > Cheers > Sebastian > ___ > 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] New Arris TG1672 Cable Modem, relay not reachable...help!
On 01/18/2015 02:18 PM, Kurt Besig wrote: I'm trying to narrow down my connectivity problem and am wondering if anyone is runniing a relay, or knows of someone successfully running a relay, that is currently using TWC's new Arris TG1672 modem. Thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] MiB/s / metrics
Hi, I opened a ticket recently with the intention to use a more common unit than MiB/s for metrics. Karsten basically agrees but is waiting for more input. If someone is interested : https://trac.torproject.org/projects/tor/ticket/14257 -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach - Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. - Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Mismatched fingerprints
You can use the "site:" prefix with our friends at google, eg. "site: https://lists.torproject.org/pipermail/ SEARCHTERM" On 18 Jan 2015 19:02, "Patrick Scharmer" wrote: > Hi, > > I’ve been running a bridge for over a year and noticed recently that the > fingerprint shown in ARM (and that actually works when connecting to the > bridge) differs from the fingerprint displayed for my bridge on both Atlas > and Globe. Any thoughts on why this would happen and how to fix it? I’m > assuming the fingerprint published on Atlas & Globe is the same fingerprint > that will be distributed by bridges.torproject, is that correct? > > Apologies if this is a common question… I’ve only recently joined the > mailing list and couldn’t find a way to search the archives other than > browsing. > > Regards, > > -Pat > > > ___ > 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
Hey there, On 19 Jan 2015, at 10:03, eric gisse wrote: > This is roughly consistent with what I've been seeing on my own node. > > Weird. > > On Mon, Jan 19, 2015 at 1:31 AM, Bram de Boer > wrote: >> Update: generation of the http://nosur.com/consensus.txt list has >> completed now, and contains 3683 relays that exist half a year or more. >> Again the relays at the top of the list show the sharp drop in consensus >> weight end of december and a short spike around January 6th. figuring out what happened will likely involve looking at the directory authority votes to see if anything specific happened. One theory might be that the addition of a new bwauth has shifted which vote gets picked for the consensus. It's conceivable that bwauths rate relays which are placed topologically close higher than others. I'm looking forward to any analysis someone might do on this. Cheers Sebastian signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
This is roughly consistent with what I've been seeing on my own node. Weird. On Mon, Jan 19, 2015 at 1:31 AM, Bram de Boer wrote: > Update: generation of the http://nosur.com/consensus.txt list has > completed now, and contains 3683 relays that exist half a year or more. > Again the relays at the top of the list show the sharp drop in consensus > weight end of december and a short spike around January 6th. > > > ___ > 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
