I'm getting a little work, unfortunately the time to completion is 60 time to large. I'm starting to take this personally!

should take 1.5 hours, says 80 hours...

---

About 2 hours ago, mine said about 8 hours. Now is says 45 minutes. In reality it is 7 minutes.

Steve

---

Warning, addicted to SETI crunching!
Crunching as a member of GPU Users Group.
GPUUG Website

I had a whole batch of them that claimed to be 7 minutes on my CPU turns out they were 35 minutes. Then I turn around and get more but they say 80 hours. Gotta love the new calculations

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

well it's nice to know it isn't just me. my rig is full up with 80 hour work units and will not ask for more work. i will gladly leave if that is what they want.

---

one machine under estimating the time by 50% or so.. other is over estimating
the time by about 100%.

Has anyone else noticed the first few percent go really slow, then it speeds up for each unit?

---

Janice

In front of me I have one machine that has a ton of work and this one. This one as I looked DCF jumped from about 0.20000 to 3.6xxxx

With the current Servers changes it would appear that the FPOPS estimate has changed causing the local machine to adjust DCF.

Regards

---

Please consider a Donation to the Seti Project.

most of this falls under a very large category..

"stuff I do not understand".

Everything I take something off the list, a bunch more things get added.

---

Janice

Hmmm. I've been getting some really strange estimated times on WUs, all week. I've had some that were as low as 3 mins and some, like the ones I'm currently going through, with 'times' of 17 hrs! The '17 hr' WUs are being crunched in about, 2 hrs.....

---

Don't take life too seriously, as you'll never come out of it alive!

I have an AP on my old P4 that started out as 320 hours to completion.Well it will finsh in about 53 hours wich is about normal with Opp apps. MY i7 GPU has times of 32 hours but being done in 30 Minutes with Opp Apps. Didnt we have this problem a while ago? Im not worried it will sort its self out,just throws you for a loop a bit.

---

[/quote]

Old James

Normally, the estimated times are pretty close, but most of the WUs I've had this week, have been a 'country mile', out. The other snag is, these same times are used for the WU cache....thats a bit of a problem, if we're going to have longer 'outages'.

---

Don't take life too seriously, as you'll never come out of it alive!

I just looked at my GPU times and they have come down from 30 hours to 15 hours.
So things should work out in the end.

---

[/quote]

Old James

Only on my Slowest CUDA rig, I have 15 MB WU's estimated 2 hours.
3 other are without SETI MB.
Ehh, jusst got 1 AP WU of 20 hours.

Getting hot, in the Lowlands :), gives my host some cooling down time....

Let them run for a hours, no WU's, then I just shut them down, saves a lot of electricity and don't have to use the AC.

And thus saves money, for other things........;-)

---

I have GPU tasks on Rig on a Bench estimated at 60 hours infact they take 10 mins, also a couple of AP tasks esimated at 400 hours completed in 12 hours.
Where's the logic in that, as a consequence the rig is not calling for new jobs and will run out before it gets any.

Dave

---

I have GPU tasks on Rig on a Bench estimated at 60 hours infact they take 10 mins, also a couple of AP tasks esimated at 400 hours completed in 12 hours.
Where's the logic in that, as a consequence the rig is not calling for new jobs and will run out before it gets any.

Dave

Indeed. Thats the problem I was trying to emphasise...then add in the factor of longer 'outages' and things could get 'ugly', with people increasing their cache sizes to compensate for those longer 'outages'. If push comes to shove, that big green button on the front of the PCs is going to be used a bit more.

---

Don't take life too seriously, as you'll never come out of it alive!

I have get Cuda´s with 9:30h now. That is very bad, before this coming big outtage. My Cache of my most Crunchers is very emty. So i get not enough work, to stay with work on the outtage.

So i must corrupted my flops to get enough. Every Day new things, so i must travel across my town to change in the configuration on my PC´s :-(

---

Be careful of messing with your cache size until this thing calms down and we can figure out where it is going. As someone said they are getting times on one machine that is way high and on another that are way low. It doesn't seem to matter what you are running and a bunch of shorties might trigger a response of the server thinking all your work can finish that fast. In other words, you set a 10 day cache while your estimates are way high then all of a sudden it goes the other way, you wind up with way more work than you can handle.(or is that the other way around? Whatever, you get my point!)

---

PROUD MEMBER OF Team Starfire World BOINC

I only have less then 10% of what i should have in my queue, I'm way under fed. It looks like it just isn't worth it any longer!

---

soft^spirit wrote:

...
Has anyone else noticed the first few percent go really slow, then it speeds up for each unit?

CUDA work definitely has that, the progress updates for Gaussian, Pulse, and Triplet searches were missing in the code from which those apps were built. Near the end there's a safety feature which forces it to catch up so it'll finish at 100%. The missing stuff has been added to the current code base, just hasn't been used for release builds yet.

Another thing you might be seeing is just a matter of not having accurate progress during startup and initialization. IIRC there's a rough guess for the baseline smoothing, but the optimum function testing is different for hosts with different capabilities so it would be more trouble than it's worth to try to even estimate what fraction of the run time it represents.

On CPU, there's also an effect due to using FFT lengths 65536 and 131072 only during the first part of a task (roughly up to 50% progress). The FFTs themselves are typically less efficient on CPUs than shorter lengths. The only searching done at those FFT lengths is the quick spike finding (and triplet finding for VLARs), so the FFT speed difference affects the progress more.

                                                                  Joe

I put the flops count tag back in My app_info file, Things look better now right now work looks like 1:14:36(HH:MM:SS) on one and that's dropping, It would be nice to be notified when the project has turned the flops calculator back on of course.

---

The T1 Trust, PRR T1 Class 4-4-4-4 #5550, 1 of America's First HST's

I just got a bunch of work, and all of mine are as normal as they should be. Roughly 4 hours per unit, but running the optimized apps, so it'll be a little lower. But no weird times here. Running BOINC version 6.10.18, don't know if that has anything to do with it. Never got any weird messages either about the app_info.xml. Maybe I'm special??? LMAO!

---