Arm Release 1.4.0

[Fabian Keil]

Damian Johnson <atagar1 at gmail.com> wrote:

> - I'm using the os.times() function to get the arm cpu usage which is
> *supposed* to include child processes. However, it doesn't seem to be
> including the ps and netstat lookups since disabling them or making
> them occur more frequently doesn't have an effect on this value. Pity,
> that was the main point in including this stat...
> 
> Per chance do you have any ideas for how to include the system calls
> in this figure?

Nope, but I'm also under the impression that they don't
really matter and that the load is mainly caused by the
algorithms used in arm itself.

> > I get the impression that the back-off mechanism doesn't apply in
> > that situation?
> 
> Backoff only applies if the connection results are taking too long.
> The netstat runtime was 0.0587 seconds so backoff was probably being
> triggered a little bit, but wouldn't help with the cpu usage being
> wasted on the sorting.

Right.
 
> > Another problem I noticed that may or may not be connection related
> > is that arm occasionally stops working and neither updates the screen
> > nor reacts to keyboard input.
> 
> Uggg, that's annoying. The low cpu usage means that it's probably not
> falling into any sort of busy wait situation. How frequently does it
> occur? Does it always happen when on a particular part of the
> interface? Does this arise when interacting with arm, or does it occur
> on its own (ie, not in response to user input)? A repro case would be
> very helpful...

So far it happened maybe four or five times on both FreeBSD and
Debian GNU/Linux combined, always when not interacting with arm.
I haven't found a way to reproduce it, yet.

> For debugging you can run arm at its debug runlevel (arm -e 1) with
> the "features.logFile" set to collect arm's events and see if it's
> continuing to do anything while it seems frozen.

Ok, I'm already running with "-e 1" anyway.

>                                                  Also, to double check
> that ssh isn't the issue you could run arm in a detached screen
> session, then reattach with another ssh connection when it seems
> frozen to see if they get the same results.

Good idea. I'm not using ssh when running arm on FreeBSD,
though, so I expect that this isn't it.

> > Arm Test Options: ...
> 
> Great! Did you run the test multiple times? It might have been biased
> due to cached results (favoring netstat since it had been running in
> arm). However, besides lsof outperforming sockstat that was more or
> less what I'd expected. Thanks!
> 
> I should have the testing utility fetch twice to account for this...

I ran the test multiple times and the results looked comparable
to me, but I didn't confirm it with ministat.
 
> > If the output of the resolver utility is (partly) localized
> > the grep for "ESTABLISHED" no longer matches.
> 
> Ack! Would you suggest modifying LANG, letting it fall back to another
> resolver, or something else? The resolver fallback in this case isn't
> ideal since (a) netstat tends to outperform the others and (b) since
> the netstat command is available but failing it'll make three attempts
> before going to the fallback (so fifteen seconds before the
> resolutions appear).
> 
> If you have an idea for how to modify the LANG env variable safely
> (ie, without unintended consequences on other platforms nor leaving
> the user's terminal in a bad state, even when arm crashes) then I'd be
> happy to apply a patch. I don't trust that I have a deep enough
> understanding of this to do the above properly. :(

I would expect messing with LANG or other localization-related
variables in the arm shell script or in arm itself to be without
consequences for the user's terminal once arm is stopped.

> That said, if this is a Linux-only issue then it might be moot if the
> connection resolution via /proc contents works.

I don't actually think the problem is limited to GNU/Linux.

I run FreeBSD without localization support compiled-in, otherwise I'd
probably could get the same problem there (assuming the utilities in
question actually support localization).

> > Hmm, I thought the confusing controller case should be handled
> > with the ipAddressIsPrivate() patch
> 
> Oops. You're right, that shouldn't be happening. That was probably due
> to something I did while messing with the patch.
> 
> Out of curiosity, what is going to be involved with the bsd port? When
> arm makes a new release what is the process for getting the port
> upgraded? Emailing you? Filing a ticket?

Announcing it in a place I now about should do.

For example I usually update the Vidalia port after a new
release has been mentioned on tor-cvs@ and the source tarball
is actually fetchable.

> Also, if this is going to require a permanent tarball link (like
> Gentoo) then please let me know and I'll add it to the site.

Stable download URLs would indeed be useful.

Fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20101224/bf785cbf/attachment.pgp>