Arm Release 1.4.0
Damian Johnson
atagar1 at gmail.com
Sun Dec 19 04:44:20 UTC 2010
Fantastic! Thank you Fabian. I've applied everything except the
myInternal -> myExternal address change (see below).
http://www.atagar.com/transfer/tmp/arm_bsdTest4.tar.bz2
http://www.atagar.com/transfer/tmp/arm_bsdTest4.tar.bz2.asc
> I had to disable the connection panel anyway, as arm kept hogging the CPU
This is a problem. Arm defaults to making a connection resolution
every five seconds, and falls back to do them more infrequently if
they take longer than 50ms. This should mean that the backoff is
triggered if at least 1% of the total CPU time is spent on connection
resolutions (handled in lines 344-355 of connections.py [1]). However,
it sounds like that isn't functioning as intended. :(
For Linux I'm about to borrow a trick from psutil [2] and read the
/proc contents instead of performing ps and netstat lookups. Hopefully
this will help.
Could you please run the test.py script to check the relative runtimes
for the resolvers? Netstat and sockstat seem to perform the best on
Linux systems, but if this isn't always the case then I should have
arm check which is the fastest when picking the default resolver.
Also, did the log message saying "Arm's cpu usage is high (averaging
X%). You could lower it by dropping the connection data (running as
"arm -b")." show up? My system doesn't experience this issue so I
haven't confirmed if the warning's working or not.
> I had to unset LANG to get the connection resolver working... Probably arm itself should do that.
This is the first I've heard of this. Do you have any idea what the
language has to do with connection resolution or arm? I'm weary of
messing with the environment variables since they're highly system
dependent and tend to have unintended side effects...
> Even on the Debian GNU/Linux system the egrep doesn't understand the "\s".
Weird, on Ubuntu it's happy with both (I'd expect Ubuntu and Debian to
be alike in this way). Thanks for the fix! I applied it to sockstat
resolutions too.
> At least for the lsof 4.78 I'm using, the 8 needs to be a 7.
Hm, sounds like your lsof version is missing one of the columns.
Here's what some of my results look like:
tor 28246 atagar 12u IPv4 181244 0t0 UDP
192.168.0.3:56143->192.168.0.1:53
tor 28246 atagar 16u IPv4 181278 0t0 TCP
192.168.0.3:47057-><scrubbed>:443 (ESTABLISHED)
I've changed it to strip the "(ESTABLISHED)" part and use the last
column so it should be happy with both of our versions.
> ... and an improperly tested hack to show the external address between the local and the foreign one, if the local and the external one differ.
I tried applying this one (with a few fixes) but the connection panel
isn't great code to hack up. This introduces issues with column
alignment, confusing controller entries like:
127.0.0.1:9051 --> 89.188.20.246 --> 127.0.0.1:55224
and probably a few other headaches for edge cases like small screen resolutions.
The problem isn't really the change, but rather that this part of the
arm codebase kinda sucks. I'm not sure if you noticed, but the
connection panel and controller differ from all the rest of the
components. The reason is that arm's been going through a rewrite and
these are the last bits of the old codebase left.
I like this change, and the connection panel is the next part due for
a rewrite, so while I'm revising it I'll be sure to include this.
Many thanks for the patches! -Damian
[1] https://svn.torproject.org/svn/arm/trunk/src/util/connections.py
[2] https://code.google.com/p/psutil/
More information about the tor-dev
mailing list