...
No, this is not the issue, your relay's own self-measured throughput is the issue. See below.
By consensus weight, which is determined by the bandwidth authorities. How do the clients choose the exit ? From those servers they believe exit to the address and port they want, randomly, weighted by the server's consensus weight. The details of bandwidth weight selection are in section 3.4.2 of the Directory Specification: "The bandwidth in a "w" line should be taken as the best estimate of the router's actual capacity that the authority has. For now, this should be the lesser of the observed bandwidth and bandwidth rate limit from the server descriptor. It is given in kilobytes per second, and capped at some arbitrary value (currently 10 MB/s). The Measured= keyword on a "w" line vote is currently computed by multiplying the previous published consensus bandwidth by the ratio of the measured average node stream capacity to the network average. If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a "w" Bandwidth= keyword equal to the median of the Measured= votes." When I look at the bandwidth authority votes for DigiGesTor1e1, they say: w Bandwidth=9586 Measured=24200 w Bandwidth=9586 Measured=15900 w Bandwidth=9586 Measured=43500 w Bandwidth=9586 Measured=19700 w Bandwidth=9586 Measured=19200 Those votes are in these large files: So the bandwidth authorities have having no trouble measuring your relay, they think it should be 2x - 4x as fast. Your relay itself has't observed itself sustaining that performance over a 10-second interval, so it won't allow the directory authorities to assign it more bandwidth. Section 2.1.1 of the Directory Specification: ""bandwidth" bandwidth-avg bandwidth-burst bandwidth-observed NL [Exactly once] Estimated bandwidth for this router, in bytes per second. The "average" bandwidth is the volume per second that the OR is willing to sustain over long periods; the "burst" bandwidth is the volume that the OR is willing to sustain in very short intervals. The "observed" value is an estimate of the capacity this relay can handle. The relay remembers the max bandwidth sustained output over any ten second period in the past day, and another sustained input. The "observed" value is the lesser of these two numbers." Please improve the throughput your relay can sustain over a 10-second period. Try some performance tuning steps, testing your relay with Tor client after each one. (See below.) Have you set a limit on MaxAdvertisedBandwidth in the torrc files? Konsole output Have you tried doing a large download through your exit via a Tor client and seeing how fast that is? ExitNodes <fingerprint od your exit> StrictNodes 1 The servers are connected with 1 Gbit/s each. It looks like your Tor processes are neither CPU nor network-bound. Does your network connection drop packets or have large latency? How many file descriptors are the tor processes allowed to open? How many connections does each tor process have open at once? (There should be thousands per process on a busy relay.) Are there any performance-related messages in the Tor logs? Is your hardware / kernel / firewall / etc. capable of handling many connections? Does your provider rate-limit any kinds of traffic? Does your provider limit the number of open connections? Is your DNS resolver keeping up with the requests? Do you have a local caching DNS resolver on each machine? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays