[tor-relays] Tor relay system uptime requirements
Hi all, I am considering setting up a tor relay. However my configuration is not powerful and I failed to find precise informations about the hardware system requirements. I believe it would be useful to have such informations in the FAQ, along with graphs of the needed RAM CPU as a function of the allocated bandwidth. Anyway, I would use a Sheevaplug (Marvell 1.2 GHz CPU, 512 MB DDR2 @ 400 MHz) running Debian Squeeze. It already serves as a small webserver (~200 visits/month, 10 MB bandwidth/month), and 150 MB of RAM are allocated to flashybrid (which helps preserving the SD card life by keeping /var/log/* and such data in RAM and write it down only once in a while). First questions : would it be eligible as a tor relay ? As a tor exit ? Or should I rather go for a bridge ? I guess my bandwidth will be limited by the hardware, how much would you suggest ? On the same network is my personal computer which is much more powerful but down most of the day, so I guess it would be unworthy to make use of it ? I have also thought about using the PC of my parents as a bridge (smaller bandwidth), but again it is online only a few hours a day, would it be worth it ? Thanks. Regards, G. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay system uptime requirements
Hi, how much Bandwidth would you use for tor? Anyway, RAM could be the limitting factor here. aurel On 1 February 2012 17:45, Goulven Guillard lecotegougdelafo...@free.fr wrote: Hi all, I am considering setting up a tor relay. However my configuration is not powerful and I failed to find precise informations about the hardware system requirements. I believe it would be useful to have such informations in the FAQ, along with graphs of the needed RAM CPU as a function of the allocated bandwidth. Anyway, I would use a Sheevaplug (Marvell 1.2 GHz CPU, 512 MB DDR2 @ 400 MHz) running Debian Squeeze. It already serves as a small webserver (~200 visits/month, 10 MB bandwidth/month), and 150 MB of RAM are allocated to flashybrid (which helps preserving the SD card life by keeping /var/log/* and such data in RAM and write it down only once in a while). First questions : would it be eligible as a tor relay ? As a tor exit ? Or should I rather go for a bridge ? I guess my bandwidth will be limited by the hardware, how much would you suggest ? On the same network is my personal computer which is much more powerful but down most of the day, so I guess it would be unworthy to make use of it ? I have also thought about using the PC of my parents as a bridge (smaller bandwidth), but again it is online only a few hours a day, would it be worth it ? Thanks. Regards, G. ___ 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] Tor relay system uptime requirements
Le 01/02/2012 19:15, Aurel W. a écrit : how much Bandwidth would you use for tor? Anyway, RAM could be the limitting factor here. My ISP currently provides me with ~ 800 kbps in upload. I could probably give half or more to tor but I believe indeed RAM CPU will be the limiting factor (that's why I didn't mention it in my first email). I have ~ 15 Mbps in download but I guess it is better to keep it symmetric (I have not yet checked this point in the doc though). G. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay system uptime requirements
I'm not familiar with the Sheevaplug, but I have some experience with low-end hardware. I run a middle node on a Pentium-M 1.8GHz (Dothan, circa 2004) with 1GB of DDR1 RAM on a CentOS 5.x/i686 box. I have Tor v0.2.2.x configured for Bandwidth=150KB, BurstBandwidth=300KB. That 150KB is one-third of my 450KB upload capability. With this set-up I see the Tor process consuming 2% of CPU, about 60MB of RAM (RSS) used, and I see 100 - 200 connections active at any given time. That 150KB is the peak traffic that is used (I've never see evidence that BurstBandwidth is used at all). If fact, it is currently averaging about 90KB. See here: http://torstatus.blutmagie.de/router_detail.php?FP=4d393c7d93c16b97a3f41df94919ca8272239b96 The crypto stuff is the CPU bottleneck in Tor, so really Tor's CPU use is gated by OpenSSL's performance. My CPU, old as it is, has SSE2 instructions and that helps a lot. I build Tor against a contemporary version of OpenSSL, which doubles the encrypt/decrypt performance relative to the v0.9.8+patches that is standard in CentOS v5.7. FYI. On Wednesday, February 1, 2012 11:45am, Goulven Guillard lecotegougdelafo...@free.fr said: Hi all, I am considering setting up a tor relay. However my configuration is not powerful and I failed to find precise informations about the hardware system requirements. I believe it would be useful to have such informations in the FAQ, along with graphs of the needed RAM CPU as a function of the allocated bandwidth. Anyway, I would use a Sheevaplug (Marvell 1.2 GHz CPU, 512 MB DDR2 @ 400 MHz) running Debian Squeeze. It already serves as a small webserver (~200 visits/month, 10 MB bandwidth/month), and 150 MB of RAM are allocated to flashybrid (which helps preserving the SD card life by keeping /var/log/* and such data in RAM and write it down only once in a while). First questions : would it be eligible as a tor relay ? As a tor exit ? Or should I rather go for a bridge ? I guess my bandwidth will be limited by the hardware, how much would you suggest ? On the same network is my personal computer which is much more powerful but down most of the day, so I guess it would be unworthy to make use of it ? I have also thought about using the PC of my parents as a bridge (smaller bandwidth), but again it is online only a few hours a day, would it be worth it ? Thanks. Regards, G. ___ 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] Tor relay system uptime requirements
On Wed, Feb 1, 2012 at 3:24 PM, Goulven Guillard lecotegougdelafo...@free.fr wrote: My ISP currently provides me with ~ 800 kbps in upload. I could probably give half or more to tor but I believe indeed RAM CPU will be the limiting factor (that's why I didn't mention it in my first email). I have ~ 15 Mbps in download but I guess it is better to keep it symmetric (I have not yet checked this point in the doc though). Just try a middle node. Do not run vidalia of course, just plain chrooted Tor. Maybe with higher niceness since the webserver is your priority. https://trac.torproject.org/projects/tor/wiki/doc/TorInChroot ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay system uptime requirements
With this set-up I see the Tor process consuming 2% of CPU, about 60MB of RAM (RSS) used 100 - 200 connections active at any given time. Seconded. It's not much. And irrespective of hardware, seconded also on using current OS, build libs and Tor. Some OS require setting kernel sysctl to enable extra cpu's or cpu features. BIOS too. But that intel-HT is not worth anything. My ISP currently provides me with ~ 800 kbps in upload ... 15 Mbps in download but I guess it is better to keep it symmetric It's bytes in/out of the closed circle that is your box/interfaces. Other than encapsulation differences, non-symmetric is not physically possible. You can set up OS rate limiting to let Tor freely use whatever when you are not using the pipe. But I don't know how to properly let Tor know you are doing that??? (other than telling Tor it's own rate limit should be the entire possible size of your pipe, as would be the case when Tor is allowed by OS to free run during your non usage. Tor would get squeezed otherwise, but that's probably not too bad.) I have also thought about using the PC of my parents as a bridge Not a good idea to subject anyone but yourself to the potential issues of being an exit :) So a non-exit or bridge is better. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Thoughts on InspecTor?
This application claims to identify bad Tor nodes for the purpose of excluding them from use: http://xqz3u5drneuzhaeo.onion/users/badtornodes/ Anyone have any thoughts on this? The sum of bad-exit-flags (8), exit nodes that alter payload (4), and long-term-misconfigured (27) suggests excluding 39 nodes within the Tor config file. Is this reasonable? Are these exclusions appropriate for relays, or for end users, or neither, or both? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thoughts on InspecTor?
On Wed, Feb 01, 2012 at 11:36:57PM -0500, Steve Snyder wrote: This application claims to identify bad Tor nodes for the purpose of excluding them from use: http://xqz3u5drneuzhaeo.onion/users/badtornodes/ Anyone have any thoughts on this? In general it is a poor plan to change your routing strategy in a way that makes you different from most Tor users. If you change it enough, you end up making a signature for your behavior where an attacker can say hey, that's the guy who never uses German relays. The result is that you harm your anonymity. Nobody has really researched how much harm comes from how much difference -- and we recommend against doing things that are poorly understood. The sum of bad-exit-flags (8), As far as I can tell, http://xqz3u5drneuzhaeo.onion/users/badtornodes/overview.html#blocking are all tiny relays so it doesn't much matter whether you badexit them (you're probably never going to encounter them in practice anyway). For the question of exit relays in Iran, see https://trac.torproject.org/projects/tor/ticket/4207 https://trac.torproject.org/projects/tor/ticket/4923 exit nodes that alter payload (4), It would be great if people would actually report these to us. I believe that two of those four are ones we've already noticed and set the badexit flag on network-wide, and two of those four aren't around anymore. and long-term-misconfigured (27) It would be great if people would report these too, if they are actually having problems. In theory, Mike Perry's TorFlow scripts out to be able to automatically recognize when a relay is buckling under the load and starting to fail connections. In practice it's not there yet, and he could sure use some help since we're also asking him to maintain our Firefox fork. suggests excluding 39 nodes within the Tor config file. Is this reasonable? Are these exclusions appropriate for relays, or for end users, or neither, or both? I'd go with 'neither'. This is a community that looked at a relay with the nickname NSAFortMeade and freaked out because it was clearly an NSA-run node. You can pick your nickname to be whatever you like. If the NSA ran a relay (which it makes no sense for them to do, since they have already suborned major telco networks like ATT so they'd do better to watch *other* peoples' relays), why the heck would they name it NSAFortMeade? And if somebody came to you claiming you'd better not use it because omg tin foil hat, how much should you listen to the rest of their recommendations? Now, that doesn't mean we don't need help trying to make sure all the relays are behaving correctly. But a person who sets up a Tor hidden service, and clearly puts quite a bit of effort into it, but never tries to contact the Tor developers or the Tor directory authority operators? Maybe he just needs you to help him communicate with us. :) The right way to set badexit flags is to do it network-wide so we don't fragment the set of possible path selection behaviors for clients. Hope that helps, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Thoughts on InspecTor?
On Thu, 2 Feb 2012 00:25:19 -0500 Roger Dingledine a...@mit.edu wrote: On Wed, Feb 01, 2012 at 11:36:57PM -0500, Steve Snyder wrote: This application claims to identify bad Tor nodes for the purpose of excluding them from use: http://xqz3u5drneuzhaeo.onion/users/badtornodes/ Anyone have any thoughts on this? In general it is a poor plan to change your routing strategy in a way that makes you different from most Tor users. If you change it enough, you end up making a signature for your behavior where an attacker can say hey, that's the guy who never uses German relays. The result is that you harm your anonymity. Nobody has really researched how much harm comes from how much difference -- and we recommend against doing things that are poorly understood. The sum of bad-exit-flags (8), As far as I can tell, http://xqz3u5drneuzhaeo.onion/users/badtornodes/overview.html#blocking are all tiny relays so it doesn't much matter whether you badexit them (you're probably never going to encounter them in practice anyway). For the question of exit relays in Iran, see https://trac.torproject.org/projects/tor/ticket/4207 https://trac.torproject.org/projects/tor/ticket/4923 The latter ticket's discussion section is quite interesting. After reading through it, it seems to me that the problem in Roger's point C would be best dealt with in vidalia without regard to IP address or presumed country. When asking whether the user wishes to run a relay, vidalia's dialog could include an instruction something like this: Before you decide to run a tor relay, please consider whether the government of the country where you live and/or would like to operate a relay might target you for any kind of abuse if that government noticed that you were running a tor relay. As long as the people who have volunteered to provide translations for vidalia's and/or tor's textual interactions with users have sufficient skills to provide such a cautionary note in all of the most necessary languages plus two or three languages spoken widely around the world, then that should take care of the matter. I share the concerns of both Roger and Sebastian regarding undesirable potential results of automating the rejection of entire countries of relays. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
