Damian Johnson <atagar1@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature