Thanks again for looking into this and fixing the bugs Sam. Also I changed my user name from LimeDude to spearson. My real name is Soren, anyone can call me that if they like.

It's sure been good reading of all the fixes, and now I see 3.6.10 Beta is out.

btw--I'm seeing an unusual jump in 3.6.9 Stats->Advanced->Uploads->General->Interrupted

Normally this is 10-20% of Completed File Tranfers, but now it's the reverse.

Most uploads are proceeding as usual. Any suggestions what to watch for here?

Attached Images

picture 2.png (14.7 KB, 932 views)

3.6.10 looks a bit unstable
-selecting a range of search results to download--most of which were already complete or in progress--sometimes locked up 3.6.10 when choosing the 'NO' option of the "Overwrite . . ." dialog. Force quit was my only option twice. Filtering search results of existing files or flagging unique results would help here.

-had problems with the new (Microsoft servent??) tunes from Magnetmix: didn't go through to iTunes 4.1 smoothly and something reset the 'Use iTunes' pref. I lack experience with iTunes to know if this is related to LW or the iTunes update.

-dl'ing multiple rare files from a host that has only one ul slot required a lot of 'babysitting.' The first file would begin well, but the others would go to "Need Sources" very quickly. 'Browse Host' showed the server to be online. Find sources button would work away with no dl's beginning, then after the 5 mins "resume" would work to get one of the dl's started. For 1 slot servers, client-side queuing of multiple requests might reduce the traffic unnecessary babysitting causes.

-re the occasional 'spike' of sudden upload peaks of 1,038 KB/s in the stats: this looks to coincide with a crawler showing up in the handshaking stats. Tough to track since crawlers show up only about once per hour of uptime.

-the QRP-Leaf-Sent graph needs a higher range, say for 1000 messages per second. The graph obscures the table (my average is 600 messages NOT routed to leaves per second).

Sorry for the fuzzy impressions--ran out of time to get more specific. This note is more of a 'raised eyebrow' rather than a 'heads-up.' Missed the changelog.

Ah, didn't know this was an issue being looked into. The spikes are caused by a CPU under-run (ie, app demanding more CPU cycles than a system has available), presumably resulting in a couple of timer events which *should* be a second apart happening in rapid sucession. The CPU under-run does seem to be caused by occasional floods on incoming requests.

Hi topbanana
Thanks for the info (and again for the files--the sheet music is proving the most popular). I'll keep an eye on the CPU % and see if that correlates.
btw--did you see that the gnutella netsize hit the highest peak in a year today? With more people sharing and the team developing so many fixes and improvements, things are looking good for gnutella. Hope the Ultrapeer numbers imrove too.