On Mon, May 18, 2015 at 09:02:27PM +0000, nusenu wrote:

now even DocTor starts to complain

https://lists.torproject.org/pipermail/tor-consensus-health/2015-May/005772....

Yep. moria1's bwauth seems to be working fine, so I'm the only one paying attention to the thread here, and also the only one who doesn't have anything to fix. :( I haven't heard back from Aaron Gibson yet. In the mean time, I've asked some other developers to get one or two new bwauths going, which will hopefully lessen the magnitude of the problem in the short term, until somebody can fix the underlying bwauth flaws. --Roger

On Tue, May 19, 2015 at 08:47:56PM +0000, nusenu wrote:

sounds alarming if people operating tor's key infrastructure do not care (or have not enough time to care)

Well, we are working on a variety of approaches now for fixing it. Some in the short term (get more bwauths, fix bugs), some in the long term (make and deploy better design for computing weights).

https://lists.torproject.org/pipermail/tor-consensus-health/2015-May/005774....:

...

WARNING: The following directory authorities are not reporting bandwidth scanner results: tor26

If one more bw auth goes down, all relays will get the unmeasured flag, because the threshold of 3 votes is no longer reached, is that understanding of the spec correct?

No, I believe if there are only two dir auths who express weight opinions in their votes, then the group collectively backs off to using self-advertised weights.

current stats: 2015-05-19 19:00: 1367 unmeasured ("lost" ~1000 relays and 10GBit/s bw since 2015-05-01)

We also took some steps in the past few weeks to cut out extra tiny relays. It would be good for somebody to track a list of what those events were. I don't mean to say that we lost zero relays due to the above issue; but I think an unknown number of them are better explained by other events in the network. --Roger

To be a bwauth you have to be a dirauth, if the bwauth draft spec I read was correct. But how do you become a dirauth? The addresses are hardcoded into Tor, so it's not like I could just spin up a dirauth in an evening and let the network do the rest. There's got to be more to it. I was interested in hearing the response as well, so... Bump. Jannis Wiese:

What does it take to run a bwauth and/or dir auth? I would be happy to help, if I can.

Jannis

Matt Speak Freely

Hi all, Wanted to provide an update (even if it's not as good news as I hoped to give) because I know this is a very frustrating issue for everyone. At a high level, the bwauth scripts segment the network into four segments ranked by relay speed, and measure each of these segments. They are 0-10, 10-40[0], 30-60, 60-100 (so the top 10% of relays by speed, and so on.) After 26 hours[1], the first scanner we added is currently at: Segment 1: Completed, looped a couple times Segment 2: 34.2 of the 10-40 Segment 3: 46.5 of the 30-60 Segment 4: 77.4 out of the 60-100 This isn't very encouraging - it's slow going. Two of things that were just brainstormed in #tor-dev were: 1) Increasing the number of scanners tended to overwhelm the tor instance that supported these scanners, so we want to try doubling the scanners *and* the tors. Hopefully this will let us work our way through the list of relays faster. 2) We want to look at the possibility of relays moving around in the percentiles in each consensus, getting unlucky, and not being measured; potentially fixable by pinning a relay to a percentile, and then when we get all the way through a segment, unpin it, get that segment from the latest consensus, and restart. This may result in a relay being pinned into scanner#2, scanner#1 completes, measures the relay, then scanner#2 measures it... that wouldn't be so bad, double measuring is better than not measuring. When torflow was written over four years ago, there may have been a good reason it didn't work this way, and we need to see if we can re-reason out what that was. So we are working on identifying the subtler issues and seeing if we can fix them, in addition to just adding more of the same. -tom [2] [0] The 10-40 overlap is a bug we just found. [1] Well, more like 50 hours, but the first 24 were lost because of a breaking change in a python point release [2] (Most of this is aagbsn's knowledge, I'm just transcribing it.)

On Wed, May 20, 2015 at 04:13:57PM -0500, Tom Ritter wrote:

Right now Tor has two new BWAuths spinning up, one of which will hopefully be included in the vote this week or weekend.

And, it looks like Tom's bwauth data is now being used by maatuska. So I expect this will be good news for many, though not all, of the relay operators who have been part of this thread. You can investigate the individual votes about your relay by looking at the copies of the votes that moria1 exports each hour: http://freehaven.net/~arma/moria1-v3-status-votes (Be aware that while the file is used to be small, it's now up to 28 megabytes. The network sure has been growing.) --Roger

