Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Apr 15, 2010, at 8:17 AM, Scott Bennett wrote: Unfortunate (IMO), the latest versions have the support for .exit either disabled or deleted, apparently leaving us no easy way to perform such tests. I've asked recently on this list whether some other easy way were available, but have been met with silence, so I assume that there still is none. If you want the functionality, feel free to set the AllowDotExit config option to 1. Note that this can't be recommended, because it opens you up for attacks where the exit node can choose who your exit is going to be, unless you use encrypted protocols when webbrowsing only. # This file was generated by Tor; if youedit it, comments will not be pres= I think the comment may be a lie. It's most likely a torrc produced by vidalia, not tor. (Someone please correct me if I've forgotten some special case in which tor does rewrite a torrc.) I think it is more likely that the file was written by Tor, via the SAFECONF torctl command. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Wed, 14 Apr 2010 21:14:49 -0400 zzzjethro...@email2me.net wrote: >Thanks. This brings up a couple of questions. One, The Onion Router.doc re= >commends against choosing one's exit nodes. Is your recommendation I exclu= >de these naughty exit nodes, that are determined as such by Tor authoritie= >s? You may have missed a distinction there. ExcludeExitNodes does not choose your exit nodes, but rather tells your client which nodes *not* to use. > >The .doc (Section 4.9--Can I control what nodes I use for entry/exit?), sa= >ys,=20 >"We don't actually recommend you use these for normal use--you get the bes= >t security that Tor can provide when you leave the route selection to Tor.= >" If you agree, why do you do this? I am assuming that is part of what you= >r post implied or meant, i.e. that you do this in spite of Tor's recommend= >ation. There are two cases here to discuss. The first is when one is testing a particular exit that one suspects may be corrupted or dysfunctional in some other way that you find unacceptable. Until the most recent versions of tor, one could perform such a test by choosing the exit with the .exit notation in a host+domainname (e.g., some.website.com.privacynow.exit), which tells the client to build a circuit that uses PrivacyNow as the exit node. Unfortunate (IMO), the latest versions have the support for .exit either disabled or deleted, apparently leaving us no easy way to perform such tests. I've asked recently on this list whether some other easy way were available, but have been met with silence, so I assume that there still is none. The second case is when a malfunctioning exit has been affirmatively identified. In such a case, one should post a message either here or on tor-rel...@torproject.org to notify all subscribers to the selected list. The directory authority operators read these lists, and if they are in agreement about your complaint, they will assign a BadExit flag to the offending node. While you and others wait for them to notice your message and decide what, if anything, to do about it, you and others need a way to enforce exclusion of that node from the circuit route selection process for use as an exit node. The ExcludeExitNodes statements in torrc are used to accomplish that exclusion. Also, sometimes the authority operators may disagree with your evaluation of a particular case and therefore refuse to flag the exit node with a BadExit flag in the directory. You can still force your own client to abide by your evaluation and decision through use of the ExcludeExitNodes statement in torrc. W.r.t. the documentation you cite, it is worth noting that being far more reluctant to exclude misbehaving nodes from use as exits was a bigger issue in the days when the tor network only had, say, 200 or fewer exits running at any one time. Now that there are usually 400 - 700 exits running at any given time, there isn't much anonymity to be preserved by allowing the use of such exits, and there may be much to be lost, depending upon the situation. I've accumulated a fairly lengthy list of excluded exits, but I do go through it every year or two to see which excluded exit nodes a) are still around and running and b) have corrected whatever I had found objectionable, as well as c) which are no longer around and can be eliminated from the list anyway. When I find nodes that are no longer a problem, I remove them from my exclusions. > >Two, in my Home Folder/Library, I have two (2), torrc files. one is torrc,= > the other is torrc.orig.1 > >The first one (torrc), has: > ># This file was generated by Tor; if youedit it, comments will not be pres= I think the comment may be a lie. It's most likely a torrc produced by vidalia, not tor. (Someone please correct me if I've forgotten some special case in which tor does rewrite a torrc.) >erved ># The old torrc file was renamed totorrc.orig.1 or similar, and Tor will= > ignore it > # If set, Tor will accept connectionsfrom the same machine (localhost onl= >y) ># on this port, and allow thoseconnections to control the Tor process usin= >g ># the Tor Control Protocol (described incontrol-spec.txt). >ControlPort 9051 ># Store working data, state, keys, andcaches here. >DataDirectory /Users/zZ/.tor/ ># Where to send logging messages. Format is minSeverity[-maxSeverity] ># (stderr|stdout|syslog|file FILENAME). >Log notice stdout > > >The second (torrc.orig.1), has nothing in it.=20 >Which should I use? And, most importantly, what exactly do I write or ente= Not the empty one, obviously. :-) >r into this file?=20 >I really don't understand this: entry nodes nickname, nickname,... >This is where one does this, is it not? Please be exact, detailed and clea= >r. Unfortunately, what is clear to most of you goes way over my head :() That is why tor is distributed with a complete set of documentation. It would be well worth your time to read it. Remember, too, that the web site *stro
MacFUSE
Hi. This is just a follow up on a question I had asked. On March 20, 2010 I asked a question about a volume (MacFUSE), that showed up in my System Preferences window. (Mac OS X 10.5.2) I deleted the volume and its preferences but True Crypt won't work. I reinstalled the latest version of True Crypt and the MacFUSE volume was back in System Preferences. Now, True Crypt works. I initially asked because when I first tried to uninstall MacFUSE, Tor wouldn't work!!! That's why I thought there was a connection. Tor wouldn't work until, I reinstalled MacFUSE. Actually it is more accurate to say, "until it somehow reinstalled itself." Now, I'm not 100% sure of my memory in that regard as I couldn't open Vidalia/Tor first. I had to go through a True Crypt file first, but if memory serves me, the very first time I rid myself of MacFUSE, it was Tor that didn't work. that's all. thanks
Re: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
Hello Thanks. This brings up a couple of questions. One, The Onion Router.doc recommends against choosing one's exit nodes. Is your recommendation I exclude these naughty exit nodes, that are determined as such by Tor authorities? The .doc (Section 4.9--Can I control what nodes I use for entry/exit?), says, "We don't actually recommend you use these for normal use--you get the best security that Tor can provide when you leave the route selection to Tor." If you agree, why do you do this? I am assuming that is part of what your post implied or meant, i.e. that you do this in spite of Tor's recommendation. Two, in my Home Folder/Library, I have two (2), torrc files. one is torrc, the other is torrc.orig.1 The first one (torrc), has: # This file was generated by Tor; if youedit it, comments will not be preserved # The old torrc file was renamed totorrc.orig.1 or similar, and Tor will ignore it # If set, Tor will accept connectionsfrom the same machine (localhost only) # on this port, and allow thoseconnections to control the Tor process using # the Tor Control Protocol (described incontrol-spec.txt). ControlPort 9051 # Store working data, state, keys, andcaches here. DataDirectory /Users/zZ/.tor/ # Where to send logging messages. Format is minSeverity[-maxSeverity] # (stderr|stdout|syslog|file FILENAME). Log notice stdout The second (torrc.orig.1), has nothing in it. Which should I use? And, most importantly, what exactly do I write or enter into this file? I really don't understand this: entry nodes nickname, nickname,... This is where one does this, is it not? Please be exact, detailed and clear. Unfortunately, what is clear to most of you goes way over my head :() Do I go to Tor's list of naughty exit nodes for the addresses to input? I need lots of help here so I'm asking for your patience too. Thanks very much. -Original Message- From: Scott Bennett To: or-talk@freehaven.net; Runa Sandvik Sent: Wed, Apr 14, 2010 9:51 pm Subject: PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account) On Wed, 14 Apr 2010 13:34:47 +0200 Runa Sandvik wrote: >On Wed, Apr 14, 2010 at 1:31 PM, wrote: >> Hello > >Hi, > >> When you add the exit PrivacyNow to "your" ExcludeExitNodes list, is this >> done automatically inside of the Tor program afterwards, for any or all >> clients,=A0 or is this something I need to do also do in my torrc file? > >This is something that you will have to do in your torrc file as well. > Yes, I guess I kind of botched my first message on this. I should have also added a request that the directory authorities flag PrivacyNow as a "BadExit" because it clearly meets the definition of a bad exit. However, 1) any bad exits that I report I also add to my own torrc's ExcludeExitNodes list because a) I want it to take effect immediately and b) sometimes the authority operators appear to make exceptions for some misconfigured/miscreant nodes, and 2) I wasn't really awake yet when I was composing the alarm. PrivacyNow is a very high-performance node, and it will be a shame to lose it as an exit node. (A few hours ago, it was ranked by torstatus as the #44 node by throughput.) However, its owner/operator clearly does not want to be contacted about problems, so we aren't really left with much choice. In any case, it will still be a good entry or middle node for many, many circuits per second. So now I guess I should make the request. Unless the authorities know how to reach the operator of PrivacyNow to get his/her OpenDNS configuration fixed (or switched to Google's open name servers or something similar), will the authorities please flag PrivacyNow as a BadExit ASAP? Thanks. 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: huge pages, was where are the exit nodes gone?
Hi Arjan, On Wed, 14 Apr 2010 22:03:33 +0200 Arjan >Scott Bennett wrote: >> On Tue, 13 Apr 2010 19:10:37 +0200 Arjan >> wrote: >>> Scott Bennett wrote: BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. >>> I'm not an expert, but I managed to perform some google searches. >>> >>> http://libhugetlbfs.ozlabs.org/ >>> >From that website: >>> libhugetlbfs is a library which provides easy access to huge pages of >>> memory. It is a wrapper for the hugetlbfs file system. Applications can >>> use huge pages to fulfill malloc() requests without being recompiled by >>> using LD_PRELOAD. >> >> [Aside to Olaf: oh. So forcing the use of OpenBSD's malloc() might >> prevent the libhugetlbfs stuff from ever knowing that it was supposed to >> do something. :-( I wonder how hard it would be to fix the malloc() in >> libhugetlbfs, which is most likely derived from the buggy LINUX version. >> Does libhugetlbfs come as source code? Or is the use of LD_PRELOAD simply >> causing LINUX's libc to appear ahead of the OpenBSD version, in which case >> forcing reordering of the libraries might work? --SB] > >If Olafs test shows that CPU usage is reduced and throughput stays the >same or improves, modifying Tor to support linux huge pages might be an >option. Part 2 of this article contains some information about the >available interfaces: > http://lwn.net/Articles/374424/ Thanks. I'll take a look at it, but I still haven't had the nap I was going to take. :-( >Getting the wrapper to work with (or like) the OpenBSD version will >probably be easier. > One of the reasons I'm still awake is that I was browsing through the OpenBSD version of malloc() that is shipped with tor and libhugetlbfs's morecore.c module. I'm still not sure quite what is going on with how the stuff gets linked together, so I don't know which avenue might be the easiest approach, but modifying tor is probably the worst option. If the LINUX side of things gets fixed, then the patches ought to be contributed to the LINUX effort. However, it may be easier to modify the OpenBSD malloc() to call something in morecore.c to get memory allocated by the kernel, falling back to whatever it currently does if the morecore.c stuff returns an error because it can't allocate the hugepages necessary to satisfy a request. Of course, someone would still need to find out how to keep the LINUX malloc() from being substituted for the OpenBSD malloc() at runtime when the libhugetlbfs wrapper is in use. I doubt I can contribute much to the effort, given that I don't have a LINUX system available to me. > >>> Someone is working on transparent hugepage support: >>> http://thread.gmane.org/gmane.linux.kernel.mm/40182 >> >> I've now had time to get through that entire thread. I found it >> kind of frustrating reading at times. It seemed to me that in one of >> the very first few messages, the author described how they had long >> since shot themselves in the feet (i.e., by rejecting the algorithm of >> Navarro et al. (2002), which had already been demonstrated to work on an >> early >> FreeBSD 5 system modified by Navarro's team) on emotional grounds (i.e., >> "we didn't feel its [Navarro's method's] heuristics were right"). > > >Thanks for your analysis of the thread and the reference to the Navarro >paper. > >I've located the paper and will read it when time permits: >http://www.usenix.org/events/osdi02/tech/full_papers/navarro/ > Oh. Sorry about that. I had intended to include that at the end of what I wrote, but apparently I spaced it. I didn't mean to make anyone have to search for it. Thanks for correcting the deficiency in my message. I think you'll find their design is quite elegant and well thought out. It apparently required adding fewer than 3600 lines of code to the kernel to do it and uses a trivial amount of kernel CPU time in action. It's quite transparent and adaptive to conditions, but there are probably some conditions under which it might give less benefit than the LINUX hugepages way. However, it continually tries to promote processes that allocate enough space in a segment to fill the next larger page size. Its reservation system greatly increases the chances that promotions will occur. It's not a perfect solution to the problem, but I suspect there aren't any perfect solutions for it on the software side of things. What is really needed is for the chip manufacturers to correct the matter by increasing their TLB sizes rather dramatically. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * *
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: > On Tue, 13 Apr 2010 19:10:37 +0200 Arjan > wrote: >> Scott Bennett wrote: >>> BTW, I know that there are *lots* of tor relays running on LINUX >>> systems whose operators are subscribed to this list. Don't leave Olaf and >>> me here swinging in the breeze. Please jump in with your LINUX expertise >>> and straighten us out. >> I'm not an expert, but I managed to perform some google searches. >> >> http://libhugetlbfs.ozlabs.org/ >> >From that website: >> libhugetlbfs is a library which provides easy access to huge pages of >> memory. It is a wrapper for the hugetlbfs file system. Applications can >> use huge pages to fulfill malloc() requests without being recompiled by >> using LD_PRELOAD. > > [Aside to Olaf: oh. So forcing the use of OpenBSD's malloc() might > prevent the libhugetlbfs stuff from ever knowing that it was supposed to > do something. :-( I wonder how hard it would be to fix the malloc() in > libhugetlbfs, which is most likely derived from the buggy LINUX version. > Does libhugetlbfs come as source code? Or is the use of LD_PRELOAD simply > causing LINUX's libc to appear ahead of the OpenBSD version, in which case > forcing reordering of the libraries might work? --SB] If Olafs test shows that CPU usage is reduced and throughput stays the same or improves, modifying Tor to support linux huge pages might be an option. Part 2 of this article contains some information about the available interfaces: http://lwn.net/Articles/374424/ Getting the wrapper to work with (or like) the OpenBSD version will probably be easier. >> Someone is working on transparent hugepage support: >> http://thread.gmane.org/gmane.linux.kernel.mm/40182 > > I've now had time to get through that entire thread. I found it > kind of frustrating reading at times. It seemed to me that in one of > the very first few messages, the author described how they had long > since shot themselves in the feet (i.e., by rejecting the algorithm of > Navarro et al. (2002), which had already been demonstrated to work on an early > FreeBSD 5 system modified by Navarro's team) on emotional grounds (i.e., > "we didn't feel its [Navarro's method's] heuristics were right"). Thanks for your analysis of the thread and the reference to the Navarro paper. I've located the paper and will read it when time permits: http://www.usenix.org/events/osdi02/tech/full_papers/navarro/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 19:10:37 +0200 Arjan wrote: >Scott Bennett wrote: >> BTW, I know that there are *lots* of tor relays running on LINUX >> systems whose operators are subscribed to this list. Don't leave Olaf and >> me here swinging in the breeze. Please jump in with your LINUX expertise >> and straighten us out. > >I'm not an expert, but I managed to perform some google searches. > >http://libhugetlbfs.ozlabs.org/ >>From that website: >libhugetlbfs is a library which provides easy access to huge pages of >memory. It is a wrapper for the hugetlbfs file system. Applications can >use huge pages to fulfill malloc() requests without being recompiled by >using LD_PRELOAD. [Aside to Olaf: oh. So forcing the use of OpenBSD's malloc() might prevent the libhugetlbfs stuff from ever knowing that it was supposed to do something. :-( I wonder how hard it would be to fix the malloc() in libhugetlbfs, which is most likely derived from the buggy LINUX version. Does libhugetlbfs come as source code? Or is the use of LD_PRELOAD simply causing LINUX's libc to appear ahead of the OpenBSD version, in which case forcing reordering of the libraries might work? --SB] > >Someone is working on transparent hugepage support: >http://thread.gmane.org/gmane.linux.kernel.mm/40182 I've now had time to get through that entire thread. I found it kind of frustrating reading at times. It seemed to me that in one of the very first few messages, the author described how they had long since shot themselves in the feet (i.e., by rejecting the algorithm of Navarro et al. (2002), which had already been demonstrated to work on an early FreeBSD 5 system modified by Navarro's team) on emotional grounds (i.e., "we didn't feel its [Navarro's method's] heuristics were right"). They then spent the rest of the thread squabbling over the goals and individual techniques of Navarro et al. that they had reinvented, while not admitting to themselves that that was what they had done, and over the obstacles they were running into because of the parts that they had *not* adopted (yet, at least). At times, it appeared that the author of the fairly large patch that implemented the improvements to the hugepage system was arguing directly from Navarro et al. (2002) with one of the other participants. Shades of Micro$lop's methods and not-invented-here attitude. What a bummer to see LINUX developers thinking in such denial! So if the guy who had written that early kernel patch for LINUX (the thread was a year and a half ago) has persisted in his implementation, he may have the bugs out of it by now, but in the long run, his design (or lack thereof) should provide something that provides significant improvement for some large processes on LINUX, but the way it is done won't be at all pretty. Unlike the method of Navarro et al., which that team had actually done not on an x86-type of system, which is the only type so far supported for superpages in FreeBSD 7 (not sure about 8.0), but on an alpha machine, using the four page sizes offered by the hardware, the method implemented by the OP of the thread used a "hugepage" size (2 MB) that is not supported by the hardware, except for pages in instruction (text) segments. I didn't see anywhere in the thread an explanation of how their software pages are made to work with the hardware, but I would imagine they must combine two software hugepages to make a single 4 MB page as far as the address translation circuitry is concerned. It left me wondering much of the time which processor architecture they were working with, though it eventually became clear that they were indeed talking about x86 processors. The others in the thread also voiced opinions that the method would prove to be not easily portable to other hardware architectures, unlike the Navarro method. Navarro et al. (2002) found that their array of test applications did not all benefit at all superpage sizes. Which superpage size crossed the threshhold into reduced TLB thrashing varied from application to application. Some benefited after the first promotion from 8 KB base pages to 64 KB superpages. Others benefited after the further promotion to 512 KB superpages. Still others' performance characteristics did not improve much until after the third promotion to 4 MB superpages. Which size causes the big improvement for an application depends almost entirely upon the memory access patterns of that application. It remains to be seen whether an application that doesn't speed up in FreeBSD tests until after the application has been promoted to the 4 MB superpages will speed up in LINUX's 2 MB hugepages. I'm still tired. I think I might take a short nap again, so I might not post replies to anyone's followups on this for a few hours. (Yawn...) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
On Wed, 14 Apr 2010 17:23:35 +0200 Olaf Selke wrote: >Scott Bennett wrote: > >>> >>> It appears memory consumption with the wrapped Linux malloc() is still >>> larger than than with openbsd-malloc I used before. Hugepages don't >>> appear to work with openbsd-malloc. >>> >> Okay, that looks like a problem, and it probably ought to be passed >> along to the LINUX developers to look into. > >yes, but I don't suppose this problem being related to hugepages >wrapper. Linking tor against standard glibc malloc() never worked for me >in the past. Always had the problem that memory leaked like hell and >after a few days tor process crashed with an out of memory error. >Running configure script with --enable-openbsd-malloc flag solved this >issue but apparently it doesn't work with libhugetlbfs.so. Is tor statically linked? If not, I wonder if it's a library-ordering problem, where a version of malloc() in libhugetlbfs or in a library called by a routine in libhugetlbfs gets linked in ahead of the OpenBSD version. I don't know how much flexibility that LD_PRELOAD method gives you, but perhaps you could try the -rpath trick we FreeBSD folks had to use to force use of openssl from ports rather than the broken one in the base system. > >After 17 hours of operation resident process size is 1 gig. How much was it typically using before? > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND >21716 debian-t 20 0 1943m 1.0g 24m R 79.4 26.9 927:51.27 1 tor > >On the other hand cpu load really seems to be reduced compared with >standard page size. > Holy Crapola! 79.4% is a *reduction*?!?? 8-Q What did it use before? 100%? 1 GB is 512 hugepages. I wonder if getting the malloc() issue resolved and lowering the working set size would reduce the CPU time still further, given that each TLB only holds 64 entries. (I fail to see yet why the LINUX developers picked a hugepage size that is not supported by hardware, at least not for the data and stack segments.) A long time back, we tossed an idea around briefly to the effect that you might get more balanced utilization of your machine by running two copies of tor in parallel with their throughput capacities limited to something more than half apiece of the current, single instance's capacity. That would bring the other core into play more of the time. A configuration like that would still place both instances very high in the list of relays ordered by throughput, but the reduction in the advertised capacity of each would help to spread the requests to both better. They would still be limited by the TCP/IP's design limit on port numbers for the system as a whole, which you would likely never see because the kernel would probably just refuse connections when all port numbers were already in use, but would probably allow you to squeeze more total tor throughput through the machine than you get at present, while still leaving a moderate amount of idle time on each core that would then be available for other processing. Have you given any more thought to this idea over the ensuing months? 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] Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: >> >> It appears memory consumption with the wrapped Linux malloc() is still >> larger than than with openbsd-malloc I used before. Hugepages don't >> appear to work with openbsd-malloc. >> > Okay, that looks like a problem, and it probably ought to be passed > along to the LINUX developers to look into. yes, but I don't suppose this problem being related to hugepages wrapper. Linking tor against standard glibc malloc() never worked for me in the past. Always had the problem that memory leaked like hell and after a few days tor process crashed with an out of memory error. Running configure script with --enable-openbsd-malloc flag solved this issue but apparently it doesn't work with libhugetlbfs.so. After 17 hours of operation resident process size is 1 gig. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 1943m 1.0g 24m R 79.4 26.9 927:51.27 1 tor On the other hand cpu load really seems to be reduced compared with standard page size. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
pimp my tor network status (tns), bandwidth sum
Hi, based on Kasimir's recent work evaluating the much more realistic read/write bandwidth history from extra-info data I've pimped my tns site with an additional info of the sum bandwidth of all routers displayed in the current view. It's located in the first line of the "Aggregate Network Statistic Summary | Graphs / Details" table near page bottom (the one without a percent value). Displaying all routers in the default view this bandwidth value doesn't say very much, but if you narrow down your choice with for example required flags "exit = yes" you'll see in the "Total Bandwidth of displayed Routers" row the sum bandwidth of all exit nodes being about 57.000 KByte/s for the last 24 hours. http://torstatus.blutmagie.de have fun, 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] Re: huge pages, was where are the exit nodes gone?
On Wed, 14 Apr 2010 15:00:52 +0200 Olaf Selke wrote: >Christian Kujau wrote: >> On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: >>> and straighten us out. Remember that Olaf runs the highest-load-bearing >>> tor node in our whole network, and there are at least two or four dozen >>> others that should be considered heavyweight relays that are also on LINUX >>> systems. >> >> ...and some of them are running on old notebooks and the tor process is >> only a few megabytes in size :-| > >In the end of all days tor traffic has to pass thru the exit nodes. >About 50% of all traffic leave tor network thru the top 15 exit nodes >only. If they can't cope with their load all nifty tor ports for >smartphones, dsl routers or whatsoever acting as entry or middle man >will be in vain. Exactly. > >> However, if it turns out that using hugepages in Linux would help larger >> Tor installations (and "superpages" can be recommended for *BSD systems[0] >> as well), maybe this can be documented somehwere under doc/ or in the >> wiki. But let's see how Olaf's experiment turns out. > >process size is still growing: > >anonymizer2:~# hugeadm --pool-list > Size Minimum Current Maximum Default > 2097152 100 313 1000* > >It appears memory consumption with the wrapped Linux malloc() is still >larger than than with openbsd-malloc I used before. Hugepages don't >appear to work with openbsd-malloc. > Okay, that looks like a problem, and it probably ought to be passed along to the LINUX developers to look into. But the important question is how is tor's CPU usage looking now with the hugepages as compared to before? It was the CPU usage that you said was the severe problem before. 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/
PrivacyNow is a BadExit (was Re: PrivacyNow node has misconfigured OpenDNS account)
On Wed, 14 Apr 2010 13:34:47 +0200 Runa Sandvik wrote: >On Wed, Apr 14, 2010 at 1:31 PM, wrote: >> Hello > >Hi, > >> When you add the exit PrivacyNow to "your" ExcludeExitNodes list, is this >> done automatically inside of the Tor program afterwards, for any or all >> clients,=A0 or is this something I need to do also do in my torrc file? > >This is something that you will have to do in your torrc file as well. > Yes, I guess I kind of botched my first message on this. I should have also added a request that the directory authorities flag PrivacyNow as a "BadExit" because it clearly meets the definition of a bad exit. However, 1) any bad exits that I report I also add to my own torrc's ExcludeExitNodes list because a) I want it to take effect immediately and b) sometimes the authority operators appear to make exceptions for some misconfigured/miscreant nodes, and 2) I wasn't really awake yet when I was composing the alarm. PrivacyNow is a very high-performance node, and it will be a shame to lose it as an exit node. (A few hours ago, it was ranked by torstatus as the #44 node by throughput.) However, its owner/operator clearly does not want to be contacted about problems, so we aren't really left with much choice. In any case, it will still be a good entry or middle node for many, many circuits per second. So now I guess I should make the request. Unless the authorities know how to reach the operator of PrivacyNow to get his/her OpenDNS configuration fixed (or switched to Google's open name servers or something similar), will the authorities please flag PrivacyNow as a BadExit ASAP? Thanks. 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] Re: huge pages, was where are the exit nodes gone?
On Tue, 13 Apr 2010 18:18:02 -0700 (PDT) Christian Kujau wrote: >On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: >> and straighten us out. Remember that Olaf runs the highest-load-bearing >> tor node in our whole network, and there are at least two or four dozen >> others that should be considered heavyweight relays that are also on LINUX >> systems. > >...and some of them are running on old notebooks and the tor process is >only a few megabytes in size :-| If tor is only using, say, 25 MB or so, then tor's CPU load is probably low anyway. Nevertheless, any other process on a small x86-type of LINUX system that has a working set greater than 256 KB of instruction pages and/or 256 KB of data+stack pages would benefit from using enough hugepages to cover its needs. > >However, if it turns out that using hugepages in Linux would help larger >Tor installations (and "superpages" can be recommended for *BSD systems[0] >as well), maybe this can be documented somehwere under doc/ or in the >wiki. But let's see how Olaf's experiment turns out. > >Christian. > >[0] http://www.freebsd.org/releases/7.2R/relnotes-detailed.html >This is disabled by default and can be enabled by setting a loader >tunable vm.pmap.pg_ps_enabled to 1. A couple of caveats regarding the automatic version available in FreeBSD 7.2 and later releases are in order here. To the best of my knowledge, this feature is not yet available :-( in any of the other BSDs, so tor relay operators on NetBSD, OpenBSD, DragonflyBSD, MirBSD, etc. can disregard all of this stuff for the time being. Another matter is that FreeBSD systems on AMD processors of designs older than the K10 types may actually get poorer performance with the feature enabled. That's because on those processors the number of entries in the TLBs is drastically reduced in the 4 MB pages mode. So on pre-K10 AMD processors the official recommendation that I read was to try it if you have a large process that is bogging down, and just see what happens. If it helps, then that's great, but be prepared for the strong possibility that it might just make matters worse. 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/
messages indicate strange choice by tor
I would be most interested in knowing the explanation for the decision that tor announced in the following pair of messages. Apr 14 08:55:50.861 [info] connection_or_group_set_badness(): Marking OR conn to 194.109.206.212:443 as too old for new circuits: (fd 7, 900 secs old). We have a better canonical one (fd 118; 2239 secs old). Apr 14 08:55:50.861 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 7 (194.109.206.212:443) [Too old]. Why is the younger connection too old, yet the much older connection is somehow "better"? 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] Re: huge pages, was where are the exit nodes gone?
Christian Kujau wrote: > On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: >> and straighten us out. Remember that Olaf runs the highest-load-bearing >> tor node in our whole network, and there are at least two or four dozen >> others that should be considered heavyweight relays that are also on LINUX >> systems. > > ...and some of them are running on old notebooks and the tor process is > only a few megabytes in size :-| In the end of all days tor traffic has to pass thru the exit nodes. About 50% of all traffic leave tor network thru the top 15 exit nodes only. If they can't cope with their load all nifty tor ports for smartphones, dsl routers or whatsoever acting as entry or middle man will be in vain. > However, if it turns out that using hugepages in Linux would help larger > Tor installations (and "superpages" can be recommended for *BSD systems[0] > as well), maybe this can be documented somehwere under doc/ or in the > wiki. But let's see how Olaf's experiment turns out. process size is still growing: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 313 1000* It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow node has misconfigured OpenDNS account
On Wed, Apr 14, 2010 at 1:31 PM, wrote: > Hello Hi, > When you add the exit PrivacyNow to "your" ExcludeExitNodes list, is this > done automatically inside of the Tor program afterwards, for any or all > clients, or is this something I need to do also do in my torrc file? This is something that you will have to do in your torrc file as well. -- Runa Sandvik *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: PrivacyNow node has misconfigured OpenDNS account
Hello When you add the exit PrivacyNow to "your" ExcludeExitNodes list, is this done automatically inside of the Tor program afterwards, for any or all clients, or is this something I need to do also do in my torrc file? Thanks -Original Message- From: Scott Bennett To: or-t...@seul.org Sent: Wed, Apr 14, 2010 4:52 pm Subject: PrivacyNow node has misconfigured OpenDNS account I just found my weather information being blocked, giving me the OpenDNS "access blocked" web page. After some checking, I found the culprit exit: PrivacyNow. There is no contact information in its descriptor in the current directory, so I'm adding it to my ExcludeExitNodes list. :-( 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/
PrivacyNow node has misconfigured OpenDNS account
I just found my weather information being blocked, giving me the OpenDNS "access blocked" web page. After some checking, I found the culprit exit: PrivacyNow. There is no contact information in its descriptor in the current directory, so I'm adding it to my ExcludeExitNodes list. :-( 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/
