1.23 seems to ignore speed limit

[kluelos]

I had updated my XP SP3 system to BitComet 1.23, then noticed problems loading most web sites in FireFox. (I run BitComet almost constantly.) Sites never seemed to load but never timed out either. If I let them run they load eventually, but this can take a hour or more.

I noticed that BitComet's tray balloon said it was uploading at 24 KB/s which is the extreme limit of my connection. I opened BitComet, and the title bar confirmed 24 KB/s.

My global maximum upload speed is set to 20 KB/s, which I reconfirmed. (LT seeding is disabled, though that should not be relevant.) Lowering the global maximum upload speed made no difference. 1.23 is blowing right through the limit I set.

I've stepped back to 1.22 which has apparently resolved the issue.

[greywizard]

This was, more or less, one of the issues I've reported in one of the betas for v.1.23. I hope the team is working on that and that they will, once and for all, make the client NEVER go above the set upload limit.

While more robust connections can deal with that "surplus" over the set limit, it really brings down to their knees the slower ones.

[Lucy26]

Yes Wiz has reported this problem before, however the team could not reproduce it, and we did not see any problem from the bitcomet.xml sent by Wiz. :unsure:

[kluelos]

It's a crippling problem. You can't do anything else, internet-wise, with BC taking over all of the bandwidth. While it could be a problem with the value written into the .xml file, it could equally be a code problem with reading the value or respecting it once it's read, and those wouldn't show up in the .xml file.

[kluelos]

I have found 1.22 also ignoring the set limit, although not "pegging the meter" at maximum, so 1.23 is just worse and not the origin of the problem.

I'm having to choose between running BitComet or doing anything else on the internet. That isn't good.

[kluelos]

Add 1.21 to the list. Now trying 1.20

[kluelos]

And a fail there. Back to 1.17.

Downgrading to 1.17 will mess you up, because you're going backwards across the transition to storing things in %appdata% instead of the program directory.

1.17 is where I came into this party, finally deciding to move on from 0.70 for most of my torrenting at the time it was released. I feel like I'm being chased back to 0.70.

1.20's transgressions weren't so bad, which is perhaps why this hasn't been reported before, but if I set a global max upload limit of 20 KB/s, then BitComet needs to be uploading at 20 KB/s or less, not skip up to 21, or 24 when it feels like it.

I've been loading the version, setting it to run, and watching for this behavior mostly with the systray balloon, and when I see it slip above its limit, verifying this with the full application. This behavior is progressively worse -- happens more frequently and exceeds the limit by a wider margin more consistently -- with later versions.

Whoops, no, here's 1.17 uploading at a steady 21 KB/s when its upload limit is set at 20. Maybe I will have to go all the way back to 0.70

[Lucy26]

I see here. Thank you kluelos, I'll report to the team and see if they can fix the problem. ;)

[kluelos]

Thanks, Lucy. BTW, 1.10 and 1.00 have the same issue, so I'm back to 0.70 as my regular client.

The issue, specifically, is that I set a global maximum upload speed limit of 20 KB/s, but these clients will exceed that for substantial time periods -- usually, popping up to 21 KB/s and sustaining that. They don't greatly exceed that, so they don't completely shut you down like 1.23 does, but they're still not respecting the limit.

[Lucy26]

Thank you testing the previous versions, kluelos. The team will work on the problem. =)

[alaa777]

http://www.cometforums.com/topic/12795286-download-limit/page__p__55183__fromsearch__1entry55183

so the bug reproduced finally :D

Edited October 8, 2010 by alaa777 (see edit history)

[kluelos]

No, sorry, that's a different issue entirely.