Could someone expain why when the progress bar reaches 100 % it keeps on running up the time. I have wu that run up to 25 mins. after it is supposed to be done. Did not know you could do more that 100% :-)

> Could someone expain why when the progress bar reaches 100 % it keeps on
> running up the time. I have wu that run up to 25 mins. after it is supposed to
> be done. Did not know you could do more that 100% :-)
>

It's one of the "fixes" in Seti 4.05. Just shows you that Seti gives you that extra effort into each and every WU. : )

---

> Could someone expain why when the progress bar reaches 100 % it keeps on
> running up the time. I have wu that run up to 25 mins. after it is supposed to
> be done. Did not know you could do more that 100% :-)
>
Simple ---- The Seti programmers don't know how to do math

Before it took only 10 min to reach 50% and 6 hr to finish.

Now it seems more linear but sometime have an overtime period.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

Try to think of it as giving 110% to the project. ;-)


SetiUK - The Offical UK Seti Site - Team Lookers
The Space Directory
Visit Seti.org.uk
SETI News Mailing List


S@h Berkeley's Staff Friends Club ©
[/url]

Hello there,
To have a correct progression bar, you must have an accurate mathematical guessing algorithm how long its gonna take you to finish that specific item.
In this case were FFT is involved that's not so obvious, since you are dealing with widely varying signals. This can lead to not-so-accurate guessing and hence an incorrect propagation bar.
It is totally different from the guessing mechanism for instance that you have when guessing the time left over when defragmenting a drive. In this case the guessing can be a lot more accurate, because a whole lot of dependant factors are known or at least better known or guessed/measured on the fly. This has as result that the progression bar can be defined in the software more accurately.

Be patient, this is really of minor importance, when they have sorted out the big ones, they eventually iron this one out...

I should really not worry to much about this.
And by the way, the remark that the programmers don't know maths is really ridiculous. To say something like this REALLY proves that the one who is stating this DOESN'T know himself the quirks of FFT.

Greeting from Belgium ;-))
HP Phd Physics, Chemistry, Informatics.

---

Estimate:
Ok..we've got 384k of data
..and we will be going through it
..and for each 16k we will do routine1 [aa] times
.. and routine2 [bb] times
.. and we might find some interesting spikes...so guess at
1% of times = interesting spike
.. do spike_routine 1% times

So total time should equal
(384/16) *
( ([aa] * time for routine1) + ([bb] * time for routine2) )
+ 1% * time for spike_routine

Actual:
384k data
each 16k do routine1 [aa] times
each 16k do routine2 [bb]+[cc] times
and 3% interesting spikes so do spike_routine 3% times

So total time Actually equals:
(384/16) *
( ([aa] * time for routine1) + ([bb]+[cc] * time for routine2) )
+ 3% * time for spike_routine

---

> Be patient, this is really of minor importance, when they have sorted out the
> big ones, they eventually iron this one out...


It is nnot a matter of being patient I was just wondering!

> I should really not worry to much about this.
> And by the way, the remark that the programmers don't know maths is really
> ridiculous. To say something like this REALLY proves that the one who is
> stating this DOESN'T know himself the quirks of FFT.


And as for some of the other answers hmmmmmmm take thaem with a grain of salt I hope they are just poking a little fun :-)


> Greeting from Belgium ;-))
> HP Phd Physics, Chemistry, Informatics.
>
>
>

> And as for some of the other answers hmmmmmmm take thaem with a grain of
> salt I hope they are just poking a little fun :-)
>

Yes that was my intent.

One additional thing about the progress bar. The fix that they did in 4.05 may be an area for the developers to look at for the cause of the increase in time for the wu's.

---

I have noticed when installing many software packages that the progress bars there don't reflect reality at all either ...

Neither does any OS install reflect real times either... MS says 30 Min tops, I have yet to see it in less than one ...

---

> I should really not worry to much about this.
> And by the way, the remark that the programmers don't know maths is really
> ridiculous. To say something like this REALLY proves that the one who is
> stating this DOESN'T know himself the quirks of FFT.

The people on this board are way too sensitive. I was just taking a litle poke at our friendly Seti dev.

If you check when I started with Seti you'll see I've been around for a while and I am quite familiar with the vulgarities of analyzing the data.

I also do know something about creating software. I wrote my first program (self-taught) on a Commodore Pet in 1978, and can assure you I wasn't using a high level assembler and compiler they have today.

I haven't checked, but from the resulting output, my guess is that they do little if any adjustment to the initial time estimate as the crunching of the data progresses. You have to admit that is sloppy programming.

Anyway, relax, be happy, and smile.
There are much more important things to worry about in life.

And as the Vulcans would say LIVE LONG AND PROSPER.

---

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470

To all the best Seti-friends in this thread.

