Hi,

I was just looking through some of my previous results uploaded to S@H and noticed the following result

My computer is here

I cannot figure out why I have been given zero credit for this WU, especially when the other 2 results returned have been credited, where the quorum is 3 results. Furthermore, the claimed credit is the same for all results returned.

Note that I have not experienced this on other WU's, and I am running Chicken of Angnor's optimised client for Core 2 Duos (X6800 in this instance).

Any ideas?

---

Hi,

I was just looking through some of my previous results uploaded to S@H and noticed the following result

My computer is here

I cannot figure out why I have been given zero credit for this WU, especially when the other 2 results returned have been credited, where the quorum is 3 results. Furthermore, the claimed credit is the same for all results returned.

Note that I have not experienced this on other WU's, and I am running Chicken of Angnor's optimised client for Core 2 Duos (X6800 in this instance).

Any ideas?

I use the same optimised application - specifically v1.41 for Core 2.

Every once in a while, I see the same 0.00 credit for a validation failure. I think there's a small bug in the application which just occasionally produces a bad result. But I keep using it, because the overall speed increase more than makes up for these very few and rare errors.

Simon has said that there should be a new and even faster version released in the next few days - it's worth keeping your eye on the 'optimised applications' sticky thread at the top of this board for any new announcements.

Thank you Richard.

I entirely agree that if these extremely rare errors are due to a coding error, they more than offset by the increase in the number of WU's crunched in a given time by Simon's optimised client.

---

Thank you Richard.

I entirely agree that if these extremely rare errors are due to a coding error, they more than offset by the increase in the number of WU's crunched in a given time by Simon's optimised client.

It depends on how you define a coding error. The 1.41 code has two sections which were hand optimized. One affects Pulse finding and makes no difference other than the speed improvement. The other is for Chirping and in part trades off accuracy for speed by using floats (4 bytes) rather than doubles (8 bytes).

The code as written would easily pass the accuracy test which Eric Korpela has included in the 5.17 code base. But it does have effects on results:

1. The validator allows up to a 1% difference between results for reported signal levels. The 1.41 code will usually be better than that, but perhaps not at high Chirp rates and toward the end of the 107.34 second duration of a WU.

2. The decision on whether a signal is good enough to report is made in the application, and cannot have a tolerance. For signals near the threshold, the 1.41 code may report a signal where the stock app doesn't, or vice versa.

3. The result file includes "best of" signal reports which are also checked by the validator. Again, minor differences could cause 1.41 to judge differently which of two signals is best.

The 1.41 code is not my work, in fact I hadn't really examined it until recently because I don't have an SSE3 capable system. But I did make an experimental SSE Chirp routine which also uses floats for all calculations. It's quick, but whether it will ever be used in an optimized release is still being discussed. Deciding how to measure accuracy is a real puzzle, the output from Chirping goes through FFT and conversion to a PowerSpectrum before signal analysis; all those later stages use floats rather than doubles. I think in the final analysis the 1% tolerance in the validator has to be the yardstick.

                                                                Joe