This evening the "To Completion"-times of sent out wus started to be "high" again. Did somebody notice this, too?



P.S. Please read http://setiweb.ssl.berkeley.edu/forum_thread.php?id=2628 ,too.

/
Urs

> This evening the "To Completion"-times of sent out wus started to be "high"
> again. Did somebody notice this, too?
>
>
>
>
>
> /
> Urs
>
I received three 27:22:18 WU's. Mine are normally 4:33:43. My long one's are _4's and I see yours are _6's.

Jerry

> I received three 27:22:18 WU's. Mine are normally 4:33:43. My long one's are
> _4's and I see yours are _6's.
>
> Jerry
>

So the wus seem to be the ones with the "high"-to completion times of some weeks ago, which had to be resent now, i think.


\/
Urs

Interesting - I just checked my laptop with 2 seti + many predictor WU and the last seti was 31 hrs to completion. It ends with _7. Unable to check the other seti only machines at the moment.

Nairb

yes Urs same here.

Take a look to the "ending" of the scheduled WUs,
_4, _6

those WU's have been out(recycled) now for the sixth time (zum sechten Male draussen)

The value of the "estimated completion time" is written in the WUs XML file.

For new WUs, berkeley had fixed the estimate (so far as I know).
Guess, the fix was not done on the WU file-level.

When the longrider WUs starts with running, the estimate shrinks to "normal"

Unfortunately the estimated credit for those WU's shrinks also.

ric

> When the longrider WUs starts with running, the estimate shrinks to "normal"
>
> Unfortunately the estimated credit for those WU's shrinks also.
>
> ric
>

Maybe someone corrects these credits somewhen in the far far future, maybe not.

\/
Urs

The other problem it causes is this: if you have five - five hour Wu's and one 25 hour Wu, the scheduler "thinks" you have 50 hours of work. You actually have approximately 30 hours, because the 25 hour unit will actually crunch in 4 - 5 hours. So you won't get new Wu's as soon as you should (per your preferences).

No big deal at this time, since the system has had enough problems to interrupt the smooth WU transfer.

The guys/gals did a nice job with the newest August 6 information on this sites home page. Things appear to be looking up!

> The other problem it causes is this: if you have five - five hour Wu's and one 25 hour Wu, the scheduler "thinks" you have 50 hours of work. You actually

first, a thank you to Urs for opening this thread.

the 2nd thank you goes to JAF.

You gave me an Anwser, without the need to post the question
(I mean this in positive way)

Like some of you, I'v got still unanswered questions.

I'm monitoring the Queues of each client.
The "downloads" are completed, the Qs filled up.

2 PCs are 1:1 same like the other, same mb, same cpu, same..., same seti prefs
benchmark differs a bit

One has now 23 WUs in Q, the other 29.

The pc with 23 has 4 longrider WUs, the pc with 29, 3 longrider WUs

taking now the estm. average from all, yes, it's exactly the difference!¹

I really hope, the scheduler is not "thinking" to much, he should just DO what he was programmed for, this as fast as possible without thingking...

well, it's not really a problem but (my opinion), its's ugly.
Especialy when the delivering demand of WUs can't be served.

still having fun

greetings
ric


¹
pc 1 23 WUs estimated time (19x 2:55:30 + 4x 17:22:55)
pc 2 29 WUs estimated time (26x 2:53:49 + 3x 17:33:03)
the difference is exactly the "missed" 6 WUs