Some explanation. It surely was not my intend to offend any of you, but the underlying thought as Paul and others stated was :

Very ofter progress bars do not always correctly reflect the actual progress in the real situation. Many examples can be cited. For instance install programs of new software.
I give you an extreme example - a couple of issues ago - of the Norton Utilities (I don't know anymore which edition) the program even decided to go in a halt for 10 to 15 minutes... The install program came to a halt and if you were so infortunate to take the Cd out of the drive, you got stuck with an incomplete and cripple installed program... The indicator in this case never gave accurately the situation.

I really am not a "turn others down type" of person. Sometimes matters are difficult to dicuss from after a keyboard, moreover in a totally different language so we will have to live with some communicative further explanation.
(In Belgium, since we are such a small country at the centre of Europe, we are often obliged to speak/write many different languages - so interpretation and feel of WHAT is actually said can be enormously different and hence misinterpreted...)

I wanted to give on this one some info in the first place from my point of view of mathematics.
I understand that most of you only wanted info.
But I wanted to express too the opinion "Give the team a break, they really must have had a hell of a time lately..."

In this perspective they even finally DID really something about the Public Relation aspect. (I'm no team cheerleader!)
This was the only factor I really did criticise often myself! If you start projects like this, you have the moral duty to inform whoever is taking part!!!

I can wait, even for a year or more for a scientific result - but please keep me informed of what's happening - that's the attitude they have taken NOW.
More info concerning the server status, a technical news page will in the end increase the credibility of the project and in my humble opnion take part of the whining load (hopefully) of the shoulders of the DEV's and of the TEAM.

Greetings to all who are taking part in this virtual walk towards the stars,

H P (not the company)

PS: started way back on IBM 360 with punched cards...

---

> > I should really not worry to much about this.
> > And by the way, the remark that the programmers don't know maths is
> really
> > ridiculous. To say something like this REALLY proves that the one who is
> > stating this DOESN'T know himself the quirks of FFT.
>
> The people on this board are way too sensitive. I was just taking a litle
> poke at our friendly Seti dev.
>
> If you check when I started with Seti you'll see I've been around for a while
> and I am quite familiar with the vulgarities of analyzing the data.
>
> I also do know something about creating software. I wrote my first program
> (self-taught) on a Commodore Pet in 1978, and can assure you I wasn't using a
> high level assembler and compiler they have today.
>
> I haven't checked, but from the resulting output, my guess is that they do
> little if any adjustment to the initial time estimate as the crunching of the
> data progresses. You have to admit that is sloppy programming.
>
> Anyway, relax, be happy, and smile.
> There are much more important things to worry about in life.
>
> And as the Vulcans would say LIVE LONG AND PROSPER.
>

Be aware that people reading these post do not know you and cannot hear the intonations. Furthermore, they will not read through all threads to get an impression of how your character is. Using smileys could give a rough overview of your intentions! :p

---

<img src="http://boinc.mundayweb.com/seti2/stats.php?userID=1578">

> Did not know you could do more that 100% :-)

Heh... this reminds me of a time I saw someone running a scandisk (back in the windows 98 days with the blue/yellow status screen). It got to 100% during its repair operation... and just kept right on going. 105%... 110%... I think that is about when we decided to stop it. As I recall there was a reformatting party the following day :)

---

A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site

> Hello there,
> To have a correct progression bar, you must have an accurate mathematical
> guessing algorithm how long its gonna take you to finish that specific item.
> In this case were FFT is involved that's not so obvious, since you are dealing
> with widely varying signals. This can lead to not-so-accurate guessing and
> hence an incorrect propagation bar.
> It is totally different from the guessing mechanism for instance that you have
> when guessing the time left over when defragmenting a drive. In this case the
> guessing can be a lot more accurate, because a whole lot of dependant factors
> are known or at least better known or guessed/measured on the fly. This has as
> result that the progression bar can be defined in the software more
> accurately.
>
> Be patient, this is really of minor importance, when they have sorted out the
> big ones, they eventually iron this one out...
>
> I should really not worry to much about this.
> And by the way, the remark that the programmers don't know maths is really
> ridiculous. To say something like this REALLY proves that the one who is
> stating this DOESN'T know himself the quirks of FFT.
>
> Greeting from Belgium ;-))
> HP Phd Physics, Chemistry, Informatics.
>
>
>

I'm still trying to get -my- progress bar to serve decent mixed drinks...

;o)

---

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT

> I'm still trying to get -my- progress bar to serve decent mixed drinks...
>
> ;o)
>
If there's no gravity, so Seti would be floating ...
I'm starting to like it. By the way where is Pascal the rascal? He should be here too, he has a progress bar in true color. See other thread... Big LOL

Greetz ;-))))

---