Re: [tor-relays] Hivelocity is not longer serving my needs.
On 05/11/2015 05:40 PM, Geo Rift wrote: > I've had my exit relay running on a spare Hivelocity server that I had for 17 > days now. Even after a reduced exit policy I continued to receive abuse > reports. I made similar experiences with my ISP. Therefore I run my new tor relay as non-exit for 3-4 weeks and opened it then again w/ reduced exit policy. That reduced drastically the DCMA spam b/c then the ip address was added to the usual firewall rule sets. -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -- "; the past is all dirty and cruel in the modern popular imagination, with the exception of the Romans, who are just cruel" Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England" ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hivelocity is not longer serving my needs.
Here are some other providers. They are both Tor friendly, but as always be sure to communicate to them that you plan to run Reduced Exit policies *before* you purchase, and make sure to tell them you are a pro-active user that responds to every complaint in a courteous manner. https://www.opticservers.com/ https://www.pulseservers.com/ I haven't had a single problem with either of them. And their tech support... sometimes answers in < 5 minutes. Great people. Both are "unmetered". During speed tests, I average 8.8-10.3 MByte/s on 1000MByte file. Optic is UK based and I believe Pulse is Canadian. Optic is custom. Pulse is OVH. Enjoy. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hivelocity is not longer serving my needs.
Hello, We provide tor services at Serverlogix.com. You can try it out. Thank You. On May 11, 2015 9:40 PM, "Geo Rift" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I've had my exit relay running on a spare Hivelocity server that I had for 17 > days now. Even after a reduced exit policy I continued to receive abuse > reports. They have now asked that I stop running a tor relay on the server. > > I'm looking for a decent provider that can suit my needs of running a fast > exit node. Does anyone have any recommendations? > > Thanks, > Tim > > -BEGIN PGP SIGNATURE- > Version: Mailvelope v0.13.1 > Comment: https://www.mailvelope.com > > wsFcBAEBCAAQBQJVUM1qCRC8Tq5FO2jmKgAA9aAP/3rWozZ63GiGG28/UsWT > Ap4ygekHqXvKPzpbUJz7mwxgk0AzCydgaLKaYHvl4jgEgXuwAXSCfSyZS27E > jOd72A6Qk36dtsVSgzBbFFyiT3f30mAZIBc+KCyhZ6fEQ5Rb5v0mJWz1nlyA > BfvYjTF6eZgLaLcyPt8RPJoITyV6df+RUbaUAstoqql+cZn7Wnoj9P6rbM3h > aSPFD2llWQorGxgRX7vJzuytJqZEIvhLoI/eakClyTKrNi2AosCn2rzKwB4C > oTv4wmlbbZnhSXvT8jdqBXzQl1va2XPaSErXTfkREzQ6Pg+LEG1lr+AGTFAE > JRMx5MN79YQtX86XnxZsCHxqLD8mqz1Kw2/lr6rNWWcxZH+tmXfKqpmCr6/b > 9Jjttd2qUQctOQZEYYoMSsIx1s269km1X6WB4tvYrx8NuBaqsFUuoEndeEpD > AvF2mlL5mhUjGxE4q9UERGm7KTVLf1MfqPNdpWjpepxy2eATjaOyo+tnswIZ > vM1h7x/Ky2KQG9240k1U6vfiqaRV82FNRvIhbrKgCtiZ3+CrqLNx4UXwcMVt > tqGqC86xX5ip4W+iyuVOOApV86V6U047ovPmiRV9XRv+44v8UFgGZA58Zobg > sCsFluaLICo857y4WPsiHjXwA5IHy9hI1kVAyJB2Qo9yIApGGlL9RhVhFDBI > B4Nm > =L3ny > -END PGP SIGNATURE- > > > ___ > 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
[tor-relays] Hivelocity is not longer serving my needs.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've had my exit relay running on a spare Hivelocity server that I had for 17 days now. Even after a reduced exit policy I continued to receive abuse reports. They have now asked that I stop running a tor relay on the server. I'm looking for a decent provider that can suit my needs of running a fast exit node. Does anyone have any recommendations? Thanks, Tim -BEGIN PGP SIGNATURE- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVUM1qCRC8Tq5FO2jmKgAA9aAP/3rWozZ63GiGG28/UsWT Ap4ygekHqXvKPzpbUJz7mwxgk0AzCydgaLKaYHvl4jgEgXuwAXSCfSyZS27E jOd72A6Qk36dtsVSgzBbFFyiT3f30mAZIBc+KCyhZ6fEQ5Rb5v0mJWz1nlyA BfvYjTF6eZgLaLcyPt8RPJoITyV6df+RUbaUAstoqql+cZn7Wnoj9P6rbM3h aSPFD2llWQorGxgRX7vJzuytJqZEIvhLoI/eakClyTKrNi2AosCn2rzKwB4C oTv4wmlbbZnhSXvT8jdqBXzQl1va2XPaSErXTfkREzQ6Pg+LEG1lr+AGTFAE JRMx5MN79YQtX86XnxZsCHxqLD8mqz1Kw2/lr6rNWWcxZH+tmXfKqpmCr6/b 9Jjttd2qUQctOQZEYYoMSsIx1s269km1X6WB4tvYrx8NuBaqsFUuoEndeEpD AvF2mlL5mhUjGxE4q9UERGm7KTVLf1MfqPNdpWjpepxy2eATjaOyo+tnswIZ vM1h7x/Ky2KQG9240k1U6vfiqaRV82FNRvIhbrKgCtiZ3+CrqLNx4UXwcMVt tqGqC86xX5ip4W+iyuVOOApV86V6U047ovPmiRV9XRv+44v8UFgGZA58Zobg sCsFluaLICo857y4WPsiHjXwA5IHy9hI1kVAyJB2Qo9yIApGGlL9RhVhFDBI B4Nm =L3ny -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with "Stable" Flag)
I'll be shutting down 5 of my unmetered 100mbit relays until they are fixed. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with "Stable" Flag)
Thanks for the response Moritz. L Brandt On 5/10/2015 11:26 PM, Moritz Bartl wrote: Hi, This is a known problem; the bandwidth authorities need to be worked on. See for example https://trac.torproject.org/projects/tor/ticket/13450 https://trac.torproject.org/projects/tor/ticket/4359 There's no timeline set yet on when this will be fixed. On 05/10/2015 09:48 PM, Marcus Wahle wrote: I had a look at https://collector.torproject.org/recent/relay-descriptors/consensuses/2015-05-10-19-00-00-consensus There you can find 874 relays with the „flag“ "Bandwidth=20 Unmeasured=1“… I don’t think this is normal… Can anybody have a look at this?! Best regards, Marcus Am 10.05.2015 um 16:47 schrieb Marcus Wahle : Hey I have almost the same problem with my relay (https://atlas.torproject.org/#details/DABC2440E9EAAEDB23F150CF95656405917A7829) I stuck to Consensus Weight: 20 since over one week. If I look at the "collected data“ I se the „unmetered = 1“ comment. :( Any Ideas how to fix this? Is this the normal and wanted behavior? Best regards, Marcus Am 10.05.2015 um 13:54 schrieb Network Operations Center : hey, can you do me a favor and remove the exit status of your relay and turn it into a regular node? I experienced the same problem as you: https://atlas.torproject.org/#details/3D7E274A87D9A89AF064C13D1EE4CA1F184F2600 but ever since I removed the exit-flag I am generating some consensus rating again. This problem first popped during the last days of 2014 and up until now there hasn't been any reliable fix. Apparently even deleting the ID of your tor-node didn't help according to one user. On 10.05.2015 07:05 AM, Larry Brandt wrote: yes I have experienced the same problem on my exit relay: DDC6C968B3DFD156C97FD71808758D251B66DBB2 My relay lost the stable flag due to a inadvertent shut-down a few days back. LB On 5/9/2015 1:38 PM, Neel Chauhan wrote: Hi, I have a Tor relay (https://atlas.torproject.org/#details/342587A287603040A49BB364D72EAC0B6BC3D71A) running from a FreeBSD server at my house on with a 5 megabit upstream connection. I have seen that lately, Tor's "Consensus Weight" value on this relay has not been going anywhere above (or below) 20. My relay has gotten the "Stable" flag, but yet didn't see it's consensus weight value rise. I decided to look at https://consensus-health.torproject.org/, and saw that two of the four bandwidth consensus servers, namely tor26 (86.59.21.38) and longclaw (199.254.238.52) don't seem to be calculating any consensus value for Tor relays in the last few days. Has anyone else been having this problem? And if the Tor consensus operators are reading this, (approximately) when would this problem get resolved? Thanks, Neel Chauhan ___ 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 ___ 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 ___ 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
Re: [tor-relays] RelayBandwidthRate vs AccountingMax
> Date: Sun, 10 May 2015 23:13:18 +0100 > From: Christopher Baines > > I run this relay [1], and currently use the following config: > 1: > https://atlas.torproject.org/#details/91F4DFA04743755C8551A12F8C4065F79786B732 > > RelayBandwidthRate 1.7 MB > RelayBandwidthBurst 20 MB > > This keeps it from using more than ~3TB of bandwidth in a month. > However, I wonder if this is beneficial for the network, over using the > AccountingMax instead? If you use "AccountingMax 3TB" and "AccountingStart month 1 00:00" (or whenever your rollover date is), the relay will go at full speed, use all the quota you specify, then hibernate for the rest of the month. The next month, it will calculate the maximum start date that it could start at to use all the bandwidth at a similar rate to last month, then wake at a random interval between the start of the month and the calculated date. Note that the AccountingMax quota will make the relay hibernate when either the download or the upload individually hit the quota. If you want the sum of both, use "AccountingRule sum". If you use RelayBandwidthRate, the relay will go at partial speed, and may not use all the quota if there are any quiet periods. Personally, I'd rather have faster relays for part of the month, but others favour stable relays for the entire month. It may also depend on whether your relay is one or more of: * a guard, where stability would be a priority, * a middle (that is, not guard or exit), where there is plenty of bandwidth, and therefore speed would be a priority, and/or * an exit, where speed would again be a priority… as far as I can work it out, anyway. Both stable relays and fast relays are a valuable contribution, please contribute what you think the Tor network needs most. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
