Hi all,
I have been running seti for a while, and over the last week or so I have noticed that tasks are showing as 89.33 hours to completion. Now, when these tasks run on Cuda which they are already assigned to, yet they take less than 30minutes! Its not a big issue but I was wondering what the issue is? if there is an issue?

D

On all machines? On some of them?

IIRC there have been a number of reports that tasks are suddenly coming in with wrong estimates.
It doesn't appear to be a general problem, but reports have been too sketchy so far to get to the bottom of it.

I would suspect some problem with serverside dcf calculations or with the way numbers are stored and handled along the way.

[rant]NB That happens when you put application specific dcf into the server instead of into the client. On the client at least you would be able to edit it to a sensible value if wacky. But no, you need that silly number to feed it into an even sillier credit 'calculation' (I may be wrong about the last one. Not about the irrationality of the credit 'calculation' but if the speed value used for estimate calculation is used for credit 'calculation' as well)[/rant]

---

Carola
-------
I'm multilingual - I can misunderstand people in several languages!

On several machines I have seen tasks come in with with way to short est completion times (9mins est & 3hrs actual) or way to high (40hrs & 3hrs actual). When that happens the tasks that are already in the queue are still at their normal est times. Then once work starts on these new tasks everything starts going bonkers.

My i3 notebook was running fine with a 3 day cache for a few days. Then it got a bunch of tasks that were est of 9 min, while all the other tasks in the queue were still in the 2-3 hour range. Then once it started working on those 9 min tasks, that actually took 2-3 hours, all of the other tasks got their est time moved way up.

On a machine at work tasks were coming in with est of 35-40hr & completing in its normal 3-4 hour time frame. The DCF value was within a normal range as well.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

yeah I have the same, its all on one machine though - http://setiathome.berkeley.edu/show_host_detail.php?hostid=5830000

they do seem to be adjusting, I might just leave the on over the weekend to see if it levels out.

I dont know if the fact I upgraded to Windows 7 (64bit) recently helps at all?

This is something that I've noticed with my new i5 computer 5828732. That computer was delivered on 24 January, and first connected to SETI on 25 Jan (morning). Yet that HostID was created on 24 Feb (evening).

What happened was that somewhere along the line a SETI scheduler (server) contact went wrong, and a duplicate record for the computer was created, with a new HostID. We had problems when the web code here was updated, and a few functions broke - one of them was 'delete (old) computer'. While testing that, I tidied my account up with 'merge duplicate records by name'. That's when I lost the original creation date for this host, and at the same time I lost all the speed and validation data from application details - those numbers are new since 24 Feb. So, I had to start the 10-validation training process all over again from scratch. It's quite painless if you do it with small cache settings, but if you allow your cache to fill up with hundreds or thousands of jobs during the "DCF squared" phase, life is going to get painful.

This is something that I've noticed with my new i5 computer 5828732. That computer was delivered on 24 January, and first connected to SETI on 25 Jan (morning). Yet that HostID was created on 24 Feb (evening).

What happened was that somewhere along the line a SETI scheduler (server) contact went wrong, and a duplicate record for the computer was created, with a new HostID. We had problems when the web code here was updated, and a few functions broke - one of them was 'delete (old) computer'. While testing that, I tidied my account up with 'merge duplicate records by name'. That's when I lost the original creation date for this host, and at the same time I lost all the speed and validation data from application details - those numbers are new since 24 Feb. So, I had to start the 10-validation training process all over again from scratch. It's quite painless if you do it with small cache settings, but if you allow your cache to fill up with hundreds or thousands of jobs during the "DCF squared" phase, life is going to get painful.

This speaks to just how buggy this whole process is - the code is apparently in very poor - dare I say, unprofessional - condition. Probably was written without being thought through, in my (ex-)professional opinion. This has happened before; why was it inflicted upon the users without thorough testing? Isn't SETI Beta supposed to be for that?

I don't mean to insult anyone, but, come ON, guys...

---

Actually, Seti Beta is for testing Seti applications although it's also used to test some server changes. Seti itself is the Boinc's test bed. That, in part, is why Seti managed to survived for so long with minimal funding.

Seti's large user base allows bugs to surface rather quickly. Any other project, including Seti Beta, would take forever to find some problems.

P.S. You could always become a Boinc Alpha testers thus adding your professionalism to the hundred or so devoted testers.

Actually, Seti Beta is for testing Seti applications although it's also used to test some server changes. Seti itself is the Boinc's test bed. That, in part, is why Seti managed to survived for so long with minimal funding.

Seti's large user base allows bugs to surface rather quickly. Any other project, including Seti Beta, would take forever to find some problems.

P.S. You could always become a Boinc Alpha testers thus adding your professionalism to the hundred or so devoted testers.

That's EX-professionalism. I'm retired now, and just like to complain every so often, to kind of keep my toe in the water. Besides, I can't concentrate like I used to, so I wouldn't be as much use as I would have a few years ago.

Time marches on!

---