GNOME Bugzilla – Bug 359197
Slow download
Last modified: 2006-10-06 19:05:36 UTC
I used the old Pan 0.14.2, and when downloading binaries it would use up all my download bandwidth, at just under 600K/s. With 0.115, even using the four server connections, I cannot get more than 180K/s. nzbperl confirms that my newsserver is still capable of the speed. Since I cannot find a speed throttle in the preferences, I suppose that this is an inadvertent error. Please fix this, as this makes the Pan rewrite useless to me for binaries.
What version of OS X are you using?
I'm using 10.4.8. The general infrastructure is from Fink, but they only provide 0.14.2 and an ancient version of libpcre, so I compiled myself the recent versions of pcre and pan.
Hmm. Unless Pan is pegging your CPU -- and please tell me if it is -- then I suspect the problem is in the socket polling code. Googling around for "OS X", "socket", and "polling" indicates that OS X's socket polling is broken, but that also fink's glib2 has patched in a workaround. (1) Is pan pegging your CPU? Or is everything normal except for the slow download? Or some other noteworthy behavior? (2) What version of Fink and glib2 are you using? (3) If you run 0.115, then 0.14.2, on the same news server one after another, do you still see 0.115 running 4x as slowly?
1) My CPU is barely above idle. 2) Fink 0.24.26. glib 2.8.6 (which I'm pretty sure is from Fink) 3) What's this one-after-the-other thing, BTW? It just caused something weird to happen. I ran 0.14.2, which was blazing at 600K/s. I then ran 0.115 which, while not as zippy, was pulling perhaps 400K/s. Better. Where's the detail about the poll problem?
*** Bug 359703 has been marked as a duplicate of this bug. ***
Could you both try the patch in bug 358061 and see if that helps any? Regarding (3) the one-after-the-other test was just to make sure that both versions were run under similar network conditions, so that it couldn't be chalked up to ISP problems. (4) You'll probably laugh at me for asking this, but does Pan say that all the connections are active and none idle? (5) Does changing SECONDS_TO_SLEEP_ON_EAGAIN in pan/tasks/socket-impl-gio.cc from 0.2 to 0.1 speed things up any?
Patch and/or 3) doesn't improve anything (380 vs 580) 4) All are active as far as I know (from the number 4@380KB/s displayed), but there's little granularity. The other newsreader offers a progress bar for each connection (and also the task at hand) and they show also 4 active connections 5) Bingo! It reached 540KB/s, compared to the 580 of the other software, without such noticeable CPU usage increase (the 5% was a high maximum, I'm really using 1-2% on my Athlon XP 2800+) 6) Going down to 0.05s increase yet again to 600K/s. It is in fact comparable to the previous figure. The usage is around 1%, with (probably artificial) spikes to 3% All in all, the CPU usage variation is within measure error, so I don't observe the same phenomenon (disproportional CPU usage) as you did. I'm resisting the urge of the 0.00001 value :-)
6) This does it for me too. In addition, my CPU is hovering 3-5%, which looks fine to me. Avi
Created attachment 74111 [details] [review] 0.115 patch Please Give this patch a try. Is it faster or slower than having a low SECONDS_TO_SLEEP_ON_EAGAIN?
Created attachment 74115 [details] [review] 0.115 patch fix bug in previous patch
It is equally fast: like 660 (SECONDS_TO_SLEEP_ON_EAGAIN at 0.05) vs 680, but the difference doesn't mean anything. Which patch leads to the lesser agressive polling, if there's a difference ?
IMO the patch is a cleaner way to do it. One last question, is there a difference in CPU load between the two setups you tested in Comment #11?
Better answer to #11: the patch fixes the root problem that sleeping was the previous workaround for, so there's no need to sleep at all anymore.
The CPU usage difference is for what I see not mesurable and therefore neglectable. There's of course the problem of low reproducibility that doesn't help. From your comments, I would also go with the later patch (removing the sleeps).