[EMAIL PROTECTED] wrote: > Example torrent: > http://torrent.ibiblio.org/torrent.php?info_hash=99f4370a715f21de64728ac11b28477371621523 > > > Pismo G3 Powerbook, 500MHz, 640MB, 6.9.0.dfsg.1-4 > > btdownloadgui.bittornado uses about 9% by top > second forked instance uses 7% > Xorg uses 6 % > total : 22% > btdownloadgui.bittorrent uses less than 7% by top > second forked instance uses 2% > Xorg uses 3 % > total : 12% > btdownloadcurses.bittornado uses about 4% by top > doesn't use a second instance > Xorg uses 0 % > total : 4% > > These are somewhat sensitive to the download rate, but there is > definitely a big difference in responsiveness of the machine if multiple > torrents are open. > > btdownloadgui.bittornado also has a habit of core dumping 90% of the > time when I click "Cancel" or "Finish". (I thought this went away, but > it still happens) > > How else can I help? > > Tim >
Hi Tim, thanks for the reply. I don't think you're doing the math correctly on these. The CPU percentage of the second forked instance is included in the number quoted by top, so you can't add the two together meaningfully. So, using this on your numbers gives: * btdownloadgui.bittornado = 9% + 6% = 15% * btdownloadgui.bittorrent = 7% + 3% = 10% * btdownloadcurses.bittornado = 4% + 0% = 0% This shows that there is increased CPU usage using bittornado, though not much, however there is also increased Xorg usage. These numbers are very similar to mine, if you allow for scaling due to the CPU speed difference. The main reason I see for this small increased CPU usage is the extra functionality and development that has gone into bittornado. Keep in mind that the bittorrent package has not undergone a new upstream revision in 2 years due to licensing issues. This can also explain the higher Xorg usage, as just looking at the bittornado gui window shows the increased complexity and functionality compared with the very simple bittorrent gui window. For an additional comparison, I ran the time program on the three. I used the Eclipse torrent you suggested, but only ran it until the download percentage reached 10%. Here are the results (the column headers don't line up properly, but they are in the same order as above): > Program Format Description > btdownloadgui.bittornado btdownloadgui.bittorrent > btdownloadcurses.bittornado C Name and command line arguments of > the command being timed. > 5% 4% 2% P Percentage of the CPU that this job got. This > is just user + system times divided by the total running time. > 8055 10578 3360 R Number of minor, or recoverable, page faults. > 0.83 0.85 0.61 S Total number of CPU-seconds used by the system > on behalf of the process (in kernel mode), in seconds. > 4.41 2.76 1.44 U Total number of CPU-seconds that the process > used directly (in user mode), in seconds. > 4096 4096 4096 Z System's page size, in bytes. This is a > per-system constant, but varies between systems. > 879 557 143 c Number of times the process was > context-switched involuntarily (because the time slice expired). > 88.89 79.79 72.93 e Elapsed real (wall clock) time used by the > process, in seconds. > 9427 8937 8239 w Number of times that the program was > context-switched voluntarily, for instance while waiting for an I/O operation > to complete. (The bittornado download took a little longer to reach 10%, though this was probably network related.) The CPU usage numbers are very similar to my previous results (no Xorg numbers though). There doesn't seem to be anything anomalous in any of these numbers to suggest a problem with bittornado. Unfortunately, I can't suggest a solution to the slowdowns you're seeing. If you were on i386, I'd suggest using the PSYCO option, but it's not available for Mac. If you don't mind the loss of some features, you could use the bittorrent program, or the text-based bittornado programs. -- Cameron Dale [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
