> We may be looking at variances in WUs themselves rather than an overall "work
> engine" issue.
>
I'm seeing some WU variances.......finally. Been running seti cruncher 4.05 since it came out with BOINC 4.09, noticed the obvious increase in WU crunch time of course.

P4 533fsb 3.06 GHZ HT was taking 3:45 (2 at a time) or so on average with Seti 4.03.
Since the switch to BOINC 4.09,4.12,4.13 and Seti 4.05 its been consistently averaging 5:30 (2 at a time) till late yesterday that is. :)

WU's from this blockset, 01mr04aa.18860.10593.298580.138 , crunch time has dropped to an average of 4:27 (2 at a time), low 4:22, high 4:32. Its only been 15 or so WU's and its only been on this one computer so far.

So it has to be WU variance. But I don't think that explains the over all slowdown since the change to SETI 4.05, the near consistent 1.75 hour jump was a little extreme to say the least.

Until a get a big batch of WU's that clocks in 3:45ish time after time after time, I'm "smeptikal" about the statement "Regarding complaints that 4.05 is taking much longer: The programmers around here are convinced this has nothing to do with release/debug versions, but we're still looking into it."

MARS

---

<br>
Mars <br>
<img src='http://www.boincstats.com/stats/banner.php?cpid=7d22d5f982e9096d95fa085d6ee2c1bc'>

> Until a get a big batch of WU's that clocks in 3:45ish time after time after
> time, I'm "smeptikal" about the statement "Regarding complaints that 4.05 is
> taking much longer: The programmers around here are convinced this has nothing
> to do with release/debug versions, but we're still looking into it."
>
> MARS
>
How can the programmers deny what the WU result tables show? All they have to do is look at the CPU times from before everyone updated to Seti 4.05 and compare them to the times from after the 4.05 update. The 50-60 percent increase in times is quite noticable.

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

> OT @ Papa Zito.
>
> This may sound like a strange question if you don't know what I'm talking
> about, but are you Papa Zito from Kingdom of Loathing?
>

*grin* Why yes, I am.

---

> > And I can't really think of anything that'll make that stop.
>
> Try adjusting your preferences to reduce the number of days to connect to the
> network.
> If this is set too high, then you will have a big stash in your cache, but
> won't be able to finish them in time.
> A reduced value will result in a smaller cache, but more frequent requests.
>
> Just a thought.
>
No, because it will still download too many WUWUWUWUs since it thinks I can crunch more than I actually can.

---

Dear Dev.Team--round 4 hours is to long on a AMD64.- are this developed from the Kids of the Scientists with his FIRST compiler ;-)))
ok learn for life and the future,help kids learn for a better world ;-)

---

BUMP ruleZ

> > OT @ Papa Zito.
> >
> > This may sound like a strange question if you don't know what I'm
> talking
> > about, but are you Papa Zito from Kingdom of Loathing?
> >
>
> *grin* Why yes, I am.

I thought so...

I just started playing it, and saw your name on the various fora. I didn't think there could be too many Papa Zito's around. :)

Yes, I am running wu's on version 4.13 at about 5:05 where with version 4.09 it was always under 5 hours.

I am using Windows XP service pack 1 on a budget AMD 2400xp 1.99 gig on budget memory.

---

<I><B>Processing for the Planetary Society since July 5, 1999

Maybe just recently all the work units come from a batch of heavier computation.

What they really need to do is take a computer, set it up with the older version, have it do a work unit. Take that SAME computer, upgrade to newer version, have it do the same workunit with the newer version.

This will prove or disprove it once and for all.

---

I do not have a superman complex; for I am God, not superman!

Try running the BOINC CLI version. I never have run the GUI, and instead just run the CLI in the background. Takes up a space on the Windows task bar (if you use Windows), but it is much faster than the GUI. I guess it uses the same logic as with Classic S@H, in which console went faster than screensaver.

---

