One thing is for sure it will help freeze some server space up when the AP results start to get perched.

---

Just got screwed by two errors validating with each other.
http://setiathome.berkeley.edu/workunit.php?wuid=1683786197

---

Grant
Darwin NT

Just got screwed by two errors validating with each other.
http://setiathome.berkeley.edu/workunit.php?wuid=1683786197

And on top of all, that result is now added to the database, as a valid result for the signals in the WU.

I wonder how many millions of invalid results that is now in the database as "real/valid" results?

The Science is compromised by all those crazy computers, filling the database with invalid results, and nobody from the project seems to care one iota about that.

And to add to it all, you haven't even received any toaster from SETI I guess....

What's interesting is the other two Computers were NV 750s running the "New" driver and using CUDA32. Previously the same scenario was seen with 2 NV 900s validating against each other while running CUDA32. It would Appear the "New" driver doesn't like CUDA32.

I suppose it was inevitable, first it was the "new" drivers with the Older NV cards and OpenCL. Now it seems the New drivers may be having problems with the Old CUDA. Maybe someone should test the New NV drivers against CUDA32...
Strange results with new GPU (GTX 970)

Just got screwed by two errors validating with each other.
http://setiathome.berkeley.edu/workunit.php?wuid=1683786197

And on top of all, that result is now added to the database, as a valid result for the signals in the WU.

I wonder how many millions of invalid results that is now in the database as "real/valid" results?

The Science is compromised by all those crazy computers, filling the database with invalid results, and nobody from the project seems to care one iota about that.

And to add to it all, you haven't even received any toaster from SETI I guess....

Don't worry the instances of bad GPU results validating against themselves to cause a good CPU tasks to be flagged as invalid happens with AP as well.
http://setiathome.berkeley.edu/workunit.php?wuid=1673423338
http://setiathome.berkeley.edu/workunit.php?wuid=1659064648

---

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

Just got screwed by two errors validating with each other.
http://setiathome.berkeley.edu/workunit.php?wuid=1683786197

And on top of all, that result is now added to the database, as a valid result for the signals in the WU.

I wonder how many millions of invalid results that is now in the database as "real/valid" results?

The Science is compromised by all those crazy computers, filling the database with invalid results, and nobody from the project seems to care one iota about that.

And to add to it all, you haven't even received any toaster from SETI I guess....

Don't worry the instances of bad GPU results validating against themselves to cause a good CPU tasks to be flagged as invalid happens with AP as well.
http://setiathome.berkeley.edu/workunit.php?wuid=1673423338
http://setiathome.berkeley.edu/workunit.php?wuid=1659064648

Well, I just checked the Validation inconclusives on my Test Mac and All the recent inconclusives are against nVidia Driver 347.09, http://setiathome.berkeley.edu/results.php?hostid=6796479&offset=0&show_names=0&state=3&appid=11

If these Bad Results start validating against my test App I will Not be a Happy Tester.

Don't worry the instances of bad GPU results validating against themselves to cause a good CPU tasks to be flagged as invalid happens with AP as well.
http://setiathome.berkeley.edu/workunit.php?wuid=1673423338
http://setiathome.berkeley.edu/workunit.php?wuid=1659064648

Well, I just checked the Validation inconclusives on my Test Mac and All the recent inconclusives are against nVidia Driver 347.09, http://setiathome.berkeley.edu/results.php?hostid=6796479&offset=0&show_names=0&state=3&appid=11

If these Bad Results start validating against my test App I will Not be a Happy Tester.

Those two results are with 4 different drivers.

[2] NVIDIA GeForce GTX 980 (4095MB) driver: 347.25
NVIDIA GeForce GTX 750 Ti (2048MB) driver: 344.75 OpenCL: 1.1
[2] NVIDIA GeForce GTX 770 (2048MB) driver: 331.82
NVIDIA GeForce GTX 750 Ti (2048MB) driver: 347.09 OpenCL: 1.1

They all do use 2721 app, but given I have 2 of these vs 11586 valid the percentage is a mere 0.000172622%.

---

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

Here, check them yourself;
http://setiathome.berkeley.edu/results.php?hostid=7461456&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7482925&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7475309&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7475158&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7482622&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=6393856
http://setiathome.berkeley.edu/results.php?hostid=7479310&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7461447&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7369476&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7407076&offset=0&show_names=0&state=3&appid=
http://setiathome.berkeley.edu/results.php?hostid=7482443&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=5726668&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7418120&offset=0&show_names=0&state=5&appid=
http://setiathome.berkeley.edu/results.php?hostid=7297008&offset=0&show_names=0&state=5&appid=
Every CUDA 3.2 task gets trashed, except when good people get robbed...

If we don't get some more datasets loaded into the splitting queue, we shall soon be crunching nothing at all.

Meow.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

If we don't get some more datasets loaded into the splitting queue, we shall soon be crunching nothing at all.

Meow.

We may have to wait for the next shipment to arrive from Arecibo. We already seem to have scraped the bottom of the barrel at least twice since Matt warned us we were Running out of workunits on 13 Nov 2014.

If we don't get some more datasets loaded into the splitting queue, we shall soon be crunching nothing at all.

Meow.

We may have to wait for the next shipment to arrive from Arecibo. We already seem to have scraped the bottom of the barrel at least twice since Matt warned us we were Running out of workunits on 13 Nov 2014.

Hope not, but you could be right.
Meowsigh, and Godspeed the next shipment.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

And export stats hasn't been updated since yesterday.

---

"Please keep Your signature under four lines so Internet traffic doesn't go up too much"

- In 1992 when I had my first e-mail address -

