So that can hardly be the problem. No idea what it is, then. Anyone else running Debian?
Well. I'll go get some sleep. PC stays on, of course, so maybe something useful will turn up overnight.
Will try this out as soon as the next WU finishes (12h remaining).
I've been manually circumnavigating this problem by leaving network activity suspended, and switching it to active just after a WU completes, loosing just a few seconds on the new WU.
Thanks Bernd and other devs....
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
So that can hardly be the problem. No idea what it is, then. Anyone else running Debian?
Well. I'll go get some sleep. PC stays on, of course, so maybe something useful will turn up overnight.
Running Xubuntu Dapper 6.06 on this computer and where the old app initially showed a time to completion of about 50ish hours, this one is showing 180 hours (It's a Celeron 800mhz). We'll see if that time changes dramatically in the next day or 2, but at this rate, I'll let y'all know how the result turns out in about a week.
Is that very long for this kind of machine? Because if it is, that might be a first clue, as Ubuntu is more or less based on Debian architecture...
Btw: roughly 1/3 in 18 hours... guess you can see where this is heading.
I have looked into the times for two types of machines yet (AMD Opteron like #913062 (Debian Etch) and Core2Duo like #847720 (Fedora Core 5)) and can't see a difference in execution times between 4.18 and 4.21 for Tasks that claim the same credit, the same with ziegenmelkers host #922868.
As I said, maybe it's Debian/Ubuntu specific. What distro are your boxes running? It can't really be the CPU type, as mine is an Athlon just like Michael's and while his does fine mine is lame without end (can't be the kernel version, either, he is running 2.6.18 and so am I). Anything else it might be... hmm... cache size? Maybe hosts with smaller cache get affected worse? Dunno how much cache C2Ds have but I think it's quite a lot, and I'm quite sure Opterons have rather much... Michael's Athlon, being somewhat newer than mine, also has twice the cache. Could that be a clue?
It can't really be the CPU type, as mine is an Athlon just like Michael's and while his does fine mine is lame without end (can't be the kernel version, either, he is running 2.6.18 and so am I). Anything else it might be... hmm... cache size? Maybe hosts with smaller case get affected worse? Dunno how much cache C2Ds have but I think it's quite a lot, and I'm quite sure Opterons have rather much... Michael's Athlon, being somewhat newer than mine, also has twice the cache. Could that be a clue?
More likely than the Distro, but I'm still not sure. I'll try to build it with the same compiler, which is the only difference I can think of that could have a large impact on the runtime. Might take a bit, though.
I have looked into the times for two types of machines yet (AMD Opteron like #913062 (Debian edge) and Core2Duo like #847720 (Fedora Core 5)) and can't see a difference in execution times between 4.18 and 4.21 for Tasks that claim the same credit, the same with ziegenmelkers host #922868.
BM
Yes my host #922868 has finished a WU and there seems to be no time difference.
This host is one of two VMware sessions running under OpenSuSE 10.2, glibc 2.5(compiled by gcc 4.1.2) and without X . The other VMware host has also finished a unit, but I will not do a manual refresh to report, but wait till the client is doing it by itself. Host for these two is an AMD X2 4400+@2,63 GHz running WinXP pro.
The next host that will finish a WU with the beta app(in about 4.x h) is this one, but it will report the finished WU right after uploading.
If it's confimed that the beta app takes about the same time than 4.18, I'll install it on another host runnig Knoppix, which is based on Debian. Maybe that can shed light on Annika's problem.
8%, lucky you. In my case it
)
8%, lucky you. In my case it has to be more than 80...
Unless I'm mistaken, I also have glibc 2.3.6 here.
RE: 8%, lucky you. In my
)
2.3.6 here as well.
CU
BRM
So that can hardly be the
)
So that can hardly be the problem. No idea what it is, then. Anyone else running Debian?
Well. I'll go get some sleep. PC stays on, of course, so maybe something useful will turn up overnight.
Will try this out as soon as
)
Will try this out as soon as the next WU finishes (12h remaining).
I've been manually circumnavigating this problem by leaving network activity suspended, and switching it to active just after a WU completes, loosing just a few seconds on the new WU.
Thanks Bernd and other devs....
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: So that can hardly be
)
Running Xubuntu Dapper 6.06 on this computer and where the old app initially showed a time to completion of about 50ish hours, this one is showing 180 hours (It's a Celeron 800mhz). We'll see if that time changes dramatically in the next day or 2, but at this rate, I'll let y'all know how the result turns out in about a week.
M
Is that very long for this
)
Is that very long for this kind of machine? Because if it is, that might be a first clue, as Ubuntu is more or less based on Debian architecture...
Btw: roughly 1/3 in 18 hours... guess you can see where this is heading.
I have looked into the times
)
I have looked into the times for two types of machines yet (AMD Opteron like #913062 (Debian Etch) and Core2Duo like #847720 (Fedora Core 5)) and can't see a difference in execution times between 4.18 and 4.21 for Tasks that claim the same credit, the same with ziegenmelkers host #922868.
BM
BM
As I said, maybe it's
)
As I said, maybe it's Debian/Ubuntu specific. What distro are your boxes running? It can't really be the CPU type, as mine is an Athlon just like Michael's and while his does fine mine is lame without end (can't be the kernel version, either, he is running 2.6.18 and so am I). Anything else it might be... hmm... cache size? Maybe hosts with smaller cache get affected worse? Dunno how much cache C2Ds have but I think it's quite a lot, and I'm quite sure Opterons have rather much... Michael's Athlon, being somewhat newer than mine, also has twice the cache. Could that be a clue?
RE: What distro are your
)
I was just editing it...
More likely than the Distro, but I'm still not sure. I'll try to build it with the same compiler, which is the only difference I can think of that could have a large impact on the runtime. Might take a bit, though.
BM
BM
RE: I have looked into the
)
Yes my host #922868 has finished a WU and there seems to be no time difference.
This host is one of two VMware sessions running under OpenSuSE 10.2, glibc 2.5(compiled by gcc 4.1.2) and without X . The other VMware host has also finished a unit, but I will not do a manual refresh to report, but wait till the client is doing it by itself. Host for these two is an AMD X2 4400+@2,63 GHz running WinXP pro.
The next host that will finish a WU with the beta app(in about 4.x h) is this one, but it will report the finished WU right after uploading.
If it's confimed that the beta app takes about the same time than 4.18, I'll install it on another host runnig Knoppix, which is based on Debian. Maybe that can shed light on Annika's problem.
cu,
Michael
[edit]error corrected[/edit]