Hey, thank’s a lot my relay is now also able to support Tor. After over 2 weeks consensus weight is raising! Thank’s to all who helped to fix this bug… Best regards, Marcus -- Mein öffentlicher Schlüssel (S/MIME) ist hier verfügbar: https://www.dropbox.com/sh/1c6mccutvv7osq8/AAD66cjh4kmgE5d5xLgQjM_0a?dl=1

Am 25.05.2015 um 15:18 schrieb Speak Freely <when2plus2is5@riseup.net>:

GIGGITY GIGGITY GOO!!!

It appears as of this morning, 3 of my relays are now reporting something better than 20, in the upper hundreds.

My other one that started working the week before is now chomping along it's merry way.

So I will turn the 3 back on to exit-relays.

Matt Speak Freely _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hi operators, I believe especially the DirAuth/bwauth operators are working on this, but I would like to understand the ongoing issues. On my relay (8827944C4BDCBDAC9079803F47823403C11A9B7A), I see a decline in consensus weight fraction basically since May 14 (that’s where the first drop in weight fraction occurred) and the same in traffic of course. The connections went down by more than 50% from 1500-1600 to now about 700 (total values). I did notice the strange peak in traffic yesterday, but it’s now back to low levels. My relay is of course working nowhere near capacity (I have set up a RelayBandwithRate of 2MB and a Burst of 5MB) and I hope you understand that's a bit frustrating for me. At the moment I just see urras missing from the consensus and the measured entries of longclaw are quite a bit off the chart (I’ve subscribed to the consensus-health mailing list) - is that all what you need to have the tor traffic not distributed consistently (at least from my point of view) any more? Most importantly: Can I do something to help? Cheers, Jannis

I set my bridge up using the guide at https://www.sky-ip.org/tutorials.html and I have a steady flow of connections definitely visible via tor-arm. On June 1, 2015 11:02:53 AM CDT, Tom Ritter <tom@ritter.vg> wrote:

Hrm. So this gets into the inner workings of the bwauth system which is... complicated.[0] Honestly, I'm not actually sure how the individual data from the different bwauths is combined into a single value for the consensus.

I'm not sure what the answer is for your problem, but I'm beginning to wonder if the general approach to this problem is "There should be a bwauth debugging mechanism similar to https://consensus-health.torproject.org/ or (the unimplemented) proposal 164." I don't know if said mechanism would be a component of atlas/globe or an entirely separate site, but if the bwauths exported their hourly files, and this hypothetical tool aggregated that data, it may help figure these things out. It might give an answer like "moria spazzed out and undervoted me, let me wait until it scans me again."

-tom

[0] https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/R... [1] https://gitweb.torproject.org/torspec.git/tree/proposals/164-reporting-serve...

On 31 May 2015 at 17:31, Jannis Wiese <mail@janniswiese.com> wrote:

...

Hi operators,

I believe especially the DirAuth/bwauth operators are working on this, but I would like to understand the ongoing issues.