I'm curious to see what the splitters will do when they get to "tape" 24se13ad. My records show that my machines already processed 287 tasks from that file just last March. They were all MB v7 tasks, however. I didn't get any APs from it. Looks like it should be the next "tape" in line, but I think I'll have to wait until morning to see what happens.

By the dawn's early light (well, actually I guess it's past 9 AM already), I see that the 24se13ad "tape" is now marked "(done)" for MB. It appears that at least some splitting was performed on it, because I see 9 files from that tape on my xw9400 this morning. I compared those file names with the 287 that I crunched last March and got the following.

New file names start with:
24se13ad.17323
24se13ad.18692
24se13ad.31616
24se13ad.32457

March, 2014, file names start with:
24se13ad.2405
24se13ad.3136
24se13ad.3682
24se13ad.10026
24se13ad.11409
24se13ad.15412
24se13ad.19064
24se13ad.19944
24se13ad.24015
24se13ad.24710
24se13ad.24872
24se13ad.28197
24se13ad.28860
24se13ad.30999

I guess that means there's no overlap, but I'm not really sure. Does each of those 2nd nodes constitute a "channel", or is that buried deeper in the file names?

And to add to it all, you haven't even received any toaster from SETI I guess....

Fundraising idea. Seti@home can sell these for a good mark-up, with the profits going to the project. Use the same logo as on the t-shirts, maybe without the number.

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

I'm game...where do I sign up??

And export stats hasn't been updated since yesterday.

There are several hours before today's daily stats dump is generated.
http://setiathome.berkeley.edu/stats/
The timestamp is UCB local time or UTC -8.

---

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

...
The Science is compromised by all those crazy computers, filling the database with invalid results, and nobody from the project seems to care one iota about that.
...

Don't worry the instances of bad GPU results validating against themselves to cause a good CPU tasks to be flagged as invalid happens with AP as well.
http://setiathome.berkeley.edu/workunit.php?wuid=1673423338
http://setiathome.berkeley.edu/workunit.php?wuid=1659064648

I wouldn't call those GPU results bad, IMO the WUs simply had signals so close to critical threholding levels that quirks of the AP validator caused the CPU result invalidation.

For wuid=1673423338, the single pulse found by both GPU and CPU processing is well below the 1.01*threshold level so the Validator ignored it. The Rep. pulse found only by the GPUs is probably right at threshold, but I've downloaded the WU and will check that.

For wuid=1659064648, the single pulse found by both CPU and GPU is very close to the 1.01*threshold level (87.85995151 for scale 5). The CPU app was made before we added enough digits to the peak_power field in stderr to be sure its reported peak_power=87.86 is above or below that critical level, but the GPU peak_power=87.8589 is just below so the Validator ignored that GPU signal. The fact that it declared the CPU result invalid indicates its peak_power was actually above the critical level so the Validator was comparing 1 signal from the CPU result to 0 signals from the GPUs.

A proposed change to the AP Validator would have given the wuid=1673423338 CPU result credit on a "weakly similar" basis (and the accompanying "valid" indication). For wuid=1659064648 the initial validation would have come out "strongly similar" and the CPU result would have become canonical. I hope the server issues will subside enough so that change can move up the todo list.

                                                                  Joe

...
The Science is compromised by all those crazy computers, filling the database with invalid results, and nobody from the project seems to care one iota about that.
...

Don't worry the instances of bad GPU results validating against themselves to cause a good CPU tasks to be flagged as invalid happens with AP as well.
http://setiathome.berkeley.edu/workunit.php?wuid=1673423338
http://setiathome.berkeley.edu/workunit.php?wuid=1659064648

I wouldn't call those GPU results bad, IMO the WUs simply had signals so close to critical threholding levels that quirks of the AP validator caused the CPU result invalidation.

For wuid=1673423338, the single pulse found by both GPU and CPU processing is well below the 1.01*threshold level so the Validator ignored it. The Rep. pulse found only by the GPUs is probably right at threshold, but I've downloaded the WU and will check that.

For wuid=1659064648, the single pulse found by both CPU and GPU is very close to the 1.01*threshold level (87.85995151 for scale 5). The CPU app was made before we added enough digits to the peak_power field in stderr to be sure its reported peak_power=87.86 is above or below that critical level, but the GPU peak_power=87.8589 is just below so the Validator ignored that GPU signal. The fact that it declared the CPU result invalid indicates its peak_power was actually above the critical level so the Validator was comparing 1 signal from the CPU result to 0 signals from the GPUs.

A proposed change to the AP Validator would have given the wuid=1673423338 CPU result credit on a "weakly similar" basis (and the accompanying "valid" indication). For wuid=1659064648 the initial validation would have come out "strongly similar" and the CPU result would have become canonical. I hope the server issues will subside enough so that change can move up the todo list.

                                                                  Joe

A threshold issue sound much better than one of the alternatives.
I'm sure they want the server issues to be resolved more than we do.

---

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

Well there goes my 'consecutive valid tasks' count...

Yeah, well, now you're stuck with one of those "guaranteed to fail" MB WUs, too. Join the crowd! :^)

And that WU has moved on to the last person to give it a whirl. So far, the previous stock CPU app has been marked as invalid and mine is now inconclusive, pending the last person's result, which will definitely mark mine as invalid, and probably theirs, as well. Unless they get lucky and get "can't validate" which from past experience, won't reset their consecutive valid count. Lucky them.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

This is going to be interesting. AP assimilators are finally running.

Yay! Hopefully soon, nearly 10TiB of disk space can be reclaimed once those WUs get purged.

And I would have to imagine it would help the database be a bit more responsive and efficient, as well.

We'll see how it goes.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

This is going to be interesting. AP assimilators are finally running.

Some are, some aren't.
None of the AP splitters are running though.

---

Grant
Darwin NT