Re: Very low performance in CriptolabTORRelays*
Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): Our ISP wont say nothing about their filters (It seems to be a Top Secret issue :P). As I said before there's no problem reported at debug.log except for the frequent: [debug] TLS error: unexpected close while reading (SSL_ST_OK) Another way to do this is to try to use Tor as a client. Does that work? Nope. How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html Nope. Transfer rates are equally ridiculous. Tried in windows, same. Great! Now we're getting somewhere. Now, your question isn't How do I run a relay at a censored ISP it's Please help me use Tor at a censored ISP. That is a question we are prepared to at least *try* to answer :) Can you access the following page: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics If it too is blocked, blocked, it is also available via the ssl-encrypted proxy link on ixquick: https://us2.ixquick.com/do/metasearch.pl?q=TheOnionRouter+BlockingDiagnostics Similarly it is in the Google Cache, which is now available over SSL. https://webcache.googleusercontent.com/search?q=cache:wDewL-f-g9gJ:https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/BlockingDiagnostics+cd=1hl=enct=clnkgl=us If you feel you can follow those instructions, can we meet on IRC? Can you access #tor-dev on irc.oftc.net? Port 6697 is SSL, if you suspect keyword filtering too. Specify a time and we can give you a private bridge IP and try to diagnose exactly how your ISP is blocking access to Tor. P.S. The above goes for anyone who knows anyone having trouble *accessing* the Tor network from anywhere else. Please contact me or show up on #tor-dev. We are in desperate need of people inside China to help us with this. So far we have zero people there who can help us diagnose what is going on. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpasY5OZXx1e.pgp Description: PGP signature
Re: Very low performance in CriptolabTORRelays*
On 03.12.2010 08:40, Daniel Franganillo wrote: Well, im not asking for help to run a Tor relay, I did it for more than a year without problems. Im asking for help to gather intel so I can make an statement to our ISP (I work at a Dept. in a univeristy) to unblock Tor. why don't you ask them? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Very low performance in CriptolabTORRelays*
El 03/12/10 09:18, Olaf Selke escribió: On 03.12.2010 08:40, Daniel Franganillo wrote: Well, im not asking for help to run a Tor relay, I did it for more than a year without problems. Im asking for help to gather intel so I can make an statement to our ISP (I work at a Dept. in a univeristy) to unblock Tor. why don't you ask them? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Well, you know, network administrators are one species by themself. My University spent almost 1M€ (yeah, one million) in a network filtering infrastructure and we're still waiting to know *What* they are filtering and *why* (here we make network research and we need to know if something fails and why); that was one year ago... So no, I've not asked for an answer on Do you block TOR?. But I know for certain what they will answer, nothing. Thanks. -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Very low performance in CriptolabTORRelays*
Hi, On 03.12.2010 13:12, Olaf Selke wrote: At least my relay holds a couple of connections to Cryptolab. We (torservers) do, too. About the same amount of connections. Moritz *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Very low performance in CriptolabTORRelays*
On Dec 3, 2010, at 3:14 AM, Mike Perry wrote: [snip] Nope. Transfer rates are equally ridiculous. Tried in windows, same. [/snip] Out of curiosity, how long are you letting these tests run for? My nodes generally take a full 2 or 3 days to get up to full capacity, and even then, traffic through them has its sporadic highs and lows. But then, I also run nodes on the lower end of the bandwidth scale, so I'm not sure how things compare... ~Justin Aplin *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Very low performance in CriptolabTORRelays*
El 01/12/10 12:03, Jim escribió: Daniel Franganillo wrote: Hi, still no luck with our bandwidth problems. I even tried to set up a tor relay under windows (to discard a linux problem) and it does not work. Also, if I setup an https server at 9001 or 9030 and download a file from there it works fine. Can you help me to gather some clues on how our School is filtering Tor? I need that information so i can fill a request to stop Tor filtering. Thanks. PD: Will it help if I pastebin a debug log? Hi Daniel, I am surprised that nobody on this list that is more knowledgeable than I has responded to your request. I am certainly no expert here, but based both on what has been posted on this list previously and the TLS entries that ended up in your debug log, I would have to wonder if your problem doesn't have to do with an incompatibilty between the version of Tor you are using and the version of SSL you are using rather than being a problem with your school's filtering Tor. I did not respond sooner in part because, based on my (admittedly limited) understanding of these issues, I did not see a conflict between what you posted you were using, based on recent other posts about this. Still there have been recent (say the last 6 months or so) issues between Tor and SSL. I can only hope that either you can research this some yourself or somebody else with more knowledge about this will post. Good luck! Jim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ Its verly unlikely that the issue comes from an incompatible version of OpenSSL and Tor because it fails in windows too :/ Any help is welcomed, we were donating more than 1MB on bandwidht and now nothing... Thanks. -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Very low performance in CriptolabTORRelays*
Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): El 29/11/10 16:27, Daniel Franganillo escribió: Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I think no one is answering your mail because of this statement. If the Tor network is blocked by your ISP, you can't exactly expect to run a relay... Did you confirm the block? Did you try connecting to some of the other public tor relays? A simple way to do this is to just use Firefox and type in https://random.tor.node.ip and see if you get a cert warning or not. Another way to do this is to try to use Tor as a client. Does that work? How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpFqlH8oZYMa.pgp Description: PGP signature
Re: Very low performance in CriptolabTORRelays*
El 03/12/10 01:55, Mike Perry escribió: Thus spake Daniel Franganillo (dani...@dilmun.ls.fi.upm.es): El 29/11/10 16:27, Daniel Franganillo escribió: Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I think no one is answering your mail because of this statement. If the Tor network is blocked by your ISP, you can't exactly expect to run a relay... Well, im not asking for help to run a Tor relay, I did it for more than a year without problems. Im asking for help to gather intel so I can make an statement to our ISP (I work at a Dept. in a univeristy) to unblock Tor. Did you confirm the block? Did you try connecting to some of the other public tor relays? A simple way to do this is to just use Firefox and type in https://random.tor.node.ip and see if you get a cert warning or not. Our ISP wont say nothing about their filters (It seems to be a Top Secret issue :P). As I said before there's no problem reported at debug.log except for the frequent: [debug] TLS error: unexpected close while reading (SSL_ST_OK) Another way to do this is to try to use Tor as a client. Does that work? Nope. How about using a client with bridges. Do they work? https://www.sesawe.net/Using-Tor-with-Bridges.html Nope. Transfer rates are equally ridiculous. Tried in windows, same. Thanks. -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Very low performance in CriptolabTORRelays*
El 29/11/10 16:27, Daniel Franganillo escribió: Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I need your help to get some proofs of the filter being applied so we can make a statement and ask for permission. Looking at the logs I see a frequently [debug] TLS error: unexpected close while reading (SSL_ST_OK) Tor: 0.2.2.18-alpha-2 SSL: 0.9.8o-3 Thanks. PD: We even tried using bridges (as in https://bridges.torproject.org/) with no luck. [1] http://torstatus.blutmagie.de/router_detail.php?FP=b0ebd113c29fa546596dae34e88b8ad82ffdaa3d [2] http://torstatus.blutmagie.de/router_detail.php?FP=a65f3cbe32d8b52afcd2b09f0258d5cef1b12f48 [3] http://torstatus.blutmagie.de/router_detail.php?FP=1d6a27aed313662e35f550b212335d4797dccdf6 [4] http://torstatus.blutmagie.de/router_detail.php?FP=3e628de58df60a228c38fa83d000439d129d00cc Hi, still no luck with our bandwidth problems. I even tried to set up a tor relay under windows (to discard a linux problem) and it does not work. Also, if I setup an https server at 9001 or 9030 and download a file from there it works fine. Can you help me to gather some clues on how our School is filtering Tor? I need that information so i can fill a request to stop Tor filtering. Thanks. PD: Will it help if I pastebin a debug log? -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Very low performance in CriptolabTORRelays*
Daniel Franganillo wrote: Hi, still no luck with our bandwidth problems. I even tried to set up a tor relay under windows (to discard a linux problem) and it does not work. Also, if I setup an https server at 9001 or 9030 and download a file from there it works fine. Can you help me to gather some clues on how our School is filtering Tor? I need that information so i can fill a request to stop Tor filtering. Thanks. PD: Will it help if I pastebin a debug log? Hi Daniel, I am surprised that nobody on this list that is more knowledgeable than I has responded to your request. I am certainly no expert here, but based both on what has been posted on this list previously and the TLS entries that ended up in your debug log, I would have to wonder if your problem doesn't have to do with an incompatibilty between the version of Tor you are using and the version of SSL you are using rather than being a problem with your school's filtering Tor. I did not respond sooner in part because, based on my (admittedly limited) understanding of these issues, I did not see a conflict between what you posted you were using, based on recent other posts about this. Still there have been recent (say the last 6 months or so) issues between Tor and SSL. I can only hope that either you can research this some yourself or somebody else with more knowledge about this will post. Good luck! Jim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Very low performance in CriptolabTORRelays*
Hi, I'm the admin of CriptoLabTorRelays[1][2][3][4] As you can see at [1][2][3][4] our relays are having almost no transfer rate (3KB or so) It started on Monday 14 of November and after some testing we came to a conclusion... Our Univeristy (our workplace) somehow filtered Tor without us noticing. I need your help to get some proofs of the filter being applied so we can make a statement and ask for permission. Looking at the logs I see a frequently [debug] TLS error: unexpected close while reading (SSL_ST_OK) Tor: 0.2.2.18-alpha-2 SSL: 0.9.8o-3 Thanks. PD: We even tried using bridges (as in https://bridges.torproject.org/) with no luck. [1] http://torstatus.blutmagie.de/router_detail.php?FP=b0ebd113c29fa546596dae34e88b8ad82ffdaa3d [2] http://torstatus.blutmagie.de/router_detail.php?FP=a65f3cbe32d8b52afcd2b09f0258d5cef1b12f48 [3] http://torstatus.blutmagie.de/router_detail.php?FP=1d6a27aed313662e35f550b212335d4797dccdf6 [4] http://torstatus.blutmagie.de/router_detail.php?FP=3e628de58df60a228c38fa83d000439d129d00cc -- --- Daniel Franganillo Corrales --- e-mail: dani...@dilmun.ls.fi.upm.es --- CriptoLab. Despacho 6305. Facultad de Informática. Campus de Montegancedo S/N Universidad Politécnica de Madrid. Boadilla del Monte. Madrid (Spain) Teléfono - 91 336 (3673) --- smime.p7s Description: S/MIME Cryptographic Signature
Re: Performance with potential mass use
grarpamp wrote: Excluding bandwidth as that's probably the easiest to guesstimate [6x each user's use for onion2onion case]. Assuming whatever typical usage patterns exist today, and expecting a partial shift to include more bandwidth intensive apps... What sort of issues exist as each new set of say 1K/10K/100K/1000K users start using tor? - Circuits tacked up funneling bits all the time? - Circuit churn? - Loads looking up directory info, HS descriptors? - Blowing out cpu, ram, disk, OS limits to crunch it all? - And anything else really, haven't much thought about it. - How big is the impact of each affecting item? - What fixes may be on paper or in the pipeline? - Wikify this thread? Kindof a general chat, no math proofs needed :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ Simple - you'd need mass increases in the number of relays to handle mass usage. ;o) -- F. Fox *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Performance with potential mass use
Excluding bandwidth as that's probably the easiest to guesstimate [6x each user's use for onion2onion case]. Assuming whatever typical usage patterns exist today, and expecting a partial shift to include more bandwidth intensive apps... What sort of issues exist as each new set of say 1K/10K/100K/1000K users start using tor? - Circuits tacked up funneling bits all the time? - Circuit churn? - Loads looking up directory info, HS descriptors? - Blowing out cpu, ram, disk, OS limits to crunch it all? - And anything else really, haven't much thought about it. - How big is the impact of each affecting item? - What fixes may be on paper or in the pipeline? - Wikify this thread? Kindof a general chat, no math proofs needed :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
FreeBSD tweak may yield better performance
FreeBSD 7.2 and later offer a little-advertised kernel facility that benefits processes with large virtual memory requirements, in particular, large working sets. What it does is to monitor process memory requirements and to promote processes whose memory requirements become large enough to use 4 MB pages instead of 4 KB pages. The benefit to I/O bound processes will typically be very difficult to detect, but for many CPU-bound processes, the performance kick can be rather dramatic. For example, my full disk backups typically were taking in excess of 8 hours with the feature disabled, but with the feature active, the backups, the output of which gets compressed by piping it through gzip(1), finished in 4 hours and 15 minutes. For this particular task, it was like getting a new computer. Very high-data-rate tor relays apparently do use a lot of CPU time, so it occurred to me that such systems might also benefit from enabling the so-called superpages facility. I am currently only able to run a tor relay as a stealth relay to avoid detection and punishment by my ISP :-(, so I cannot run the experiment myself. If someone running a high-data-rate relay under FreeBSD 7.2 or later would like to try it, here's what you need to do. Basically, just add the following line to /boot/loader.conf and then reboot your system. vm.pmap.pg_ps_enabled=1 This sysctl variable can only be changed at boot time, and its default value is 0 (i.e., not enabled), so if you are interested in trying it, keep in mind that a reboot will be necessary to activate promotion to superpages. Note that contention for real memory will cause this facility to demote superpage processes back to 4 KB pages as required to meet systemwide memory needs. In case it isn't obvious where the performance enhancement comes from, consider that most/all modern CPUs from Intel and AMD have TLBs that hold a maximum of 128 entries, each one containing a mapping of a virtual memory page to a real page frame's base address. That means that the TLB can cache translated addresses covering a maximum of 512 KB when 4 KB pages are in use. If a process's working set exceeds that size, then there will be frequent TLB misses, each of which causes a processor stall while that DAT circuitry goes through the full address translation process, complete with multiple fetches from memory. This seems especially wasteful when one considers that the data or instructions needed by the processor might actually already be in L1 cache lines, but inaccessible without a fresh, full address translation. :-( By contrast, a process that has been promoted to superpage usage has had its TLB entry requirements reduced by as much as a factor of 1024, so the entire process might need only a few TLB entries, after which no further address translations need be done, except when context switches have caused TLB entries to be purged. Anyway, if someone running a high-data-rate tor relay on a FreeBSD system of release 7.2 or later would like to try the above tweak and report back to the list any observed changes in performance, I would be grateful for the information. torstatus.kgprog.com currently shows 9 relays with peak traffic rates greater than 1 MB/s that run on FreeBSD systems, although the release level is not shown. Those very active relays are the ones I would expect to see get the greatest benefit from using superpages. 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Roger's HAR2009 talk on Tor performance
From Tor Blog | Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last week in The Netherlands. I did a talk on Tor performance challenges — basically walking through the key pieces of the Why Tor is Slow document that we wrote in March. As usual with European hacking cons, they produced a really well-done video just days after my talk. So if you want to get the highlights on what we're doing to speed up Tor and what roadblocks remain, take a look at the video and also the slides that come with it. | I just put a torrent of this up at http://www.johntowery.com/har2009_Why_Tor_is_slow.mp4.torrent It uses the hidden tracker and should work for Tor users and non-tor users. It actually appears to be down right now but it'll come up eventually. It has both the regular .onion and the tor2web url in it. Ringo
Re: Roger's HAR2009 talk on Tor performance
On Wed, Aug 19, 2009 at 05:19:20PM -0400, Ringo wrote: Jake, Mike, Karsten, Sebastian, and I attended Hacking at Random last week in The Netherlands. I did a talk on Tor performance challenges ? basically walking through the key pieces of the Why Tor is Slow document that we wrote in March. As usual with European hacking cons, they produced a really well-done video just days after my talk. So if you want to get the highlights on what we're doing to speed up Tor and what roadblocks remain, take a look at the video and also the slides that come with it. Right. For those who like to see the links too, see https://blog.torproject.org/har2009-video-tor-performance --Roger
Re: Roger's HAR2009 talk on Tor performance
It uses the hidden tracker and should work for Tor users and non-tor users. It actually appears to be down right now but it'll come up eventually. It has both the regular .onion and the tor2web url in it. Yep, we're down right now. Sorry about the inconvenience. We're expecting to be up and down for a little while while we make some fairly comprehensive overhauls. In the mean time, publicbt.org, and openbittorrent.com should work for you. If anyone wants to stay in the look about our 'scheduled' downtime, and other hidden-tracker-related goodness, @hiddentracker on twitter has all the news.
Re: Roger's HAR2009 talk on Tor performance
Well given this, I've added a few other trackers, file at the same spot: http://www.johntowery.com/har2009_Why_Tor_is_slow.mp4.torrent Ringo The Hidden Tracker wrote: It uses the hidden tracker and should work for Tor users and non-tor users. It actually appears to be down right now but it'll come up eventually. It has both the regular .onion and the tor2web url in it. Yep, we're down right now. Sorry about the inconvenience. We're expecting to be up and down for a little while while we make some fairly comprehensive overhauls. In the mean time, publicbt.org, and openbittorrent.com should work for you. If anyone wants to stay in the look about our 'scheduled' downtime, and other hidden-tracker-related goodness, @hiddentracker on twitter has all the news.
Re: aes performance
On Wed, Feb 25, 2009 at 08:20:48PM -0500, pho...@rootme.org wrote 0.4K bytes in 9 lines about: : One fine way to find out is to run oprofile and see what tor is doing. : you'll even find out the most popular calls as it's cranking away. I took my own advice and ran 'valgrind --tool=callgrind' on my tor server. The resulting callgrind file can be found at http://interloper.org/tmp/tor/callgrind.out.23678.gz. One could use kcachegrind or other profiling programs to create pretty graphs or otherwise analyze the output. For example of a pretty graph, this is the callgraph of tor starting, http://interloper.org/tmp/tor/2009-02-27-tor-callgrind-0.png -- Andrew
Re: aes performance
I wrote: as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k stupid! I mixed up openssl's benchmark bytes/s from the table above with bits/s network throughput. Now it appears only 10% tor's cpu usage is spent within aes crypto. What the heck is tor doing the remaining 90%? confused, Olaf
Re: aes performance
On Wed, 25 Feb 2009 22:59:14 +0100 Olaf Selke olaf.se...@blutmagie.de wrote: I wrote: as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k stupid! I mixed up openssl's benchmark bytes/s from the table above with bits/s network throughput. Now it appears only 10% tor's cpu usage is spent within aes crypto. What the heck is tor doing the remaining 90%? Olaf, your system is one of 14 or 15 tor relays that routinely peak at more than 5 MB/s. You have, in the past, stated that it typically has ~5,000 established connections simultaneously. I would guess that key exchange operations on a system loaded like that must take up an awful lot of CPU time. My relay peaks at about 1/10 of blutmagie's peaks. tor's primary CPU percentage range seems to be 0% - 13% (2-second averages) on my 3.4 GHz P4 Prescott (which is also a Netburst chip). Occasionally, it will consume more than that for a brief time, sometimes as much as 30% - 40%, but those events usually last only a couple of seconds. Given these numbers, your figures seem reasonable. 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 * **
Re: aes performance
On Wed, Feb 25, 2009 at 10:59:14PM +0100, olaf.se...@blutmagie.de wrote 0.8K bytes in 17 lines about: : bits/s network throughput. Now it appears only 10% tor's cpu usage is : spent within aes crypto. What the heck is tor doing the remaining 90%? One fine way to find out is to run oprofile and see what tor is doing. you'll even find out the most popular calls as it's cranking away. -- Andrew
Re: aes performance
slush wrote: Oh, also dont forget that openssl speed runs only on one core! yes, I know I tested it on my server 2x dualcore Xeon 3GHz and results: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 92860.55k 120028.42k 130562.36k 132490.03k 135248.26k aes-192 cbc 82754.33k 102625.36k 110524.08k 113481.96k 114419.55k aes-256 cbc 74095.94k90670.80k96039.18k97677.96k 98717.71k .. but you have to multiple number by 4. So teoretical limit (in my case) is 371 MB/s and it is absolutely enough to run fast Tor node :-). I dont know how much cores you have, but dont forget on that... nope, just one core is used by tor for aes crypto. So the openssl speed aes command should give an idea about tor's throughput. Olaf
Re: aes performance
Tor FAQ: I have more than one CPU. Does this help? Yes. You can set your NumCpus config option in torrc to the number of CPUs you have, and Tor will spawn this many cpuworkers to deal with public key operations in parallel. nope, just one core is used by tor for aes crypto. So the openssl speed aes command should give an idea about tor's throughput. Are you sure? Marek
Re: aes performance
Olaf Selke wrote: hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. If you're going to replace hardware, hardware assisted encryption may be an option. Recent VIA CPUs like the C7 and the Nano can do that. Their clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. Resuls for VIA Nano (with 32-bit openssl): VIA Nano 1.6 GHz with padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 69796.09k 275407.68k 585574.57k 815018.33k 920136.36k aes-192-cbc 52670.82k 208539.14k 472485.55k 691277.82k 798340.44k aes-256-cbc 50984.77k 201934.27k 439964.25k 623764.14k 709612.89k VIA Nano 1.6 GHz without padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 41429.86k 55836.29k 60886.87k 62508.03k 62974.63k aes-192-cbc 35838.02k 47521.62k 51671.72k 52854.10k 53177.00k aes-256-cbc 33208.77k 41789.16k 45009.83k 45891.24k 46153.73k Performance for 16-byte blocks is pretty poor, but for bigger blocks it's much faster. A VIA C7 running at the same clock frequency should produce similar results.
Re: aes performance
You're mistaken here. AES *always* has a block size of 128 bits (it was one of the requirements for the competition to create the AES standard). The algorithm on which AES is based (Rijndael) can support 192 or 256 bits, but this is considered nonstandard today, and does not provide any provable benefit to security. The variable in AES that we usually refer to (as in aes-128) is the key size. Smaller key sizes mean a smaller key space (technically, easier to bruteforce, but still unreasonably hard at present), but they are also dramatically slower. If I recall correctly, aes-192 is almost 50% slower than aes-128 and aes-256 is an additional 15-25% (but I don't have a source for those numbers at this time). AES-128 is still considered secure. All of that aside, the encryption speed is a non-issue here. Unless you're using a large portion of a gigabit connection, AES will work far faster than your line speed on a modern processor. Additionally, just measuring the speed of that algorithm is very far from the entire story; there are MACs involved and tor has its own things that need to be applied, including layers of encryption. Still, I don't see encryption being a large issue for any but low-powered machines with high bandwidth connections. - John Brooks On Mon, Feb 23, 2009 at 9:23 AM, Arjan n6bc23cpc...@list.nospam.xutrox.comwrote: Olaf Selke wrote: hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. If you're going to replace hardware, hardware assisted encryption may be an option. Recent VIA CPUs like the C7 and the Nano can do that. Their clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. Resuls for VIA Nano (with 32-bit openssl): VIA Nano 1.6 GHz with padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 69796.09k 275407.68k 585574.57k 815018.33k 920136.36k aes-192-cbc 52670.82k 208539.14k 472485.55k 691277.82k 798340.44k aes-256-cbc 50984.77k 201934.27k 439964.25k 623764.14k 709612.89k VIA Nano 1.6 GHz without padlock engine type 16 bytes64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 41429.86k 55836.29k 60886.87k 62508.03k 62974.63k aes-192-cbc 35838.02k 47521.62k 51671.72k 52854.10k 53177.00k aes-256-cbc 33208.77k 41789.16k 45009.83k 45891.24k 46153.73k Performance for 16-byte blocks is pretty poor, but for bigger blocks it's much faster. A VIA C7 running at the same clock frequency should produce similar results.
Re: aes performance
John Brooks wrote: You're mistaken here. [...] My point was that the '16 bytes' column was showing significantly worse results than the other columns. It's because of overhead for more function calls, setting up keys, setting up initialization vectors, ... All of that aside, the encryption speed is a non-issue here. Unless you're using a large portion of a gigabit connection, AES will work far faster than your line speed on a modern processor. Additionally, just measuring the speed of that algorithm is very far from the entire story; there are MACs involved and tor has its own things that need to be applied, including layers of encryption. Still, I don't see encryption being a large issue for any but low-powered machines with high bandwidth connections. Encryption speed is indeed only part of the problem, but on my LAN (with a few years old hardware), the VIA Nano is by far the fastest when doing SFTP file transfers or disk encryption.
Re: aes performance
On Mon, 23 Feb 2009 16:59:21 +0100 slush sl...@slush.cz wrote without proper attribution (tsk, tsk): Tor FAQ: I have more than one CPU. Does this help? Yes. You can set your NumCpus config option in torrc to the number of CPUs you have, and Tor will spawn this many cpuworkers to deal with public key ^^ AES is a symmetric-key cipher, not an asymmetric-key cipher, so there are no public key operations involved in AES encryption/decryption. The answer shown in the FAQ is poorly stated. Rather than Yes., it should have said, Not very much. It only makes much difference on extremely high throughput systems, where onionskins may be queued for decryption far faster than a single processor might be able to keep up with. It also keeps onionskin decryption operations from interfering with other tor processing by moving those operations off of the core is handling the rest of tor's work. operations in parallel. 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 * **
Re: aes performance
John Brooks schrieb: All of that aside, the encryption speed is a non-issue here. Unless you're using a large portion of a gigabit connection, AES will work far faster than your line speed on a modern processor. it depends :-) I supposed cpu encryption speed being the limiting factor for the majority of the top 20 nodes: http://trunk.torstatus.kgprog.com/index.php?SR=BandwidthSO=Desc With aes-128 and 16 byte blocks my node would be limited to 42 MBit/s even if all cpu time would be spend within aes crypto, which isn't very realistic. Olaf
Re: aes performance
On Mon, Feb 23, 2009 at 8:23 AM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. i think you mean buffers (or at least multiples of 16 byte blocks); and yes the 4096 byte or larger buffers would be nice to get the most of the rep style XCRYPT instruction chaining. ... clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. it is also worthwhile to accelerate the public key ops with MONTMULT on the padlock core. there is assembly optimized code for this in openssl 0.9.9 (work in progress). the bottleneck for Tor on these CPU's becomes the libz compression/decompression overhead with padlock enabled. best regards,
Re: aes performance
coderman wrote: On Mon, Feb 23, 2009 at 8:23 AM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. i think you mean buffers (or at least multiples of 16 byte blocks); and yes the 4096 byte or larger buffers would be nice to get the most of the rep style XCRYPT instruction chaining. Yes, that's what I meant. ... clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. it is also worthwhile to accelerate the public key ops with MONTMULT on the padlock core. there is assembly optimized code for this in openssl 0.9.9 (work in progress). the bottleneck for Tor on these CPU's becomes the libz compression/decompression overhead with padlock enabled. My upload speed is much too slow to run into this problem, but could the compression be (partially) disabled for middle nodes? I'm assuming that the data they are relaying has already been compressed + encrypted, so it wouldn't compress much anyway.
Re: aes performance
On Mon, Feb 23, 2009 at 12:29 PM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... My upload speed is much too slow to run into this problem, but could the compression be (partially) disabled for middle nodes? I'm assuming that the data they are relaying has already been compressed + encrypted, so it wouldn't compress much anyway. it would be interesting to see how roles (middle, exit, directory cache) affect the crypto overhead. i suspect you're right, that a middle only would opt toward the traffic it is most effective at (lots of AES, fewer pubkey ops, fewer compressed payloads). i have no if this would make a significant impact, or get you past other CPU limits for network saturation. would be a fun experiment for someone with the bandwidth/lab setting and some C7 cores... :) best regards,
aes performance
hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. Olaf
Re: aes performance
It is in kilo _bytes_, isnt it? I think 84MB/s isnt that bad result :). [snip] The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 51108.77k68049.87k73548.62k73809.19k 75586.27k aes-192 cbc 45487.20k57737.88k61597.64k62914.12k 63948.21k aes-256 cbc 40880.73k50780.57k54186.47k55259.88k 54481.37k [snip] ... everything is measured in bytes... Well, results are from old laptop, but 51MB/s isnt also so bad... Marek On Sun, Feb 22, 2009 at 2:52 PM, Olaf Selke olaf.se...@blutmagie.de wrote: hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. Olaf
Re: aes performance
Oh, also dont forget that openssl speed runs only on one core! I tested it on my server 2x dualcore Xeon 3GHz and results: type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 92860.55k 120028.42k 130562.36k 132490.03k 135248.26k aes-192 cbc 82754.33k 102625.36k 110524.08k 113481.96k 114419.55k aes-256 cbc 74095.94k90670.80k96039.18k97677.96k 98717.71k .. but you have to multiple number by 4. So teoretical limit (in my case) is 371 MB/s and it is absolutely enough to run fast Tor node :-). I dont know how much cores you have, but dont forget on that... Marek On Sun, Feb 22, 2009 at 2:52 PM, Olaf Selke olaf.se...@blutmagie.de wrote: hello there, as I understood tor spends most of its cpu time within openssl library aes crypto. Which result of openssl speed aes applies to tor? Is it aes-128 cbc 16 bytes? In this case my old Prestonia P4 Netburst Xeon box's throughput is supposed to be roughly about 40 MBit/s as middleman. Correct? type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 84098.99k 119729.69k 138053.97k 142741.16k 144386.04k aes-192 cbc 75035.35k 104143.72k 115681.81k 120099.84k 120949.42k aes-256 cbc 69559.47k92221.78k 102006.05k 105361.75k 100274.74k Strange to say that my desktop Core2 Duo E8400 @home performs only 33% better in openssl aes crypto than one of the old P4 Netburst Xeon cores from my tor node. For the sake of better performance I'm thinking about replacing my tor node's hardware. Olaf
Re: Performance optimizations for high-bandwidth Tor exit
6cnf6c...@sneakemail.com wrote: Are there any performance tweaks to limit Tor's CPU consumption? Compiling the openSSL library source code package with Intel's C compiler icc instead of using the gcc-precompiled Debian package tor's performance increased about 25% on my Intel Xeon Linux box anonymizer.blutmagie.de. Compiling tor with icc doesn't change any thing noticeable. cheers Olaf
Re: Performance optimizations for high-bandwidth Tor exit
Hi! On Sat, Dec 20, 2008 at 4:13 AM, 6cnf6c...@sneakemail.com wrote: I now want to play around with hidden services, and noticed that Apache takes a very long time to reply, even to local requests. Do you use this same Apache as a proxy to directory server? Mitar
Performance optimizations for high-bandwidth Tor exit
Hallo, I've been running a Tor exit node on one of my machines (Intel Dual E2160 (1.8GHz), 2GB RAM, Xen domU for Tor, encrypted HDD) for some months. It is on a shared 100MBit/s line (500GB in/out daily). I have not configured any bandwidth limits within Tor. Most of the time, the Tor process maxes out the CPU (85-100%), while memory consumption stays at ~10%; until today, this didn't pose much of a problem as log files show no errors and the machine has been used exclusively for Tor. I now want to play around with hidden services, and noticed that Apache takes a very long time to reply, even to local requests. As I am already using Xen, I thought it might be possible to share CPU and memory intelligently between two domUs (with the Tor domU having lower priority), but I didn't find any useful information how to do that. Are there any performance tweaks to limit Tor's CPU consumption? NumCPUs is set to 2, other than that I didn't modify the default configuration much. Also, niceness is set to +15 for the tor process. I want to avoid setting a fixed bandwidth limit, Tor should use as much as it gets. Will upgrading the CPU help? -Daniel
Re: Performance optimizations for high-bandwidth Tor exit
On Sat, Dec 20, 2008 at 03:13:00AM -, 6cnf6c...@sneakemail.com wrote 1.1K bytes in 26 lines about: : Most of the time, the Tor process maxes out the CPU (85-100%), : while memory consumption stays at ~10%; until today, this didn't : pose much of a problem as log files show no errors and the machine : has been used exclusively for Tor. Any chance you could run oprofile and tell us where the cpu is burning cycles? My guess is it's in openssl over actual tor code. : I now want to play around with hidden services, and noticed that : Apache takes a very long time to reply, even to local requests. Is this because the cpus are consumed with handling tor? : configuration much. Also, niceness is set to +15 for the tor : process. I want to avoid setting a fixed bandwidth limit, Tor : should use as much as it gets. Will upgrading the CPU help? So, my personal experience is that the switch from Xeon to AMD64 cpus dramatically changed the cpu usage with as many other variables staying constant. However, it's probably not a practical change for you. -- Andrew
Hidden Service Performance [was: Re: How many hidden service circuits built?]
On Saturday 13 December 2008, Karsten Loesing wrote: Hi Bernhard, Bernhard Fischer wrote: Sorry, I didn't see this before. I'll read your paper and I appreciate all improvements regarding hidden services. You might also want to read the documents that are linked from the NLnet project page, for example: http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf Thanks, I had a look at it. Your measurements regarding message transfer reflect pretty much the observations I did. While TOR is building circuits there's always some kind of randomness involved. As far as I know TOR chooses nodes based on directory flags (like fast, stable, ...) and the randomizes those matching some criteria. Obviously the flag fast is somehow misleading because bandwidth is a local property and does not necessarily mean that it's also fast across the network to any other node. Okay, we didn't change anything about path selection so far. One reason is that this might have serious consequences on anonymity. While it would be great to make Tor and hidden services faster by using only the best nodes available, this largely destroys anonymity. All changes here should be made with extra caution! Of course, you are right. Changes in the path selection algorithm should be done with caution. But it was just an idea which looked feasible for me from a user perspective (SOCKS interface) without changing TOR, thus not risking loss of anonymity. I did some RTT measurements and my observations are really ugly. It usually is never below 5s. What you can observe is that when the circuit is rotated the RTT also changes signifficant. See the measurements in the analysis linked above. This document contains some data about message transfer times after connections are established. Basically, we excluded message transfer times from the project, because they didn't seem to be a problem of hidden services, but rather of Tor in general. That could also be possible. I didn't scientifically proven measurements yet, but I will do. Maybe it's a problem of TOR *and* hidden services. Another solution is to start performing QoS for hidden services. In combination with client authorization (see proposal 121), hidden servers could decide whether to pick an extra-fast circuit to connect to the client's rendezvous point, or not. Having said that, did you look at proposal 121 for OnionCat. I could imagine that OnionCat would make good use of the additional security that client authorization offers for hidden services. See also a Technical Report on that topic: http://petsymposium.org/2008/hotpets/vrtprsvc.pdf QoS sounds good but I think it might have same troubles in its deployment as it has in plain Internet. QoS was foreseen in IP since decades but never used network-wide. Until today QoS is always a local service limited to the network of a provider or company. I can imagine that QoS deployment will last very long until it works TOR-network-wide for similar reasons. Regarding authorization: Thanks, I already knew proposal 121 before and I did test those authorizations features. They work and seem to be very useful for some scenarios. Best Regards, Bernhard signature.asc Description: This is a digitally signed message part.
Re: Performance
True, I did take that into account. I could be mistaken but I think the main problem lies with the proxy software. I think that Polipo and, especially, Privoxy are pretty resource intensive, and affect performance more than Tor itself. Polipo has been shown to be faster than most browsers' implementation of HTTP. As for resources consumed, people are running Polipo on embedded routers with 16 MB of memory. Juliusz
Re: Performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know. My statement below is wrong. Juliusz Chroboczek wrote: True, I did take that into account. I could be mistaken but I think the main problem lies with the proxy software. I think that Polipo and, especially, Privoxy are pretty resource intensive, and affect performance more than Tor itself. Polipo has been shown to be faster than most browsers' implementation of HTTP. As for resources consumed, people are running Polipo on embedded routers with 16 MB of memory. Juliusz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkCQS0ACgkQ3ju7mowpX9UJSACg03OMPB+FTZ4ZHraW80maOzHw +OYAnie8SOvQ6nNcufXGVBTeeIToi1pR =C/cN -END PGP SIGNATURE-
Re: Performance
In tor version Tor-0.2.15-alpha, in the file circuitbuild.c change 'routelen = 3;' to 'routelen = 2;' (at line 1070). That's it. Martin * on the Wed, Oct 22, 2008 at 04:49:35PM +0200, Martin Balvers wrote: I have changed the route length to 2 hops How did you manage to do this? I know you have to edit the source code, but what specifically needs changing in it? I remember attempting this a while ago but haven't looked recently... -- Erilenz
Performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have been using tor for about four months. Tor release - 0.2.0.30 running on an MS Windows XP SP2 system. Browser - 1) Sea Monkey (Mozilla) with Polipo 1.0.4 2) MS IE6 with Privoxy 3.0.8 Using either browser, performance has been abysmal (I am not exaggerating). Time-outs occur, and pages have to be re-loaded. When I say performance has been abysmal, I mean that average response time has increased by at least one order of magnitude when compared to using a browser with a direct connection to the Internet. On my system, I also have Firefox. Currently, it is not configured to use any proxy. When it was, performance was as bad as it is using Sea Monkey or MS IE. I believe I am a fairly typical user in as much as I browse to access information, news, make reservations, and purchase goods and services. However, I am also a believer in the value and importance of the function performed by Tor, and are committed to using it. This is why I am willing to live with the very poor performance. However, I do not believe that the vast majority of users are as willing to do so. I am not sure about the goals of the group developing and managing Tor are. If there is a desire to provide this very valuable service to the average user, then I do not see how this can happen until the performance problem has been resolved. Obviously, it could well be that I have made one or more mistakes in configuring Tor, Polipo, and Privoxy. I would be very glad if this were the case. I would appreciate any input from the group about this, and any ideas for improving performance. Thank you. Alex Donnini -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj/G+sACgkQ3ju7mowpX9UivwCeNTpAUfdmCL4nUnbbkJe5FfXq dC4AnjvbE5/n+1SKtju6Wz8jmkalndZ5 =Jr9u -END PGP SIGNATURE-
Re: Performance
You are right, performance usually sucks. You can get lucky sometimes, and pick a route that actually has low latency, but that doesn't seem to happen very often. Keep in mind that latency will always be higher than without tor, you do have to connect through 3 additional hops to get to your destination. If every hop happens to be on the other side of the planet, it can add up. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have been using tor for about four months. performance has been abysmal // Other stuff
Re: Performance
The problem isn't the proxy software, it's the tor network. There are a lot of node that are really slow, and i don't mean bandwidth, but latency. I have changed the route length to 2 hops, and i excluded some countries altogether (i know this is bad for anonymity, but i'm ok with that). I have also selected some nodes that seem to work good for me as entry nodes. This has made it a bit more usable. I noticed that i still have very poor performance sometimes, even with fast (as in bandwidth) nodes. Some nodes taht i found to have high latency are blutmagie,chaoscomputerclub23 and kyirong (drops most connections). gpfTOR3,SEC,dotplex1 and Tonga seem to have low latency. It's not a static thing though, sometimes the 'slow' nodes perform ok and sometimes the 'fast' nodes perform poor, but overall it seems there are 'good' and 'bad' nodes. Maybe it's some hardware/network issue of the particular nodes. Martin Alessandro Donnini schrieb: True, I did take that into account. I could be mistaken but I think the main problem lies with the proxy software. I seriously doubt that. But you can check that if you use Polipo/Privoxy, but not Tor. Dominik
Re: Performance
The main reason why Tor currently has bad performance is that it multiplexes multiple circuits (and therefore the streams in those circuits) under the same TLS(TCP) connection. This is very important from the security perspective, but causes problems when any link in the circuit that you chosen is under congestion. When a link is under congestion, packet drops in that connection will make the TCP connection to slow down (tcp transforms reduced bandwidth into latency). Thus if only one stream is of heavy traffic, the latency of all other streams that share that connection will be increased. It is now known that bulk traffic accounts for 40% of Tor's exit traffic (It is impossible to estimate hidden traffic) thus there is a very high probability that you are sharing the connection with one of those streams. Further if there are any hosts in you circuit that do not use TCP extensions for high bandwidth-delay products (windows machines have this options disabled by default), this 'side-effect' would be increased. To test this, even on a 'fast circuit' try making 2 bulk downloads while simultaneously browsing.. the latency of the browsing will be abysmal, even tough the total throughput is ok. Currently, there are two research paths to solve this on Tor : A proposal by Joel Reardon that creates per circuit and hop userspace TCP stacks for each circuit and a proposal by Camilo Viecco (myself) to use a single TCP session for active each stream from the application at the client to the exit node. There is running source code (and a running network) for my proposal mostly as a Proof on concept (that is ,the network is really small, ,the code is still not ready for production, is not available as binaries, nor compiles in windows machines (only linux, and osx)) but that you can use now for testing purposes. To download from the public svn repo: 'svn checkout */http/*://tdor.googlecode.com/svn/trunk/ tdor-read-only'/ . This code illustrates that you can have low latency while keeping anonymity. I would love to hear more from testers, but I will restate the caveat : this network provides very little anonymity as I am in control of all of the infrastructure (And why would you trust me). I am very confident that some solution to the latency will be available in Tor in the next two years, but for now we have to live with this Camilo PS. The paper with the traffic statistics is available here: http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf Dominik Schaefer wrote: Alessandro Donnini schrieb: True, I did take that into account. I could be mistaken but I think the main problem lies with the proxy software. I seriously doubt that. But you can check that if you use Polipo/Privoxy, but not Tor. Dominik
Re: Performance
* on the Wed, Oct 22, 2008 at 04:49:35PM +0200, Martin Balvers wrote: I have changed the route length to 2 hops How did you manage to do this? I know you have to edit the source code, but what specifically needs changing in it? I remember attempting this a while ago but haven't looked recently... -- Erilenz
Re: Performance
Marco Bonetti schrieb: doesn't changing the CircuitBuildTimeout and the NumEntryGuards give an advantage to an attacker which is spying on your connections? IIRC it should be mentioned in the design documents: an attacker which is reading traffic can isolate clusters of users depending on their tor client behavior and then launching other types of attack on them with higher percentage of success due to the previous clustering. That point was always one that prevented me from playing around with too many Tor settings. In addition, I am not sure, if it won't harm the Tor network as a whole if too many peoply tune their options to prefer low-latency circuits and/or certain high-bandwidth relays, which will cause even more frustrated users who also use the same tips and so forth... Dominik
Re: Performance
Thus spake Marco Bonetti ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Perry wrote: The Tor settings are by far the more impactful of the two, I've found. doesn't changing the CircuitBuildTimeout and the NumEntryGuards give an advantage to an attacker which is spying on your connections? IIRC it should be mentioned in the design documents: an attacker which is reading traffic can isolate clusters of users depending on their tor client behavior and then launching other types of attack on them with higher percentage of success due to the previous clustering. Timeout is only observable for cases where circuits fail to complete within that timeout period, and this information doesn't easily transfer to circuits that do complete unless you are the guard node. However, the guard already has much better identifers to work with (such as IP, TCP fingerprint, and potentially some information on Tor version). Now, a middle node could potentially use some statistics about how quickly a guard is known to extend circuits and try to cluster circuits by distribution of their timeouts this way, but it only gives that middle node information for the circuits clients AREN'T using. Because failed circuits are completely abandoned and not partially restarted, this information does not readily transfer well for circuits that succeed unless you are the guard node too (which means you have two hops in the circuit, and would have much better luck using that effort to have your two hops be guard and exit). -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpT7soeFD2Tk.pgp Description: PGP signature
Re: Performance
Thus spake Dominik Schaefer ([EMAIL PROTECTED]): Marco Bonetti schrieb: doesn't changing the CircuitBuildTimeout and the NumEntryGuards give an advantage to an attacker which is spying on your connections? IIRC it should be mentioned in the design documents: an attacker which is reading traffic can isolate clusters of users depending on their tor client behavior and then launching other types of attack on them with higher percentage of success due to the previous clustering. That point was always one that prevented me from playing around with too many Tor settings. In addition, I am not sure, if it won't harm the Tor network as a whole if too many peoply tune their options to prefer low-latency circuits and/or certain high-bandwidth relays, which will cause even more frustrated users who also use the same tips and so forth... Actually, it should have a balancing effect where traffic automatically avoids overloaded nodes that have trouble completing circuit extends due to their load. That is, unless the timeout is set too low (where clients create tons and tons of circuit attempts without ever completing any). This could easily lead to a DoS condition on the network, which is one of the reasons we have not yet lowered the timeout in the Tor distribution. My Google Summer of Code student (Fallon) was tasked with implementing some statistics to determine the timeout automatically per client, but unfortunately she did not complete her project due to time conflicts for her unrelated thesis work... -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpZHDka4AuTD.pgp Description: PGP signature
Re: Paid performance-tor option? [2]
Apropos to see and deja-vus ... Georgia (and George [on 9/11]): And The Kremlin attempted to reach Saakashvili, WHO WAS HIDING, by phone. Update: Ukraine opposition to send Georgian leader neckties to chew on KIEV, August 22 (RIA Novosti) - Ukraine's opposition party has pledged to send 365 neckties to Georgian President Mikheil Saakashvili, who was recently caught on camera nervously chewing his garment while discussing the Georgian-Russian conflict. Saakashvili has caused an internet sensation with his tie-chewing antics, captured during a phone conversation with a top Western official and aired by the BBC, and also over footage of him running in apparent terror after speaking to reporters, believing he was about to be attacked by Russian planes. ... Party of Regions lawmaker Boris Kolesnikov told a crowd of supporters in the east Ukrainian city of Donetsk: We have already bought Saakashvili spiked running shoes, similar to those worn by the Jamaican sprinter who won the Olympic 100 meters. We will also buy him 365 neckties, so that he will have enough to chew on every day of the year. Etc., full article at: http://en.rian.ru/world/20080822/116219864.html Hence, at a 2nd thought BBC is not completely useless [as I have stated in a previous post, here at the list], after all. :) /Roy Lanek -- S bagai air di daun talas--as if water on a S . s l a c k w a r e SS leaf of talas [two things that never get S + linux SS along ... talas has a thin waxy layer and S therefore is waterproof]
Re: Paid performance-tor option? [2]
Do you see the implications [cherries-like: Madrid, 7/7, ..., Georgia right now] of that? Apropos to see and deja-vus ... Georgia (and George [on 9/11]): ... The Georgian air force and artillery struck the sleeping town at midnight. More than 1,500 civilians perished in the very first hours of the shelling. At the same time, Georgian special forces shot 10 Russian peacekeepers who didn't expect such a betrayal from their Georgian colleagues. The Kremlin attempted to reach Saakashvili, WHO WAS HIDING, by phone. All this time the Russian Joint Staff forbid the surviving peacekeepers to open return fire. Finally our patience was exhausted. The Russian forces came to help Tskhinvali and its civilian population. ... [emphasis mine] Reference is: Washington's Hypocrisy by Dmitry Rogozin Global Research, August 18, 2008 International Herald Tribune http://globalresearch.ca/index.php?context=vaaid=9869 /Roy Lanek -- S tak bisa menari dikatakan lantai yang S . s l a c k w a r e SS berjungkit--cannot dance but blame the S + linux SS floor as uneven [blaming the wrong reason] S
Illuminati (was: Re: Paid performance-tor option?)
Am 20.08.2008 um 05:49 schrieb Roy Lanek: 9/11 has been planned much earlier than 2001. Dear Mr Fletcher (sic!), I don't think that this mailing-list is the appropriate place to propagate your FUD based conspiracy theories as if they were facts. So would you mind to stop it? Beside that, as other posters stated already, your style of writing with all these brackets and sidetracks is very stressful to read, especially for a non-native-speaker like me. I get headaches every time I try. But this is probably due to the implant in my head, that some secret agency equipped me with in an unwary moment, and now wants to hinder me to find out THE TRUTH. You watched Zeitgeist once too often? Sven -- http://sven.anderson.deBelieve those who are seeking the truth. tel:+23-232-3232323 Doubt those who find it. mobile: +32-323-2323232 (André Gide)
Re: Paid performance-tor option?
mplsfox02, This study was performed by Privacy International, as far as I am aware. I think it best to forget how they decided to color code the map, and just look at the numbers inside the columns. It would also be of interest in how they went about acquiring their data, and what the standards were. For the specifics, we are interested in those columns I pointed out, as those are directly related to internet privacy. The rest are areas that are outside the scope of our threat model. Arrakis [EMAIL PROTECTED] wrote: Arrakis: [EMAIL PROTECTED] wrote: macintoshzoom: Sorry, just re-reading my post, I am partially wrong, JONDONYM (formerly JAP) is still running its main nodes from compromised countries. There are no compromised or safe countries as there is no hostile or friendly network. Any concepts based on such assumptions are doomed. You may care to take a look at this, specifically the 5th, 7th, 8th, and 9th columns. Not all countries are equal, especially when those countries to data interception and data retention themselves. http://www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597 Thanks for the link. That does not contradict to what I said. Who did this study? I cannot rely my security concept on some human estimates. It's interesting, though. There are differences, but no country is dark green or even cyan. This study is more a journalistic than a scientific one, since the information it is based on is not always comparable and does not represent all the characteristics that are important for privacy. Maybe Greece is just better in hiding the breaches?
Re: Paid performance-tor option?
On Tue, 19 Aug 2008 11:45:52 +0700 Roy Lanek [EMAIL PROTECTED] wrote, quoting me without attribution: Why, to the administration at the university (or the bosses at the company) one works for or to one's ISP, of course. Perhaps also to a judge. Wasn't that obvious? No, it was not obvious. And it STILL is not. Oh. Okay. Let me attempt to clarify. First, let me say that I do not know which country's/countries' environment(s) inform(s) your perspective, so I will try to explain what a tor server operator here in the U.S. may well be up against. tor server operators generally fall into one or both of the following categories: those who run their servers using their employers' resources and those who run their servers using their own private resources. Those who use their employers' resources do so either with their employers' official or tacit approval or without approval, in the latter case perhaps following the ancient maxim that it is better to ask forgiveness than to ask for permission. In either situation, the server operator who wishes to continue to be allowed to run the server should avoid drawing unwanted management attention to the server. Server activities that cause complaints that may result in legal hassles for the employer are especially likely to get the server shut down, and in some situations might even result in some sort of disciplinary action against the server operator. A partial exception to this is likely to be found in academic institutions and some kinds of non-profit and/or advocacy organizations. Colleges, universities, and public research insititutions (DOE-operated national labs excepted, of course), for example, have a strong traditional streak of support for the freedoms of press and speech--yes, those very same ones found in the first ratified article of amendment to our now discarded Constitution--and may well be more likely than businesses to stand up for the freedom of electronic communication fostered by tor, but that doesn't mean that they would be happy about devoting their limited legal counsel resources to defend an employee's pet tor server's configuration. They may also not wish to devote potentially 80% - 90% of their bandwidth budget to people stealing copyrighted movies, etc., rather than to uses that are normally part of the institutions' missions. That may still go on, of course, but not identifiably so if their is no open exit for it. tor server operators using their own private resources for their servers face a related reality. Most are running their servers on their computers at home over an ISP's link to the Internet and are thus at the mercies of their ISPs. In many areas, there is only one ISP to choose from, so if a tor server's activities cause the ISP to drop the customer's service, that tor server is effectively shut down permanently. Where more than one ISP is available, service levels and prices typically differ from one ISP to the next. If a server operator is currently getting the best deal available in the area, then there is a strong incentive not to allow one's exit server's activities to drop the account. In some countries, e.g., Germany, tor server operators have been arrested and their equipment (and data!) have been confiscated because of some of their servers' exit activities. A typical home server operator is not going to be well prepared to afford the time, stress, or money to face such situations. Besides, what are you trying to say, that one--example--as a soldier [I have been in the army], or, more in general, as a pawn needs to let go a slap on the butt of the waitress bringing food or a drink at a restaurant so to become accepted by his bosses and the others? I have no idea what that is about, much less how it is supposed to be relevant to the discussion. If so, are you writing from a *free country*? Or: are you Ch1n3s3? (Accordingly to a *cliche'*, Chinese can't lose face.) No, to both questions. 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 * **
Re: Paid performance-tor option?
Roy, Free, no strings attached. Naturally I cannot disclose what specific organizations we work with, as that would be counter-intuitive to privacy protection. Here is one offer, currently, just take a look for yourself: http://xerobank.com/olympics.php We'll consider others on a case basis, but some general countries of ill repute suffice. If you were to ask me a hard number, I would say any country scoring above 40 on the Press Freedom Index. Steve Roy Lanek wrote: We offer free service for journalists in areas where there are significant restrictions on free speech and free press. And why should you offer free [I am guessing: free as in free beer] service for journalists--are you recruiting, looking for PR? Detail free speech and free press [who knows, maybe these are--here--intended differently than with free beer] please. In particular, make concrete examples of such areas. Better still!, sketch your list [top-down relative to restrictions on free speech and free press, most restricted on top]: 10 entries, say [but if you give more I would not say no]. /Roy Lanek
Re: Paid performance-tor option?
any country scoring above 40 on the Press Freedom Index. 8-) RWB [Reporters sans Frontieres], I was thinking that. Thank you. /Roy -- S buruk muka cermin dibelah S . s l a c k w a r e SS ugly face, the mirror is split [blaming S + linux SS the wrong cause or creating a scapegoat] S
Re: Paid performance-tor option?
On 2008-08-19 Scott Bennett wrote: On Tue, 19 Aug 2008 13:17:58 +0200 Ansgar Wiechers wrote: On 2008-08-19 Scott Bennett, persistently sending his mails without In-Reply-To- or References-headers, thus continually breaking threads for everyone else, complained: On Tue, 19 Aug 2008 15:49:50 +0700 Roy Lanek [EMAIL PROTECTED] again quoted me without attribution: Remove the beam from your own eye before trying to remove the splinter from someone else's. This I've discussed here before. Demanding the use of threaded mail readers is silly for a low-volume list and is not required in any case. As usual you're completely missing the point. Nobody's demanding the use of threaded MUAs, but a lot of people do use them, and threading is convenient even for low low-volume lists. Your persistent refusal to use a reasonable mail setup, which in turn leads to broken threads, makes things unnecessarily hard for everyone else for no apparent reason other than your reluctance to fix your mail setup. Beam and splinter. Stop making things hard for others yourself, then you can come again and complain. Regards Ansgar Wiechers -- The Mac OS X kernel should never panic because, when it does, it seriously inconveniences the user. --http://developer.apple.com/technotes/tn2004/tn2118.html
[OT] mail interfaces (was Re: Paid performance-tor option?)
On Tue, 19 Aug 2008 15:23:08 +0200 Ansgar Wiechers [EMAIL PROTECTED] wrote: On 2008-08-19 Scott Bennett wrote: On Tue, 19 Aug 2008 13:17:58 +0200 Ansgar Wiechers wrote: On 2008-08-19 Scott Bennett, persistently sending his mails without In-Reply-To- or References-headers, thus continually breaking threads for everyone else, complained: On Tue, 19 Aug 2008 15:49:50 +0700 Roy Lanek [EMAIL PROTECTED] again quoted me without attribution: Remove the beam from your own eye before trying to remove the splinter from someone else's. This I've discussed here before. Demanding the use of threaded mail readers is silly for a low-volume list and is not required in any case. As usual you're completely missing the point. Nobody's demanding the use of threaded MUAs, but a lot of people do use them, and threading is convenient even for low low-volume lists. Your persistent refusal to use a reasonable mail setup, which in turn leads to broken threads, makes things unnecessarily hard for everyone else for no apparent reason other than your reluctance to fix your mail setup. Beam and splinter. Stop making things hard for others yourself, then you can come again and complain. Like I wrote before, check the archives if it really concerns you so much. One more time, repeat after me: Scott Bennett is *not* the system administrator on this system and *cannot* install mail software onto it. It is not a matter of my refusing to accede to your unreasonable demands to do something I cannot do in order to pamper your lazy self. I have no trouble following the traffic on this list. Maybe you should try reading something easier if it gives you trouble. Stop worrying about headers, and start worrying about content. Now give it a rest, would you? This list is supposed to be about tor, for goodness's sake. 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 * **
Re: Paid performance-tor option?
A lot easier to sell to WHOM? (Let's say you are Novartis ... who are those which you are--implicitly or not, and slip of the tongue or not--mentioning as a destination for selling attested, proven sneak-oil ... a lot easier?) Management. When I approached the higher-ups about doing a TOR node, I needed to pick a repressive regime to use as the reason for doing it. I didn't think using our own country (equally repressive, for mostly the same reasons) would fly. It worked, btw .. we ran one @10mbps for almost a year, until folks started raping online academic journals with it. Michael Holstein Cleveland State University
Re: Hidden Service Performance GSoC Project Report
On Mon, 18 Aug 2008 19:30:25 +0200 Christian Wilms [EMAIL PROTECTED] wrote: I've written a a short project report about my Summer of Code project to improve the performance of hidden services. It can be found under http://www.ununoctium.de/gsoc08/gsoc_report.pdf The directory also includes related files. This looks like very helpful work. Do you know when to expect it to be incorporated into a future distribution of tor? Thanks for the good work! 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 * **
Re: Paid performance-tor option?
Ouch. Sorry to hear it. :-( Scott Bennett, Comm. ASMELG, CFIAG In-Reply-To: [EMAIL PROTECTED] To: Scott Bennett [EMAIL PROTECTED] Subject: Re: Paid performance-tor option? I really cannot parse the above bit of your writing. I may know better my 1st language, Italian, than you do English. Yet, the fact that I always have managed to read Italian written even by those who do no master it is hardly an explanation. [I also don't remember to have complained ever ... it doesn't take much more effort than some amount, figure.] Hence, I don't believe you. From the psychoanalysis, you also would not have started *argumenting* [your logic is horrible] with such objections. Try writing straightforward sentences without embedded asides. On the other hand, I can read English decently. Hence, I pretend to be able to recognize whether one writes ... bullshit--what you have done--or not. I invite you to stop your verbiage. Do you--rhetoric question [I am aware you don't]--know what you are implying when you utter Chinese dissident ... from a rogue, completely turned mad country such today's U.S. by surplus? From America #1 in the world for population living in the jail on its territory, and hundredth of thousands *outsourced*, jailed and tortured abroad on its behalf! Have you been *boiled* up like the classical bullfrog from the pan all these years for not having noticed it? It's grotesque. Yes, the U.S. is thoroughly screwed up, but that wasn't what I was saying. I was simply stating that what I was about to present was what a tor server operator in the U.S. has to consider. So you suggest a *radfahrernatur*^1 as the model? Oh? In August or September 2000? What event are you referring to? I am feeling embarrassed myself--for you; because this is really petty, in fact you have understood perfectly, of course. I have been tempted to add an erratum corrige. Then I have changed idea. (For the same reason I have added the *quasi-note* on my *English language* on the last post ... as a kind of a *probe*, because I wanted to see--and indeed I have: maybe I now have a better idea on who you are.) There are m banal explanations for the typo: done 2008 - 2001 mentally ... then just [mentally] picked the wrong digit, and typed ... eight instead seven. (Here, where I am replaying, there are *routine* blackouts daily since months: 4-6-10-12 hours a day; it makes one behave the *saccadic* and *incremental* way a bit.) I regard the readers as intelligent, and imagine that they can do by themselves the necessary corrections here and there. Good that you likely can't read French, or you would have *corrected* me when I have mistyped 'Reporters Sans Frontieres' in one of my recent replies. (I have written 'Reporter Sans Frontieres'--reporter without 's' for the plural--and, figure, I know French!) I make errors and type typos daily, I can live with that. The best professor I ever have had, on analysis, and a very good personal friend of Polya [it has always been highly interesting, and amusing, to listen some anecdotes on Polya once a while during the lessons], always warned us to please correct him as soon he wrote a *betise* [such, e.g., elementary arithmetic addition errors] at the blackboard. Mainly for not wasting too much time in hunting an error backwards, less for *proving* him that, say, 5 - 2 = 3 and not = 4. If you would stop ranting and raving long enough to make clear what's bothering you ... [etc.] Maybe verbiage is a reason why you are making it difficult to quote you. 9/11 has been planned much earlier than 2001. (If you can't understand, figure out why, then I can't help you much anyway.) One--one out of many--signs of it, is that the Internet--how it would have evolved--has FATALLY [read: LUCKILY for us ... 'us' the world] been under-evaluated, wrongly weighted and assessed in its development and potential by the 9/11 *architects*. 9/11 would possibly NOT have been unmasked as the inside job, the synthetic terrorism operation it has been, if there would not have been the Internet. Do you see the implications [cherries-like: Madrid, 7/7, ..., Georgia right now] of that? Moreover, similarly to the insane clique who sporadically came out from the bunkers of an encircled Berlin to still send the remaining boys from the Hitler-youth to their death, the deranged clique in Washington thinks to have a 2nd *chance*. (And a 3rd, after the 2nd.) With the difference that NOW the Internet has been BETTER assessed, and the expert [simulation] programs adapted accordingly. If you have managed to follow me till here [bizarre that I am somewhat thinking at *social engineering*!] then you can continue by yourself. I hope you understand better Tor's context now. Cheers, /Roy Lanek PS: as someone else from the mailing list has told to you already, please don't email me again privately--this is not a topic such firewalling, using a given editor or compiler
Re: Paid performance-tor option?
Management. When I ... [Roy: more garbage deleted] ... with it. Michael Holstein Cleveland State University Okay, thank you for the live *demo* [keep reading], and for having volunteered. Please put your regard here: Faulty Towers of Belief: Part II. Rebuilding the Road to Freedom of Reason Laurie A. Manwell, M.Sc. http://www.journalof911studies.com/volume/2007/ManwellFaultyTowersofBeliefPartII.pdf [Roy: HIGHLY RECOMMENDED READING ... the entire site, journalof911studies.com, contains highly recommended readings only] It begins like this: Anyone who has common-sense will remember that the bewilderments of the eyes are of two kinds, and arise from two causes, either from coming out of the light or from going into the light, which is true of the mind's eye, quite as much as of the bodily eye; and he who remembers this when he sees anyone whose vision is perplexed and weak, will not be too ready to laugh; he will first ask whether that soul of man has come out of the brighter life, and is unable to see because unaccustomed to the dark, or having turned from darkness to the day is dazzled by excess of light. And he will count the one happy in his condition and state of being, and he will pity the other; or, if he have a mind to laugh at the soul which comes from below into the light, there will be more reason in this than in the laugh which greets him who returns from above out of the light into the den. - Plato, The Republic1 It continues like that: Imagine for a moment that it is you who has just been asked to re-evaluate some of the most basic beliefs that you hold about the world around you. Again, if you are reading this, it is likely that you have already been asked to reconsider your beliefs about the events of 9/11 and your perception of the world thereafter. How did you respond? How did those around you interpret your responses? And most importantly, how can you use the insights yo've gained in order to pass along to others the same opportunity to re-examine some of the core beliefs about the events of 9/11? Similar questions have been asked long before September 11th 2001, by minds of greater depth and insight, yet we continue to be reminded of the necessity to ask them again and again -- to be vigilant and always question our beliefs - lest our beliefs enslave us to a reality that does not exist. Before we can ask others to re-examine their beliefs about the events of 9/11, we must do so first, we must lead the way by example. And we must do so through reason and with authenticity. ... It introduces Plato's Allegory of the Cave ... Timeless Lessons from Plato's Allegory of the Cave: The War Between Faulty Belief and Reality Briefly reviewing the research on attitudes presented in Part I, we see that the attitudes people already have can be automatically activated by mere reminders of the events of 9/11, and the longer and stronger these attitudes are held, the more resistant they are to change. One mechanism of attitude change is through the experience of cognitive dissonance, wherein tension arising from conflicting beliefs, feelings, and actions compels one to resolve the inconsistency. However, when people feel that they are under some form of attack, including strong challenges to their existing beliefs and worldview, they may also engage in various defensive mechanisms, often in an effort to reassert a perceived loss of control. ... It tells A brief synopsis shows Socrates giving Glaucon a description of human prisoners in a cave, who have been shackled since childhood and permitted only a very limited view of their surroundings, including various shadows cast on a wall, but never the men that cast them. Socrates then poses a series of questions to Glaucon regarding the nature of the prisoners'view of the world that is presented to them by their captors. Socrates points out that, for the prisoners, the truth would literally be nothing but the shadows of the images. However, if the prisoners were to be released from the cave, this truth would be challenged, and this challenge could be observed in the various responses of the newly liberated men. Socrates continues with the following pivotal question: Will he not fancy that the shadows which he formerly saw are truer than the objects which are now shown to him? However, liberation is much more a state of mind than body. Thus, as the former prisoners appear to be free to accept or reject it, their freedom is largely based upon their ability to integrate the new worldview with the old. Whereas some struggle to comprehend the meaning of two opposing worldviews, some simply cannot. And only a few can transcend both and truly be free in body and mind ... Etc. Read the 63 highly
Paid performance-tor option?
PERFORMANCE and freeness from big-bro-s influent area is a must for tor and for the world benefiting tor. JONDONYM, formerly JAP, have just established this. ( https://www.jondos.de/en/ ) If tor is incompetent to find HUGE funding for free, it may be time to setup an international tor paid option. Mac.
Re: Paid performance-tor option?
Since you've come to your own conclusions please go see Xerobank http://www.xerobank.com or one of those other services available. On Mon, Aug 18, 2008 at 11:20 AM, macintoshzoom [EMAIL PROTECTED]wrote: PERFORMANCE and freeness from big-bro-s influent area is a must for tor and for the world benefiting tor. JONDONYM, formerly JAP, have just established this. ( https://www.jondos.de/en/ ) If tor is incompetent to find HUGE funding for free, it may be time to setup an international tor paid option. Mac.
Re: Paid performance-tor option?
If tor is incompetent to find HUGE funding for free, it may be time to setup an international tor paid option. Many of TORs current high-bandwidth nodes are run by universities .. who would be legally prohibited from participating in a for-profit system (even if the model was just cost recovery). It's also a lot easier to sell the idea of exposing yourself to endless abuse complaints if you can use the ...but we're helping Chinese dissidents... angle. If you want paid-for anonymity services, there's tons to choose from .. but consider that once you attach payment to a username, you've created an easily attributable path back to you. TOR from the coffee shop's wifi is a lot harder to trace. I guess it depends on *why* you need the performance .. if it's p2p you're trying to do (which you shouldn't be doing on TOR anyway) I'd suggest you take a look at what the friendly pirates at PRQ have come up with (Relakks .. www.relakks.com). Cheers, Michael Holstein Cleveland State University
Re: Paid performance-tor option?
Thanks for your email. Dudes: Is this service really running, or it's a joke? How long are your running this? At what jurisdiction do you have set your servers and your corporation-s? Are you using the tor network? How do you compares with anonymizer.com? Do you allow fully untraceable anonymous payment systems? (just browsing a bit your site I just saw that you only accept credit/debit cards. If not a fully privacy issue for privacy rights activists or experts, as anyone can buy legal anonymous offshore debit cards, it's a bit an annoying task). You are emailing from an [EMAIL PROTECTED] Gmail account: Why not yet your own protected, firewalled and encrypted email server yet? .. It doesn't gives much confidence in your privacy knowledge. Anyway, if you are able to really improve free tor privacy/anonymity/security for global customers, my felicitations, and I would study your offer-s seriously in a near future, if not for my personal use, yes for my pseudonymously posted privacy/security blogs. Mac. If you do gpg mail (I couldn't find your pug pgp/gpg key at any pub keyserver), enclosed is my pub-key for non-post mailing if-when any. Rochester TOR Admin wrote: Since you've come to your own conclusions please go see Xerobank http://www.xerobank.com or one of those other services available. On Mon, Aug 18, 2008 at 11:20 AM, macintoshzoom [EMAIL PROTECTED]wrote: PERFORMANCE and freeness from big-bro-s influent area is a must for tor and for the world benefiting tor. JONDONYM, formerly JAP, have just established this. ( https://www.jondos.de/en/ ) If tor is incompetent to find HUGE funding for free, it may be time to setup an international tor paid option. Mac. -BEGIN PGP PUBLIC KEY BLOCK- mQGiBEhvd2gRBACoQplC2WIYkKhSmYbNIBFMne9RlSs6dns40C/wWAyntGp9RZa+ zNs3cC1K4/2nSiWq3Sff/8mTA65ieWwPAbfVHO1wF7KxSB1OgN4MAuIq0aD9A9hJ br3o0KbpmOIR2T0Rk5vGHXyLMDLnmO8m0JA7zWHkmutgjobfFs18syrqVwCg7D6N IExl1kypM7DBtetvg6dgzjsD/jLZyE3bcMLTFfp1RWE15yPUlH4pPNupK1Z4yTg7 z9IUSjC68hKNx7r/Qvd2T4F0wqUxZ+3z9HgLMVuvHQMMyjEOKt4qc+xhB2vl/ESd QLtg3bKzS9SWFt9kEqk534wf2UHl6Xv4/z/XQAwRNOE8yoUooHIt4kK7OQM9WTUi YXG/A/40+IbrjQZ3HIWD3rjM0NJWf147XB/EiGXRnt781AuBvSW8ZXDu0+TUHdVE tyj0PsTDtDfpF3uukDu1y//eA0eYL680Ke8jRrrs8fCGhuzJj9vs9xH5or8WwL92 4L+LC78dDi2Fei5RwJEi0w+TRt179LmcNSOFGaKFypbvRDK6k7RJbWFjaW50b3No em9vbTIgKG5ldyBrZXkgZnJvbSB2YWxpZCBqdWx5IDIwMDgpIDxtYWNpbnRvc2h6 b29tQGxhdmFiaXQuY29tPohgBBMRAgAgBQJIb3doAhsjBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQUWpddW9/YQdERACg2UA5nRQ2sKAadm18iL4i5so2OOUAoL9W 5/7L/XwFybY4kt7vm70WOb/guQQNBEhvd2gQEADWm9CdC65raxIOOpIDzq6VpDeK CQyQgfXYOMUN4/9cu7EQPq5pDkphyt3rGl+yvTXYu0gkF1GkUKkAlQfHkcruKstt lz/FJhatydg9ofw5M48t4jCG1HZWFCZD69cIVuz1JtJrMjCcTmC7SC7UH6iTqfUC IgP+tsw3mmgU2cw/EstBjwT2KpWZtLlTWYBnii34DG6bzeK9ZbZ98Qrwc+UHjP22 NnNoOY2DOKYkPsD9f8iK5ieAuvV/9T9rqeHdUBL28+JXddGyyW73Q990pO1NfeuM kVvC2U/ut8krll/mQFPGTgIPunpiPOKVRW0zT5p3K6klKBEYvvKp+qlUh5EDTPr3 Iaf1ERXIdc/XNlbhEKSyGBB1UwEAuiH9cdGnN0jwTHr3i5dzw+oVVSwsZk1ZrOAJ /LHmgpwVl+h4tNc5nvLteyrzPhmBbCqaDYzk7HP/4k2n5tBhH6qdF8vu2YD0owNR EDA4B8k8c7EtoKI5IJAUdsSHR99ok2jFpC65yD0w+CGFDn6/a+oH8mdS2b1LhtYW ibLMq2cQ3TrAwnkHQsWdB4xEeZtl/VWeriPrQ7lqGTK21BKnh2NmyErB4g7zqe0Z AI3yOJ5nmmiiom7gwwaBhA7Y+JIsKHP9FzpT0HkoFVff7310w4Lx4aPtZR9u1wLs QWTTVeNhvS4rLVODGwADBRAAkY2B7cOGZBmWVpxiOz3/v/01tICd/oiwEriIUARO LGTSBZlQiI36gWVX/DVbmjz8yEZUoeHB84z3XDuXC131R67OVXrJblGS5+tlUGhq b/IRlsU7ZVNjb9LuYFs8cKiBA8WVf9b57O+giazONqDJpayI+DeU4LVdVBWDKrWm cTnODzAOCi/gnlOTywyD5DPwL7zc8IjiRA4VzyeFC2hixvFlg0TrR0abLBluq2n3 grjbcWUSisVMepehANmNCQqi2IPpS0r+OAvIJa1BVw6neE88h52JPtpB8nC2LfdK juLWxqc2RSZ+uk6d7K2+K5j7w7YoELgamHRhxAbsjfVDcSlEfxx6hafIUhBviSso ZgoBC7BiDlRQPS+U7GNYHggxyPjcwI7b7I7zW4ml05jd7KEO8BPRVkU+VEJtNEH8 22mT4Jn2UzJHUwHefyIplchY+XXVMzl+aSIUYcf2QRhOmIoR2Xc1xbWuQ7Swfdxu swh3BfBPjZ2JyN7laQUK372qSzZ6FK9DCSdIulBk0sv2sHpR7R8GVkpqQERWeufR LnkylzA85bJfpihOOsxmS9HlkiDJSONkLTDIbGhGxkNb3DP87DTNKfJS4D9Q6G4H DsaZOhm+fCs9LAbkPTNMnstz3p0PODwwx9q8OADhYiUD/qnQRPTBljJ+43NlbQZ8 G4eISQQYEQIACQUCSG93aAIbDAAKCRBRal11b39hB2UZAJ9CwzFKry+LKJALWzEl T11T9LgwIACgp4mrGRDzYjj23QlgW68O6xo9Jns= =ClCW -END PGP PUBLIC KEY BLOCK-
Re: Paid performance-tor option?
Mac, For high bandwidth in addition to low latency, you are correct that commercial anonymity is the only option. However there are a lot of issues with commercial anonymity, and anonymity that is not purely P2P designed. These issues can result in worse privacy if you don't pay attention to the circumstances of your provider. Beyond that, many of them have high political risk, and high legal risk so they are not analogous to Tor, which is distributed and decentralized, barring authoritative directory servers. Political risk refers to the possibility of integrity being compromised due the actions of the country or countries in which the network operates in. A data retention law, for example, would severely hamper efforts in anonymity. That means providers like relakks, swissvpn, etc turn into a honeypot. This also applies to JonDos, as the operators are located in Germany and the EU, which has a data retention directive in addition to being a plethora of surveillance societies. To battle this, all of your traffic must be end-to-end encrypted, but can still be subject to traffic analysis for context. JonDos however is a slightly different beast. This is because they operate a mixed-trust model. You are trusting the operators not to do exit node injection, and it also requires rerouting through three entities because they do not trust each other. In that way it is similar to tor. Other commercial networks, that are single entity, typically have one-hop or two-hop proxies because they are not disguising origination from themselves, as that isn't in their threat model. Centralized one-hop proxies should always be avoided for non-trivial communications or integrity. The known multi-hop proxies are ironkey, jondos, xerobank, and cryptohippie. Legal risk deals with centralization of the operation/operators. These corporations are governed in surveillance societies, or low-privacy areas, and are instantly compromised if a record is requested by any agency of authority. Examples of services with high legal risk are findnot, anonymizer, ironkey, and cotse. To attain similar anonymity as tor, with a single trust domain such as a corporation, they would have to be distributed in server location, and decentralized in operations. This narrows your choices down to just two choices that I know of: xerobank as mentioned by rochester and cryptohippie. Both are incorporated in low risk areas, and have multi-jurisdictional networks. There are many providers, all with different levels of integrity and competence, which should be considered by the user. These come into play with items like the privacy policy, logging, source availability of software being used, etc. Other issues are what type of protocol they use. Beware of L2TP alone, as it does not have encryption, and thus content is exposed, and only context is obscured. Beware of PPTP, as it is known to leak DNS. On the relakks network it leaks 100% the last time I checked. SSH is good, but make sure you are piping your traffic through it. OpenVPN is a good choice, and so is IPSec, but again you'll need a good implementation to prevent leaks, which is often OS dependent. The bottom line is that providers aren't the same, and anonymity has no metric of measurement for easy comparison, yet. It's all apples to oranges. Consider what your needs are, who your potential adversary is, and do your homework before you buy or demo anything. If you don't, in many cases, you may as well be CCing your traffic directly to echelon, as many of the providers are being monitored or are known to proactively provide logs to law enforcement. Steve Rochester TOR Admin wrote: Since you've come to your own conclusions please go see Xerobank http://www.xerobank.com or one of those other services available. On Mon, Aug 18, 2008 at 11:20 AM, macintoshzoom [EMAIL PROTECTED]wrote: PERFORMANCE and freeness from big-bro-s influent area is a must for tor and for the world benefiting tor. JONDONYM, formerly JAP, have just established this. ( https://www.jondos.de/en/ ) If tor is incompetent to find HUGE funding for free, it may be time to setup an international tor paid option. Mac.
Re: Paid performance-tor option?
On Mon, 18 Aug 2008 12:44:44 -0600 macintoshzoom [EMAIL PROTECTED] wrote: Thank you for your post. Michael Holstein wrote: [much text deleted --SB] TOR from the coffee shop's wifi is a lot harder to trace. Probably most if not all coffe shop's wifi are at this time under strict orwellian surveillance. And most of their servers and firewalls are for People connect to the coffee shops' wireless access points anonymously in many cases and are given private IP addresses via DHCP. Granted, some coffee shops do have security cameras that *might* make it possible to figure out which person's computer got which IP address by noting DHCP server logs and viewing the tapes after the fact. To do so would be so expensive that it would only be done in cases where someone specific were already being surveilled. sure poorly setup. I'm not sure that communicating via tor from any of those wifi could be safe globally regarding anonymity/privacy/security, mostly if the coffee shop wifis are located at your adversary country. But even if they knew which person got the IP address that opened connections to tor servers, they still wouldn't know what that traffic contained. If the adversary agency were that serious about it, it would simply do a black bag job and be done with it. [much political dogma deleted --SB] I am tired of tor gurus aiming to forbidden P2P. Really. Hiphocresy. I will research some day on this list archives about this matter to publish the results on a blog, and to open a new tor+p2p thread that can be beautifully hot. So open the port on your exit server. There's no technical reason that you can't. Most people don't do that because a) it can also open the operator to endless legal hassles from powerful entities like RIAA, law enforcement agencies, etc. and b) the P2P bandwidth in use over the open Internet might well swamp the limited tor network bandwidth, thereby rendering tor useless for everyone else. Tor must be prepared for the revolutionary P2P technology, anything else is stupid, retarded minded, coward. Nice attitude toward those who simply want to stay out of jail, not have their computers and homes taken from them, etc. Must be nice to have all the power from which you appear to speak to defend yourself. Keep in mind that universities typically block known P2P ports on the open net, anyway, for both legal and bandwidth reasons. If their administrations believed that a significant fraction of tor's bandwidth were being used for P2P stuff, some of them might order their tor servers be shut down. Just out of curiousity, how much bandwidth are you currently donating to the tor network? Given that most people don't change routelen from 3 to a larger value, would 1/3 of the bandwidth that you contribute be enough to cover your P2P needs? 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 * **
Re: Paid performance-tor option?
As per privacyinternational.org (link below), Germany, once a top privacy rights bastion country, is deceiving progressively. Top privacy rights bastion country?! ... Yes?!, once when? On the other hand, and focusing on an other topic slightly, though on the bastion theme still: Swiss banks' secrecy has been zeroed TRULY--the only concealing effective today is for Swiss citizen [me for example] WITHIN the national territory. (And to maintain that last thing, they--the Swiss as the captain of the Titanic--are also going to vote too ... soon. 30 seconds of silence/pray please.) Back to Internet privacy, France should be the worst [in the strict sense] in Europe ... I am correct? /Roy Lanek -- S keluar mulut harimau, masuk mulut S . s l a c k w a r e SS buaya--out from the tiger's mouth, S + linux SS into the crocodile's mouth S
Re: Paid performance-tor option?
It seems that they are knees-down to german law-enforcement, opening their nodes servers to them when required (?), probably even without required nor informative request, as they seem to have set up a backdoor system for law-enforcement. Thinking in advance at the Argentina-Brazil [football] game. And at the off-side^1 [-forcing] trick the teams use at times ... [For those who do not love football--is it possible?!-- :) and ignore everything of the game, see the note below] Law-enforcement is GOOD and VITAL. It's madness in general to try to sneak it. BAD is when law-enforcement is done abusively and inappropriately [e.g., when governments and administrations do not represents a majority of the populations]. This--arbitrary law-enforcement--is a problem, and a very serious one. It goes beyond Tor, and rightly so. Plus, we don't want to let Tor become an out of the laws [re-read the Argentina-Brazil example of above]. What Tor can do, is to try to make arbitrary law-enforcement hard to implement, within legality of course. /Roy Lanek 1. Off Side -- A player is in an off side position if he is nearer to his opponents goal line than the ball, unless there are at least two of his opponents nearer their own goal line than he is. A player is only declared off side and penalized for being in an off side position. [Roy, and here comes the important part:] If a player is declared off side, the referee awards an indirect free kick, which is taken by a player of the opposing team from the place where the infringement occurred. [Roy: actually--but without loss of generality--the rules have changed slightly meanwhile] Ref.: [first entry picked up after a google search] http://www.webindia123.com/sports/football/rules.htm -- S dimana tak da lang, aku lah lang, kata S . s l a c k w a r e SS belalang--where there are no eagles, I am S + linux SS the one, said the grasshopper [where's no S top dogs, underdogs will be seen as one]
Re: Paid performance-tor option?
We offer free service for journalists in areas where there are significant restrictions on free speech and free press. And why should you offer free [I am guessing: free as in free beer] service for journalists--are you recruiting, looking for PR? Detail free speech and free press [who knows, maybe these are--here--intended differently than with free beer] please. In particular, make concrete examples of such areas. Better still!, sketch your list [top-down relative to restrictions on free speech and free press, most restricted on top]: 10 entries, say [but if you give more I would not say no]. /Roy Lanek -- S bread sama dipikul, ringan sama dijinjing S . s l a c k w a r e SS heavy we shoulder together, light S + linux SSwe hand-carry together S
Re: Paid performance-tor option?
Why, to the administration at the university (or the bosses at the company) one works for or to one's ISP, of course. Perhaps also to a judge. Wasn't that obvious? No, it was not obvious. And it STILL is not. Besides, what are you trying to say, that one--example--as a soldier [I have been in the army], or, more in general, as a pawn needs to let go a slap on the butt of the waitress bringing food or a drink at a restaurant so to become accepted by his bosses and the others? If so, are you writing from a *free country*? Or: are you Ch1n3s3? (Accordingly to a *cliche'*, Chinese can't lose face.) /Roy Lanek -- S gajah bertarung lawan gajah, S . s l a c k w a r e SS pelanduk mati di tengah-tengah S + linux SS elephants wage war against elephants, S deers die in the midst
worsening performance
Hi, almost exactly 48 hours ago traffic on my node changed from rather smooth performance into 'saw blade'. (see attachment) The time shown is gmt -2 (germany). Tor is continuing to fail to perform the way it did before. At the time this is sent, a few hours later, there is no change. This is Tor v0.2.0.6-alpha configured as a directory mirror and middleman. Not a very powerful one, but it does it's job. Apparently, as I changed neither the configuration of the node nor the machine, the reason for this must be somewhere else. Ideas what was happening? What could I possibly do to regain former performance? regards Hans attachment: perf7d.jpg
Re: worsening performance
Original Message From: Hans S. [EMAIL PROTECTED] Apparently from: [EMAIL PROTECTED] To: or-talk@freehaven.net Subject: worsening performance Date: Mon, 17 Sep 2007 08:51:32 -0400 hi The time shown is gmt - -2 (germany) - is incorrect, of course it must read gmt + 2. ( - 2 should be somewhere in the atlantic, I suppose ) my apologies. Hans Hi, almost exactly 48 hours ago traffic on my node changed from rather smooth performance into 'saw blade'. (see attachment) The time shown is gmt -2 (germany). Tor is continuing to fail to perform the way it did before. At the time this is sent, a few hours later, there is no change. This is Tor v0.2.0.6-alpha configured as a directory mirror and middleman. Not a very powerful one, but it does it's job. Apparently, as I changed neither the configuration of the node nor the machine, the reason for this must be somewhere else. Ideas what was happening? What could I possibly do to regain former performance? regards Hans
Re: worsening performance
this is emberassing, but time, space, speedy fingers and a slow brain seem to be in dissonance today correction #2: The time shown is gmt -2 (germany). of course it must read gmt + 2 is meant as: he time shown is gmt +1 (germany). again my apologies. The initial problem though still persists. regards Hans Original Message From: Hans S. [EMAIL PROTECTED] Apparently from: [EMAIL PROTECTED] To: or-talk@freehaven.net Subject: Re: worsening performance Date: Mon, 17 Sep 2007 09:40:56 -0400 Original Message From: Hans S. [EMAIL PROTECTED] Apparently from: [EMAIL PROTECTED] To: or-talk@freehaven.net Subject: worsening performance Date: Mon, 17 Sep 2007 08:51:32 -0400 hi The time shown is gmt - -2 (germany) - is incorrect, of course it must read gmt + 2. ( - 2 should be somewhere in the atlantic, I suppose ) my apologies. Hans Hi, almost exactly 48 hours ago traffic on my node changed from rather smooth performance into 'saw blade'. (see attachment) The time shown is gmt -2 (germany). Tor is continuing to fail to perform the way it did before. At the time this is sent, a few hours later, there is no change. This is Tor v0.2.0.6-alpha configured as a directory mirror and middleman. Not a very powerful one, but it does it's job. Apparently, as I changed neither the configuration of the node nor the machine, the reason for this must be somewhere else. Ideas what was happening? What could I possibly do to regain former performance? regards Hans
Re: worsening performance
I want just to help you out on the time zone thing: Summer: UTC/GMT +2 (as we have daylight saving time) Winter: UTC/GMT +1 Currently GMT+2, my linux box says! ;-) The sawtooth thing is reported often in the past. It is coupled with the fact not beeing listed at the authority directories and therefore not attracting node traffic anymore. Can you verify this? It seems to be still an issue.. Greets Am Montag, den 17.09.2007, 09:52 -0400 schrieb Hans S.: this is emberassing, but time, space, speedy fingers and a slow brain seem to be in dissonance today correction #2: The time shown is gmt -2 (germany). of course it must read gmt + 2 is meant as: he time shown is gmt +1 (germany). again my apologies. [...] -- BlueStar88 [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: worsening performance
hi, time is a tricky thing... thank you for helping out with all the time mess ;) The problem obviously still persists. I checked the files in tordb. cached-routers.new: 1 entry with the correct IP cached-status/* : 5 files with 1 correct entry per file but in: cached-routers: 6 different entries with $mynode with 5 different IP's, only the last one correct as of now. This is a dial-up line, with the common change of IP's every 24 hours, sometimes even shorter than that, if the line collapses. The machine reconnects immediately after each , Tor SIGHUP's with the renewed IP, and this actually worked fine. Especially with v0.2.0.6-alpha the *full* connectivity was given again after about two or three hours after publishing the renewed address. The old IP's from about the last 5 redials showing up in cached-routers certainly shouldn't be there anymore. The first idea was to renew cached-routers completely, but that will not solve the problem as the renewed file will be in the same state. Regards Hans
Re: worsening performance
Hans S. wrote: but in: cached-routers: 6 different entries with $mynode with 5 different IP's, only the last one correct as of now. a fixed IP address doesn't change anything regarding this traffic behavior. Attached you'll find my saw blade like looking traffic graph (or sawtooth? what's the correct term in English?). The IP address never changed within months. regards, Olaf from Germany GMT+2 - not from Greenland GMT-2 :-) inline: anonymizer.blutmagie.de_2-week.png signature.asc Description: OpenPGP digital signature
Re: worsening performance
Hi, a fixed IP address doesn't change anything regarding this traffic behavior. Good to know, I was hoping so. But still I wonder why rather smoothly running traffic drops with such a sharp cut, there must be a reason for that. Certainly, on the larger scale, this behavior reduces overall performance in the Tor network quite significantly. During the last 90 minutes though, traffic on my node shows again more normal patterns. If this is due to the time of day (don't ask, but it is evening here) or someone with the right time has flushed the right cache, I do not know. Regards Hans
On the performance scalability of Tor
A frequently stated problem with Tor is the poor performance and improving this is the goal of several sub-projects. One of these is to simply encourage the deployment of more Tor servers. This will increase the capacity of the network, but the consequent improvement to users is more difficult to estimate. The intuitive hypothesis -- that a n% increase in network capacity will result in an n% increase in performance for users -- is almost certainly wrong. In fact, the defining factor is how the number of users scales with the available bandwidth -- a currently unknown function. I discuss this way of looking at Tor as well as the consequences and limitations of the approach in a blog post published today: http://www.lightbluetouchpaper.org/2007/07/18/economics-of-tor-performance/ As always, comments and suggestions, either here on the list or on the blog, are appreciated. Steven. -- w: http://www.cl.cam.ac.uk/users/sjm217/ pgpCAOggd7IUN.pgp Description: PGP signature
Re: On the performance scalability of Tor
On Wed, Jul 18, 2007 at 07:52:14PM -0700, Mike Perry wrote: Thus spake Mike Perry ([EMAIL PROTECTED]): RELAY_EXTEND is the way this is done. I believe clients can and do send multiple RELAY_EXTENDs in a row, so it's not like its a Sorry, I'm a moron. I meant to say RELAY_BEGIN. Also, Roger/Nick, please correct me if these can't be issued concurrently. They can be issued concurrently. Tor doesn't care. Also, with HTTP/1.1 pipelining to the actual website, we just need to open a single TCP stream (one RELAY_BEGIN) and we can then fetch many pages in a row. I'm not sure if this is better or worse than fetching them in parallel. I suspect Juliusz (the polipo developer) has opinions :), and I'll defer to him. --Roger
Re: On the performance scalability of Tor
Thus spake Roger Dingledine ([EMAIL PROTECTED]): On Wed, Jul 18, 2007 at 07:52:14PM -0700, Mike Perry wrote: Thus spake Mike Perry ([EMAIL PROTECTED]): RELAY_EXTEND is the way this is done. I believe clients can and do send multiple RELAY_EXTENDs in a row, so it's not like its a Sorry, I'm a moron. I meant to say RELAY_BEGIN. Also, Roger/Nick, please correct me if these can't be issued concurrently. They can be issued concurrently. Tor doesn't care. Also, with HTTP/1.1 pipelining to the actual website, we just need to open a single TCP stream (one RELAY_BEGIN) and we can then fetch many pages in a row. I'm not sure if this is better or worse than fetching them in parallel. I suspect Juliusz (the polipo developer) has opinions :), and I'll defer to him. Yeah, cause it's not like optimizing high latency networks and chatty protocols for speed is my day job or anything. Probably should wait for the expert to weigh in to really be sure ;) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgphk8XMyUpdv.pgp Description: PGP signature
Re: On the performance scalability of Tor
They can be issued concurrently. Tor doesn't care. Indeed; I will see vidalia show a lot of connectings all at once, followed by all switching to open at once (TCP streams inside a tor circuit). The overhead to open a new TCP HTTP connection through a tor circuit seems to be very long. I know it has to be encrypted/decrypted at each node, as well as originated at the exit to the destination, but I have to wonder: Can this be sped up at all? The discussion about fast nodes: Is there a way to tell the client, Only select fast nodes? Does fast imply high throughput (but it might be slow to start up), or fast startup/turn around?
Why batching and reordering is bad for TCP performance in mixes
Dear All, I put a technical report on why batching and reordering is bad for mixes at http://www.homepages.dsu.edu/fux/paper/mixPerf_fu07.pdf. Just for fun. Cheers, Xinwen Fu
