Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. the old blutmagie exit running in 2007-2009 which serves my tns pages is equipped with two Xeon cpus from the old P4 Prestonia architecture. The exit node anonymizer2.blutmagie.de has one c2d E8600 cpu. Cause tor process basically spends all cpu time within one thread, a slower clocked quad/multicore wouldn't speed up anything. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Tue, 13 Apr 2010 08:43:21 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. the old blutmagie exit running in 2007-2009 which serves my tns pages is equipped with two Xeon cpus from the old P4 Prestonia architecture. The exit node anonymizer2.blutmagie.de has one c2d E8600 cpu. Cause tor process basically spends all cpu time within one thread, a slower clocked quad/multicore wouldn't speed up anything. Either I forgot (probable) or you didn't mention before (less probable) that you had moved it to a newer machine. Whatever you're running it on, superpages or LINUX's huge pages ought to speed tor up considerably by drastically reducing TLB misses. (I wasn't suggesting that you revert to older hardware. I was thinking that you were still running tor on the Xeon- based machine.) 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/
Re: [or-talk] where are the exit nodes gone?
Kasimir Gabert wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. fyi bandwidth bar for torstatus.blutmagie.de now calculates according Kasimir's new code evaluating the more realistic daily average from extra-info instead of the observed peak bandwidth. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 08:47:31 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. 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/
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without knowing about the total provided bandwidth. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. Sorry to disappoint you, Olaf, but that's just the way things are for now. :-( FWIW, I still think it might be worth your time to take a spare machine, if you have one, and install an OS that supports superpages (e.g., FreeBSD 7.2 and later, Windows Vista and later, possibly Windows Server 2008, but I don't know about that one), and then try it long enough to see whether that relieves any of the CPU load. Or, if you're up for some coding and testing, you could try LINUX's support for huge pages, but that facility is neither automatic nor transparent to the application, as I understand it, so it does require additional code. At present, it's very likely that 30% to 45% of your tor relay's CPU time is being wasted in address translation due to TLB misses, even when the needed data or instructions are *already in some level of cache*. If the CPU is stalled because MMU has to walk a page table before it can discover that what it needs is not only already in memory, but already in a cache, the performance hit is a crying shame. 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/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 06:12:43 -0500 (CDT) I wrote: Hi Olaf, On Sun, 11 Apr 2010 12:11:36 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic You did say observed, not advertised. purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value Remember, there are exactly two vantage points from which valid observations can be made, no more and no less. One is from inside your system's networking stack (including packet filter software). The other is inside your tor relay's process. Unless the value of about 16000 KB (/s) comes from one of those two sources, then I simply don't believe the so-called measurement, and neither should you. Such a measurement means, at best, only that it's probably a relatively big number when compared to the rest of such numbers in the consensus, and the real number is almost certainly larger than this number. is killing the cpu with the number of new conns/s. I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) In any case, if a consensus document volunteers any capacity exceeding the smallest of a node's BandwidthRate, RelayBandwidthRate, or MaxAdvertisedBandwidth, then I believe it should be documented and reported as a bug in the authority code. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without No, not at the present time because that is not reported by the relays. What a relay reports is the highest minimum number of bytes handled in any one second in a ten-second sliding window within the the past 24 hours. That value is then devalued considerably by the fact that the 24-hour periods are not normally consecutive, but rather are overlapped by roughly six hours at each end, so that only the middle twelve of the 24 hours are represented exclusively in a measurement reporting period. The whole reporting setup is wrong and needs to be revamped from scratch in order to get a system that works properly. As I've noted before, the very first and most critical thing to be done is the design separation of throughput capacity (which the clients need to know) from actual service rendered (which only some humans want to know). The rest cannot even be begun until that much is done. knowing about the total provided bandwidth. Probably the best data (i.e., not as bad as any of the other values reported) for that purpose would be found in the extra-info documents. Divide each field by 900 s to get the average rates in B/s. One good thing about the numbers in the extra-info documents is that both bytes read and bytes written are reported. The other things I missed in Olaf's remarks above are *exit* usage and *exit* capacity. If tor ever get proper reporting of throughput capacity, then adding up the capacities of all exit nodes in the consensus or, arguably, the current directory, would yield the total exit capacity because it matters not whether data leave a node for a true destination or just to another node. But the total exit usage question cannot be answered at present because nothing reports that information at present. Whether tor is keeping such information locally but not reporting it either locally or to some authority, I don't know. If it is, then adding a few lines to write the information to a log every so often should be fairly trivial to do. 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
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I'm certainly not going to migrate my tor node to Windows. Never ever! ;-) regards Olaf inline: anonymizer2.blutmagie.de_2-day.png
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. Oh, jeez. I thought that one had been fixed a while back. Sigh. Or maybe it's not just *one* bug. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I don't see how because a successful translation stays in the hardware and causes no interrupt. The kernel only sees something when the translation fails. FreeBSD has had steadily growing HWPMC support since 6.0, so I just looked through some of the HWPMC man pages. There are counters for instruction cache misses and data cache misses, but I didn't see any counters at all that involved TLB-related events. That doesn't mean that there aren't any, just that I didn't find any documentation of any. On a moment's thought, that does seem a trifle odd, given that there are counters for lots of strange things, including other performance hits that have far milder consequences per event (e.g., logical CPU cycle lockouts caused by conflict with the other logical CPU in a core, IIRC) than TLB misses have. If I had the Intel processor manuals that describe the various counters that the chips support, I'd have a better clue where to look in the FreeBSD documentation or maybe how to query the hardware itself (using a small utility that is part of the base system) to find out whether there are any TLB-related event counters available. You might dig around in your system to see whether LINUX shows support for any TLB-related event counters. Something else you might check on if you're considering adding scraps of code to tor to use LINUX's huge page support is whether huge pages get page-fixed (a.k.a. wired). FreeBSD's superpages don't. If the kernel decides it has to snatch any base page frames out of a superpage, it simply demotes a superpage to the next smaller page size supported on that processor type, then demotes one of those, etc. until it can free up individual base pages. That means it can't cause the sort of problem that tying up several hundred megabytes of page frames by fixing a large process's pages into them can create for the rest of whatever is running in the same machine because a superpage's base (i.e., underlying, smallest sized) page frames can always be freed for reuse by something else if the system really needs them. On i386 and amd64 architectures, there are only two page sizes (4 KB and 4 MB) available anyway, so there's only one step available in either the promotion direction or the demotion direction. (ia64 (i.e., Itanium) has a several more steps available, IIRC, and I think the alpha processors have about five.) In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. I'm not sure about Xeons, but the regular, non-server i386 and amd64 chips by Intel only have 64 TLB entries for instruction (i.e., text) pages and 64 TLB entries for data (i.e., data and stack) pages, so that means if an instruction working set or a data working set exceeds 256 KB, then the process running with base (4 KB) pages will end up thrashing the relevant TLB(s), stalling the processor every time while the MMU walks through the page table. If you have HTT-enabled Xeons, then remember that the two logical CPUs in each core share the same MMU and L1 and L2 caches, as well as the same bus to and from main memory, which can further
Tor-network-status wishlist (was Re: [or-talk] where are the exit nodes gone?)
On Sun, Apr 11, 2010 at 03:23:16PM +0200, Olaf Selke wrote: maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Here's my chance to remind people about http://archives.seul.org/or/talk/Jan-2008/msg00300.html :) I think #1 and #4 have been done, but #2 and #3 remain. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, Apr 11, 2010 at 10:05 AM, Kasimir Gabert kasimi...@gmail.com wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Thanks, Kasimir -- Kasimir Gabert Hello again, I believe you're bandwidth is being calculated to be 14523 KB/s -- impressive! http://trunk.torstatus.kgprog.com/index.php?SR=BandwidthSO=Desc Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor-network-status wishlist (was Re: [or-talk] where are the exit nodes gone?)
On Sun, Apr 11, 2010 at 10:04 AM, Roger Dingledine a...@mit.edu wrote: On Sun, Apr 11, 2010 at 03:23:16PM +0200, Olaf Selke wrote: maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Here's my chance to remind people about http://archives.seul.org/or/talk/Jan-2008/msg00300.html :) I think #1 and #4 have been done, but #2 and #3 remain. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ Hi Roger, #2 and #3 are implemented in the current trunk version. #1, however, is only partially implemented. Thanks, Kasimir -- Kasimir Gabert *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sun, 11 Apr 2010 10:05:06 -0600 Kasimir Gabert kasimi...@gmail.com wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: =A0 =A0 On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmag= ie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. =A0 =A0 You might communicate with Kasimir Gabert about that. =A0I think = he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. Thanks for responding to that so quickly, Kasimir. It should save Olaf some time. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. I'm giving myself two weeks at the end of this semester to get a new interface that was designed for me implemented, redo the PHP frontend code base, and push out a new version. :) You can get the actual bandwidth code already, however. I used a moving average to calculate it. Did you just use a boxcar average? If so, it will have significant (I'd guess a peak of about 2% of true amplitude) Gibbs ringing in the result, but given the erratic quality of the source data (i.e., the mix of varying lengths of records, times of day, and so forth) and given how the results will be used, it's probably no big deal, and no one is likely to realize the ringing is present when they look at a graph of it anyway. How many 15-minute periods wide is the window? 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/
Re: [or-talk] where are the exit nodes gone?
On Tue, 6 Apr 2010 at 21:01, Olaf Selke wrote: on my exit node blutmagie The fastest Tor node out there, kudos! the ratio of real bandwidth divided by advertised bandwidth has increased within the last three month by a factor of three. The MaxAdvertisedBandwidth 2000 KB config parameter leads to 135 MBit/s real bandwidth. Well known TNS sites like http://torstatus.kgprog.com sorted by bandwidth lists only two exit nodes within the top twenty. Hm, we do not seem to monitor exit nodes over time (or do we?). Looking at the tor.eff.org frontpage however there's an ad suggesting that we were at 1755 exit nodes at one point. The current TNS sites count only 584 exit nodes, a factor of three indeed :-\ Might this just be caused by some Tor code change leading to the TNS sites being unable to reliably determine if it's an exit node or not? Christian. -- BOFH excuse #85: Windows 95 undocumented feature *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Fri, Apr 09, 2010 at 08:58:32PM -0700, Christian Kujau wrote: the ratio of real bandwidth divided by advertised bandwidth has increased within the last three month by a factor of three. The MaxAdvertisedBandwidth 2000 KB config parameter leads to 135 MBit/s real bandwidth. Well known TNS sites like http://torstatus.kgprog.com sorted by bandwidth lists only two exit nodes within the top twenty. Hm, we do not seem to monitor exit nodes over time (or do we?). Looking at the tor.eff.org frontpage however there's an ad suggesting that we were at 1755 exit nodes at one point. The current TNS sites count only 584 exit nodes, a factor of three indeed :-\ No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all Also, we moved from tor.eff.org to torproject.org several years ago. :) --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
On Sat, 10 Apr 2010 at 00:08, Roger Dingledine wrote: You might like http://metrics.torproject.org/consensus-graphs.html#exit-all Thanks for the link! Also, we moved from tor.eff.org to torproject.org several years ago. :) Yeah, I know. But the old URL is so much shorter! :-) Christian. -- BOFH excuse #173: Recursive traversal of loopback mount points *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