On my relay (8827944C4BDCBDAC9079803F47823403C11A9B7A), I see a decline in consensus weight fraction basically since May 14 (that's where the first drop in weight fraction occurred) and the same in traffic of course. The connections went down by more than 50% from 1500-1600 to now about 700 (total values). I did notice the strange peak in traffic yesterday, but it's now back to low levels. My relay is of course working nowhere near capacity (I have set up a RelayBandwithRate of 2MB and a Burst of 5MB) and I hope you understand that's a bit frustrating for me.

At the moment I just see urras missing from the consensus and the measured entries of longclaw are quite a bit off the chart (I've subscribed to the consensus-health mailing list) - is that all what you need to have the tor traffic not distributed consistently (at least from my point of view) any more? Most importantly: Can I do something to help?

Cheers, Jannis

_______________________________________________ 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

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On Mon, Jun 01, 2015 at 11:02:53AM -0500, Tom Ritter wrote:

Hrm. So this gets into the inner workings of the bwauth system which is... complicated.[0] Honestly, I'm not actually sure how the individual data from the different bwauths is combined into a single value for the consensus.

The weight in the consensus is the median of the bwauth votes. (That design aims to best resist manipulation of the weight by a small number of bwauths.)

I'm not sure what the answer is for your problem, but I'm beginning to wonder if the general approach to this problem is "There should be a bwauth debugging mechanism similar to https://consensus-health.torproject.org/ or (the unimplemented) proposal 164." I don't know if said mechanism would be a component of atlas/globe or an entirely separate site, but if the bwauths exported their hourly files, and this hypothetical tool aggregated that data, it may help figure these things out. It might give an answer like "moria spazzed out and undervoted me, let me wait until it scans me again."

Yes, I'd love to have something like this. Once upon a time I asked for us to export more of the bwauth internals: https://trac.torproject.org/projects/tor/ticket/2532 But at the time Mike decided that the intermediate bwauth numbers weren't useful enough to export. Another ticket you might enjoy is: https://trac.torproject.org/projects/tor/ticket/2394 I think ultimately we need somebody to simplify the bwauth design as much as possible (but no more), and then we can start assessing its output to see how it compares to reality. In parallel, or maybe instead, we might want more work on bandwidth estimation algorithms that are resilient to cheating. Right now the bwauth results can be gamed, and making them harder to game is an open research area. Some research groups have been working on it, and I look forward to some of their papers going public. But none of the papers that I've seen so far are perfect designs, so don't set your expectations too high. :) But all of that said, just visualizing the various Measured= lines by each of the bwauths might be a great start, and this can be done with the published votes as-is: http://freehaven.net/~arma/moria1-v3-status-votes --Roger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi nusenu, Again thanks for keeping an eye on things. At least partially, the balance of measured/unmeasured should be fixed in the new few days. To relay operators, in the mean time, please bare for few more days and sorry for the inconvenience, I can imagine what it feels like to have a high capacity unmeasured relay. Developers already know that a new bandwidth measurement system is badly needed, just need to find workarounds for the short term until such a system will be ready. On 5/19/2015 12:02 AM, nusenu wrote:

now even DocTor starts to complain

https://lists.torproject.org/pipermail/tor-consensus-health/2015-May/0 05772.html

_______________________________________________

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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVWlkwAAoJEIN/pSyBJlsRPUEH/3x9638bl0mSoq2oEpC3MazV GgCEh/MG+6dWDKdASG0qdrpdFPt4VrihuwhIOB5l5G9x6RUhf1LEZvGjdqYiyz0Y JRB1m4Mek8x0iHKeVQeY8VnWX3WQBEpgXc4EVUHgkTGXZByLSAueyYnviD0hGeiy ftfaBhN6SE5nzxAVBmzHBiC5rmFl5cam3o9YxguGOkugaWeLHgHDECbQ+yjacy1N 6VjudnuuFeAu2myfo6g2W7tCHswVaDwqyUhmhuab9OUguImv0HdHoGgeJM/tn3TZ EQuRSKYV4jhfCkzpcLvzcsueJKuLfchGyJ8JxiD/vbLuXe9swLJsUcwORg4BMQQ= =w3+J -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is splitting the bwauth data into a seperate consensus of some description a possibility and have a few people run them without needing to be a dirauth? That would mean lesser responsibility is placed on bwauth ops and perhaps the load or task could be spread to people known by Tor Project but not in the current dirauth pool. T On 18/05/2015 22:45, Roger Dingledine wrote:

On Tue, May 19, 2015 at 12:27:12AM +0300, s7r wrote:

...

Hi nusenu,

Again thanks for keeping an eye on things. At least partially, the balance of measured/unmeasured should be fixed in the new few days.

To relay operators, in the mean time, please bare for few more days and sorry for the inconvenience, I can imagine what it feels like to have a high capacity unmeasured relay. Developers already know that a new bandwidth measurement system is badly needed, just need to find workarounds for the short term until such a system will be ready.

I've even been pondering crazy hacks at this point like exporting moria1's bwauth file to a second dir auth, so it gets to vote twice and we're more likely to have the required minimum of three opinions for each relay.

(This is a terrible idea, but we're in the realm of terrible ideas at this point.)

Another terrible idea, while we're at it, is to disable the active measurements and go back to self-advertised weights by the relays.

--Roger

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

- -- Activist, anarchist and a bit of a dreamer. Keybase: https://keybase.io/thomaswhite PGP Keys: https://www.thecthulhu.com/pgp-keys/ Current Fingerprint: BA81 407C BD61 CD15 E5D9 ADA9 5FA2 426F F34E 0FD4 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Twitter: @CthulhuSec XMPP: thecthulhu at jabber.ccc.de XMPP-OTR: 77E6C8C6 95FDE863 1172A1E1 8C114C01 691398AC -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVWl+WAAoJEF+iQm/zTg/UC04P/20Ph3yrInfodsjg86ngVs0S lQ3kYHLNTy+ei09J4V3OtatWwmIfeY2/Upe5We1vzvnYzp/cGnfn3QaHKpe6TnNY 20ThOcmWS9/bX9ZVdKRMwzkKkItr0DOWukhTZcZ8FvNMpvwsvKyc5reEeA/Q43Ag AM0r7XYeN/7g2pGvPYZUYjo62Ss7Hdf/2Qb9PUm2po+Vh2vGHKFGQE5H5uFKQC71 43LaeRT/Rz0QGCk+aB8B2kQ/EuaqFxI7vhXWN/gOdHlCL2OvmlgSVHt7G6dHwUJq vJ/goRakR9WJG57RR2a+vgqgZafXZiLJ94tT1RMor8pgok6d+guD1rI/81hTgs5E HLLaKsYVG/9xfXBJz2HlFyLuaG3/l+uXxluJd55yF3SVyAXxvRUpzYg3cW/wv0pD AxNFgAdjdhiT31YmITAuctTfaw8bAOvciD2clFuvX9HCPI5iYBFdg8BvjvfIotOU 6zUREBXcsRJUcBqFok5q7XAZflLFvM1GIdpQQqos/4W2vz/gsg28uYDeUX2lyCt3 2vMcLyFCDc6KPNhXzD0jX6nlIWNkq3v/AK6gkcVgR/XrifqpTYCQvdazQZEXlXrx R085lpsR5K3Wlv/tn3kJ5y0bCUVj3MUluekTmXQw/gMXpyl5TwdZ64NdeFr/YyYf boLcS9hKf2RyKsWn1cID =cqAZ -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

At least partially, the balance of measured/unmeasured should be fixed in the new few days.

Thanks for the pre-info, appreciated. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVW6NQAAoJEFv7XvVCELh0/18P/2dsv6o5DFwCqCid41nYaksG FNmgX8WqvOBGhcNngY+b9ajUa68+8D355qI5Wy0e8yKIZ/ZOmjTrxcfiKzEz7zGn mmWsxATFDS9VPUOQDpl7SUY0sUhVgO/xGvQwcAKz4yKdA571+qVjF2m0l6wKZODA ZOMemB+Nyi8tuJLWKZ9+v4lTwRPplIxwlMSB59+p2HlJaymAOV+08glsLbBnn+if FA9e068T6iczI2mbm24CoLUxmgQSYLLb7TxUvTUXbYPCk8l1EMiHvfAzXI/ddtWu mnRMjPQNwQiNvikm+7LB7v3JLpqM5B7DTTUnsyjMrrlsDtpdMJv2DLf9390cH5K+ eCL06/vsqoP9Uf3yRfVo9nCriC+X7zQBb5INrDRfKC05+BxR9kZ+s4PBUzPeievq WvUJLKGgbS8lh5xsB/8f0aDZVyjZoJ1gjKuQAvDsLG2m+BvpnkkjttTlBjvBobs9 iYIjyootFZJZwzPWAt4gdM/WxMekG5LHhBquuVk5OZF/ZsDVn7H/urRug9tkXAx/ NpFqfWn4X4aJrcAfrDheqw2uNxnXYuCSAcRM3NRgVRSTWCDrr+WvA52Ilet7AcSs iSUws2p8g5XF4lv+Tj0etXMnbJdyIxWO99yTsw95/gfyTWrDmu6ENDpuSkDk0hpo 1cTqjXu9HypAFKVj0W15 =anmQ -----END PGP SIGNATURE-----

Hey NOC, Nah I had the same experience with *1* relay. Following the same pattern, none of the other relays have left 20. I'm now at 16200 and averaging ~30mb/s. 4 still in limbo. What's also interesting is I setup a non-exit and it also will not get past 20. What does arm say your measured speed is? Mine was 45Kb/s for the longest time, but very recently went to 126.5Kb/s, but that's silly. Matt Speak Freely

Hey, I still have the problem, that my relay (non-exit) is "not measured". I tried to set up a new ID but this doesn’t work. The relay ist still not measured since one week. (12FD624EE73CEF37137C90D38B2406A66F68FAA2) I don’t know much about the DA, but I checked that only two of nine have measured my relay. Only gabelmoo and moria1 did measure the relay. An other smaller relay I own (FFB78E1F3E29091212C23A24A9779072800E1D96) is listed as „measured“ in the consensus with only three DA which measured the bandwidth. (gabelmoo, moria1 and long claw) Based on this information I have some questions: 1) Is three DA which measured the bandwidth the „necessary“ number to be not „unmeasured“? 2) Is it only by chance that the DA are almost the same, which measured my both relays?! 3) Is there any idea, how I can maybe force a DA to measure the relay?! I am a bit frustrated that I rented a Server to support TOR and now the relay is useless… :( Thanks and Best regards, Marcus

Am 22.05.2015 um 01:24 schrieb Network Operations Center <noc@schokomil.ch>:

Matt,

135 Kb/s measured, I'm currently pushing data at 40Mbit in/out (limit is 80 Mbit with burst to 120 Mbit).

On 21.05.2015 11:14 PM, Speak Freely wrote:

...

Hey NOC, Nah I had the same experience with *1* relay. Following the same pattern, none of the other relays have left 20. I'm now at 16200 and averaging ~30mb/s. 4 still in limbo. What's also interesting is I setup a non-exit and it also will not get past 20. What does arm say your measured speed is? Mine was 45Kb/s for the longest time, but very recently went to 126.5Kb/s, but that's silly. Matt Speak Freely _______________________________________________ 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Julian Thanks for your contribution to Tor! Please keep them running, as much as you can. We already struggle to (at least partially) solve the issue for the short term, by launching more bandwidth authorities. On the long term, some research groups are working on a better bandwidth measurement system. We are all anxiously waiting for it, but unfortunately there is no ETA for it at this moment. To answer your question, it's not exactly true that _current system is clearly broken_, or totally broken. It works, but does not work 100% (e.g. we are missing some bandwidth). It's better than going back to self advertising bandwidth. By default (if not explicitly set a MaxAdvertisedBandwidth in torrc), Tor will self advertise the port speed which it sees on the server where running, which is very very often (I could say almost) of a higher value than that server can really handle. For example, take a VPS which has a network port of 1 gbps seen by the operating system, but it's running on a cluster with 100 another virtual machines and each is individually capped at hypervisor lever to 10mbit. Going back to self advertised bandwidth would assign unfair weights to some relays and cause Tor clients to choose paths in a buggy way, we could overload the less capable relays and cause circuit failure for clients, decreasing the Tor performance / user experience overall. The bandwidth authorities are not so sensitive as directory authorities, but a bandwidth authority is useless unless it talks to a directory authority which is allowed to vote in the consensus. That is why bandwidth authorities are run by the same trusted people who also run directory authorities. The analogy you are describing does not reflect the reality in this situation. For the issue we are facing, no directory authority operator has a solution, nor anyone. It's not like someone can do something about it, but does not do it. Still, everyone is making efforts to fix it, in the measure in which it is technically possible. The system where we have a known number of directory authorities, hardcoded and run by trusted people is very well researched and studied, and it eliminates a lot of real and practicable attacks. I am all for decentralized and distributed systems, but at this moment I really think we are doing the best we can. Everyone would prefer Tor to be decentralized and trustless, but this is not that simple and cannot be done immediately. A lot of research is needed. P.S. having the semi-centralized system we currently use (with few Directory authorities run by trusted people) does not mean you are 100% depending on the directory authorities or that they can compromise your anonymity. You are trusting them for consensus data (info about all the relays in the Tor network) which your client uses to build circuits. If something happens to the majority (50% + 1) of the directory authorities, this would prevent the Tor network to function at all, for anyone, but the previous activity within the Tor network of an user won't be compromised. This is a fair trust limit I could say, when you take in consideration the fact that total decentralization will open the door to many other attacks, far worse than this. (fortunately) there is no way to 'force' a bandwidth authority or directory authority to do anything. Please bare little more and keep the relays running if you can. After all, we are a community comprised in volunteers involved in research and experiments, sometimes things like this happen. Just keep calm, run relays and use Tor. It'll be fixed. On 5/23/2015 8:58 AM, Julian Plamann wrote:

I have a non-exit relay that has been up and running with 100% uptime on a 15mbps circuit for going on 20 days that is still unmeasured.

I also have an exit node on a 100mbps un-metered link that I brought online 7 days ago and purchased specifically to donate to Tor that is still unmeasured by the bwauths.

Perhaps it's time to go back to self-advertised bandwidth since this system is clearly broken?

Furthermore, I understand the necessity of having the bwauths run by trusted/known members of the development community, but what is the criteria for this trust? Does running a broken directory server for going on three weeks without taking the steps to fix it still fall within this "trust" definition?

--- Julian Plamann

julian (at) amity.be GPG: 0x96881D83

On 2015-05-22 10:32 am, Marcus wrote:

...

Hey,

I still have the problem, that my relay (non-exit) is "not measured". I tried to set up a new ID but this doesn't work. The relay ist still not measured since one week. (12FD624EE73CEF37137C90D38B2406A66F68FAA2) I don't know much about the DA, but I checked that only two of nine have measured my relay. Only gabelmoo and moria1 did measure the relay. An other smaller relay I own (FFB78E1F3E29091212C23A24A9779072800E1D96) is listed as „measured" in the consensus with only three DA which measured the bandwidth. (gabelmoo, moria1 and long claw)

Based on this information I have some questions: 1) Is three DA which measured the bandwidth the „necessary" number to be not „unmeasured"? 2) Is it only by chance that the DA are almost the same, which measured my both relays?! 3) Is there any idea, how I can maybe force a DA to measure the relay?!

I am a bit frustrated that I rented a Server to support TOR and now the relay is useless... :(

Thanks and Best regards, Marcus

...

Am 22.05.2015 um 01:24 schrieb Network Operations Center <noc@schokomil.ch <mailto:noc@schokomil.ch>>:

Matt,

135 Kb/s measured, I'm currently pushing data at 40Mbit in/out (limit is 80 Mbit with burst to 120 Mbit).

On 21.05.2015 11:14 PM, Speak Freely wrote:

...

Hey NOC, Nah I had the same experience with *1* relay. Following the same pattern, none of the other relays have left 20. I'm now at 16200 and averaging ~30mb/s. 4 still in limbo. What's also interesting is I setup a non-exit and it also will not get past 20. What does arm say your measured speed is? Mine was 45Kb/s for the longest time, but very recently went to 126.5Kb/s, but that's silly. Matt Speak Freely _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

...

...

...

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

...

...

tor-relays mailing list tor-relays@lists.torproject.org <mailto: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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVYL9hAAoJEIN/pSyBJlsRqxoIAIZxNCWC9XmHGSdTa/TRkK2h RZuS+bea7Pb19XlhBo6VytUN4BRPbv+B1HQ/riz8EwlwZVXlvMNMH87Hd7S+zpby lflvufdZKzJg4rKUxdx/z7XQ+EEuAJE6zYqEumUS3UTY+rHkEtJhZqLwEl8w3xxi FKrzqddzP+BQctRlqowwNNcMahYCmFS0ZIRIeCjHNJXzprtSAOn26AkYsyDxIHix T8oUgDJuJz+nt/hIxHTP4GMB/GRjswLCygemCGg22B7dvkRk9VsLdW9HBF77VIlE Z9N06XpWv429xcXRZnzO4ZQSYfT/RQiFy0JIeEcvum6AeE7hELWERS34pRIDp+w= =ED/G -----END PGP SIGNATURE-----