Dear Relay Operators,

Please see below for an updated list of slow relay DirPorts.

On 31 Mar 2016, at 11:13, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:

While I was checking fallback directory mirrors for #17158, I encountered some relays that took more than a minute to serve a consensus. Most took 150 seconds, which could be caused by a RelayBandwidthRate of 10 kilobytes a second.

One solution to this issue is to disable the DirPort on relays with a RelayBandwidthRate less than 50 kilobytes a second, or more than 30s to serve a consensus.
(This ticket also contains the python / stem code that I'm using to check the consensus download speed.)

But I don't actually know if it's the relays' torrc configuration that's causing the issue, or if their provider is limiting their speeds, or if there's some other issue.

If you're the operator of one of the relays listed below, can you let me know?
And if someone wants to investigate further … that would be great.

It turns out that some of these relays are down, and the connections are timing out.
I've modified my script so it catches timeouts, rather than treating them as "success".

Here are the relays that are actually up, but timing out or producing slow DirPort directory downloads:
89.163.225.184:9030 - mertadx - No ContactInfo - 92139E58A2FD1235A9AC02B1E1E87174FB80301B
185.31.230.69:9030 - AskForEraser - cc'd - E58CECC2ED31B33867D30707CDB239C85B38FFF2
81.7.14.227:9030 - Torwell01 - cc'd - BCA197C43A44B7B9D14509637F96A45B13C233D0
62.210.238.33:9030 - ORGNorthEast1 - cc'd - FDF845FC159C0020E2BDDA120C30C5C5038F74B4
212.107.149.145:9030 - flimsy - No ContactInfo - A4B99A72464F955F7EFFB5DD968B53DD450C7FB4

(This is an incomplete list based on those relays with the highest bandwidth weights.)

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F