BOINC has a ?bug? that counts CPU time even when calculation is paused. Could this effect be worsened by 4.13? I thought i saw previous versions compensate for this on restart of calculation, but i may be wrong.

---

I heard something about making the CLI version a service, thus making it go away from the taskbar...

Why would it take longer though? isnt the science part and the control part seperate? they should be. Its not like we have BOINC creating visuals all the time even in CGU version. In fact mine never does, I dislike screensavers.

---

I do not have a superman complex; for I am God, not superman!

I have found that with ver4.05 the processing time has increased a great deal for some machines. My dual xeon (400 mhz 1 meg L2) has jumped from about 11/12 hrs per WU to 22/23 hrs. All the others have increased by 20/30% and more.

Love to know if better science is being done. Still no official reason given.

The xeon machine used to average about 10.5 hrs/WU with seti classic.

Hope its not just a build issue.

Nairb

---

How can the programmers deny what the WU result tables show? All they have to do is look at the CPU times from before everyone updated to Seti 4.05 and compare them to the times from after the 4.05 update. The 50-60 percent increase in times is quite noticable.

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

>
> What they really need to do is take a computer, set it up with the older
> version, have it do a work unit. Take that SAME computer, upgrade to newer
> version, have it do the same workunit with the newer version.
>
> This will prove or disprove it once and for all.
>
That would be too easy.

I'm surprised that's not one of the checks that is automatically performed before releasing a new version. Run a test WU, check for accuracy, and check the CPU time. Log the data. Maintain copies of all versions on the test machine so verification can be done again at a later date, if necessary.

Afer revieweng there is no difference in time between Boinc 4.05, 4.09, 4.12 & 4.13. There is an increase in time of seti 4.05 over seti 4.03.
computer a 4.03 = 3hr39min 4.05= 5hr
computer b 4.03= 3hr 42 min 4.05 = 5hr
there is +/- 15 min depending on the wu.

edit
I have run both the gui and the cli and on my computers, I see no difference in time.
edit #2
The above is base on completion time not estimated time.

---

Fred
BOINC Alpha, BOINC Beta, LHC Alpha, Einstein Alpha

> also the running time has beem longer since 4.09
> how many wu's have you run in two days?
>
> Timmy
>
Time has increased for me from 4.09 to 4.13 by about 30 minutes.

---

me@rescam.org

@Papa Zito

> > Try adjusting your preferences to reduce the number of days to connect to the
> > network.
> > If this is set too high, then you will have a big stash in your cache, but
> > won't be able to finish them in time.
> > A reduced value will result in a smaller cache, but more frequent requests.
> >
> > Just a thought.
> >
> No, because it will still download too many WUWUWUWUs since it thinks I can
> crunch more than I actually can.
>
No, that's not really the case. If your cache is sized right you'll be just fine in spite of it underestimating your time to process.

ex: Set preferences to download 2 days of work. It will download enough WUs to where it 'thinks' you have 4 days of work available.

Suppose it is underestimating the time to process by 25%, so you actually have 5 days of work in your queue now.

As you return WUs, BOINC examines what's left in your queue to see how much is left. When your queue gets down to what it believes is 2 days of work left, it will again download what it believes is another 2 days worth of work. Again, you actually have 5 days of work, but it's not a problem as you still have plenty of time (assuming you crunch most of the time and not just occasionally) to return all the WUs before the 14 day timeout.

If instead, you set your preferences at 7 days, it will then download what it thinks is 14 days of work (running right at the edge of the timeout). But because it has underestimated by 25%, it has actually downloaded almost 19 days worth of work and a significant portion (though not all) of your WUs may go past the deadline. However, it will not download additional WUs until your cache drops down to what it thinks is 7 days of work left. So occasionally, you will be doing creditable work, but alot of it is wasted too.

I find that a 2 day cache is about right for my setup which is connected 24/7. YMMV if you are on dialup, etc.