As starlight said, you are getting the appropriate amount of traffic according
to the bandwidth authority measurements for your relay.
Right now, the middle/entry nodes are relatively lightly utilized. This is a
good thing, since it makes for a much better user experience. With high
So we now have the bandwidth, IP, and dirport of the fastest exits. With this
list in hand, I just needed to form a proper URL, wget each one, and grep out
the transfer speed:
http://37.130.227.133:80/tor/server/all 1.17 MB/s
http://176.126.252.11:443/tor/server/all 4.54 MB/s
Thanks for running the tests. Which exit nodes led to poor performance? I
would like to try to reproduce any performance problems.
I did not record the nodes (they were in Europe). A simple test you could run
on your server is fetching directory info from nodes that have directory
Original Message
From: Green Dream greendream...@gmail.com
Apparently from: tor-relays-boun...@lists.torproject.org
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Guard flag flapping
Date: Fri, 7 Aug 2015 21:49:16 -0700
I've learned from this thread that the
Original Message
From: starlight.201...@binnacle.cx
Apparently from: tor-relays-boun...@lists.torproject.org
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Guard flag flapping
Date: Sat, 08 Aug 2015 14:39:48 -0400
My advice is that this QWest service is third-rate
debugging the old Blutmagie Perl scripts I found all routers like
splitDNA running Tor 0.2.7.2 sending two hash values in the
extra-info-digest. I suppose this isn't expected by the script parsing
the data.
GETINFO desc/name/splitDNA
250+desc/name/splitDNA=
router splitDNA 62.210.82.44
