Re: [tor-relays] Middle Relay has no traffic
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 utilization, the web browsing experience deteriorates dramatically as network request latency goes up. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard flag flapping
> 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 > http://176.126.252.12:21/tor/server/all 666 KB/s > http://77.247.181.164:80/tor/server/all 111 KB/s > http://77.247.181.166:80/tor/server/all 330 KB/s > http://195.154.56.44:80/tor/server/all 3.65 MB/s > http://77.109.141.138:80/tor/server/all 2.20 MB/s > http://96.44.189.100:80/tor/server/all 13.4 MB/s > http://197.231.221.211:1080/tor/server/all 347 KB/s > http://89.234.157.254:80/tor/server/all 295 KB/s > > I'm not seeing anything immediately, although I need to run it on a larger > set. There's no smoking gun so far though. Some of the speeds are a bit slow, > but nothing low enough to explain the extremely low measured bandwidth these > relays are getting. The current BW auth measurement results are around 1.0MBit/s for greendream848. I had a couple of measurements in the 300-500KBit/s range. So, if the auths heavily weight towards low individual measurements, things might make sense. Maybe one of the BW auth guys can comment on how the total measurement result is cooked up!? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard flag flapping
> 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 functionality enabled. wget http://:/tor/server/all e.g.: wget http://176.126.252.11:443/tor/server/all You can get a bandwidth-sorted list of nodes at: https://torstatus.blutmagie.de/ There is a column that has the directory port. > How would you measure performance between my node and a given exit without > being influenced by the properties of the middle relay? You can only set me > as an entrynode, and you can't pick a specific middle, You are wrong. :-) You can build arbitrary circuits by hand. There are libraries like Stem, Txtorcon, TorCtl and there is a text based, SMTP-like protocol that you can use directly: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt > so how would you know that the low performance was my node and not the random > middle relay? Your node would be a non-random middle relay. > > The bandwidth auths probably downrate the measurement results of your > > server severely because of those slow connections. > > Probably? How can we investigate further? AFAIK, the raw bandwidth auth measurements are not published, only the total result. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard flag flapping
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 > and rather than bleeding for the length of the > contract, run for the hills! > > If you are still in the 1-month cancellation > period (relays are about a month old), terminate > the service immediately and place an order for > Verizon FiOS. Verizon is one of those ISPs who have played routing games, slowing down Netflix and other traffic that happens to use use the same routing: http://www.extremetech.com/computing/186576-verizon-caught-throttling-netflix-traffic-even-after-its-pays-for-more-bandwidth ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard flag flapping
Original Message From: Green Dream 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 Guard flag flapping is a direct result > of the low measured bandwidth. I still have no idea why the measured > bandwidth is so (terribly, comically) low. The fact that it's so wrong is > somewhat telling. Actual performance on the network is like 1000 times better > than what the measured bandwidth says! Something feels very broken here. I ran some tests against your node. While performance is generally very good, it has very low performance connecting to some exit nodes. The problem is likely that your ISP is routing some traffic via an overloaded peering point. Some ISPs have been know to do that on purpose, e.g. to make connections to Netflix or Youtube extremely slow while claiming not to do throttling. The bandwidth auths probably downrate the measurement results of your server severely because of those slow connections. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
> 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 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt -- "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) --- Fetching descriptors via: http:///tor/server/all has 2 values for extra-info-digest as well. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
