I've taken down the 'de' searches and started up some 'ps' searches. Let me know if you're having any problems with them.

---

Received 2 ps_separation_17_3s_fix tasks, both reported error after 2 seconds.

ps_separation_17_3s_fix_5_791_0

<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Error reading into stream_max
Error reading into optimize_parameter
Error reading stream_weight for stream 2
10:31:46 (2164): called boinc_finish

I've had 32 ps wu's so far either error out within the 1st 2 secs or hang and keep running with no progress until I abort, all giving the exact error message kashi posted

But now in the last 10 mins they have all completed fine

Just tried eight, six were ps_test_4's, one ps_separation_13_3s_free_2, and one ps_separation_10_3s_fix10_2.

All eight fell over "computation error" around 50% of the way through.

All eight had same error:

<message>
Maximum elapsed time exceeded
</message>
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Using SSE3 path
Found 4 CAL devices
Chose device 0


Regards
Zy

My failed ones are doing this (on all machines):

<core_client_version>6.12.33</core_client_version>
<![CDATA[
<message>
Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4' 
Error reading astronomy parameters from file 'astronomy_parameters.txt'
  Trying old parameters file
Error reading into stream_max
Error reading into optimize_parameter
Error reading stream_weight for stream 2
20:48:00 (1604): called boinc_finish

</stderr_txt>
]]>

One validate error here after runing 163.54 sec.

Coprocessors [2] CAL ATI Radeon HD5800 series (Cypress) (1024MB) driver: 1.4.1332
Operating System Microsoft Windows Vista
Home Premium x64 Edition, Service Pack 2, (06.00.6002.00)
BOINC version 6.10.60


Name ps_test_4_2069995_0
Workunit 41318788
Created 27 Jun 2011 | 18:36:31 UTC
Sent 27 Jun 2011 | 18:40:38 UTC
Received 27 Jun 2011 | 19:09:26 UTC
Server state Over
Outcome Validate error
Client state Done
Exit status 0 (0x0)
Computer ID 59862
Report deadline 9 Jul 2011 | 18:40:38 UTC
Run time 163.54
CPU time 5.23
Validate state Invalid
Credit 0.00
Application version MilkyWay@Home
Anonymous platform (ATI GPU)

And one more here.

Name ps_separation_17_3s_fix_5_197_2
Workunit 41419890
Created 28 Jun 2011 | 4:18:21 UTC
Sent 28 Jun 2011 | 4:21:25 UTC
Received 28 Jun 2011 | 4:33:58 UTC
Server state Over
Outcome Computation error
Client state Compute error
Exit status 1 (0x1)
Computer ID 83808
Report deadline 10 Jul 2011 | 4:21:25 UTC
Run time 1.03
CPU time 0.00
Validate state Invalid
Credit 0.00
Application version MilkyWay@Home
Anonymous platform (ATI GPU)

Stderr output
<core_client_version>6.10.60</core_client_version>
<![CDATA[
<message>
Felaktig funktion. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Error reading into stream_max
Error reading into optimize_parameter
Error reading stream_weight for stream 2
06:32:24 (4940): called boinc_finish

</stderr_txt>
]]>

I also have two ps_17 with errors!

<core_client_version>6.12.28</core_client_version>
<![CDATA[
<message>
Unzul�ssige Funktion. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
Error loading Lua script 'astronomy_parameters.txt': [string "number_parameters: 4..."]:1: '<name>' expected near '4'
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Error reading into stream_max
Error reading into optimize_parameter
Error reading stream_weight for stream 2
07:07:54 (4892): called boinc_finish

---

I've taken down the 'de' searches and started up some 'ps' searches. Let me know if you're having any problems with them.

Hello,

I did not understand what your new research ... ?

---

Team Alliance francophone, boinc: 7.0.18

GA-P55-UD5, i7 860, Win 7 64 bits, 8g DDR3, GTX 470

I've taken down the 'de' searches and started up some 'ps' searches. Let me know if you're having any problems with them.

Hello,

I did not understand what your new research ... ?

Different type of task. Also could be a new search area.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

I've taken down the 'de' searches and started up some 'ps' searches. Let me know if you're having any problems with them.

Hello,

I did not understand what your new research ... ?

the DE workunits are using a different search algorithm on the server end to find the best fit of our models of the Milky Way to the data we've gotten from the SLOAN digital sky survey. DE stands for "differential evolution". PS stands for "particle swarm optimization". What your clients are running is the same, but the method we're using to generate new workunits and find the best fit model is different on the server end of things.

Wikipedia has some good information about particle swarm optimization: http://en.wikipedia.org/wiki/Particle_swarm_optimization

and differential evolution: http://en.wikipedia.org/wiki/Differential_evolution

We've found that these methods give us solutions much quicker than your standard genetic algorithm, which we've used in the past (if anyone remembers workunits starting with gs) : http://en.wikipedia.org/wiki/Genetic_algorithm

---

Hmm.... Wats this?
Sent out to 9 and maked as 'valid' by 6 different computers and sent out again?

http://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=41398880

the ps_separation_17_3s_fix tasks seem to be working just fine for me...

Windows XP Pro SP3 32-bit
AMD Phenom II X6 1090T
4GB (2x2GB) PC12800 (DDR1600)
AMD/ATI HD 5870 2GB GPU
BOINC v 6.12.33

...i also noticed that i'm getting ~320 credits for them, unlike the typical ~167, ~213, and ~267 credits we're used to earning for validated tasks...not that i'm complaining ;-)...i just thought i'd mention it.

---

the ps_separation_17_3s_fix tasks seem to be working just fine for me...

Windows XP Pro SP3 32-bit
AMD Phenom II X6 1090T
4GB (2x2GB) PC12800 (DDR1600)
AMD/ATI HD 5870 2GB GPU
BOINC v 6.12.33

...i also noticed that i'm getting ~320 credits for them, unlike the typical ~167, ~213, and ~267 credits we're used to earning for validated tasks...not that i'm complaining ;-)...i just thought i'd mention it.

But the 17_3s tasks also take longer to complete then the 10_3s or 13_3s, so the credit/sec seems to be roughly the same.

Can the insta-purge be extended to 5 min at least? I couldn't even check a result that I uploaded 5 seconds before and it was gone.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

The ps_separation_13_3s_free_2 WUs seems to be off with their calculation time and credit.
Examples:

Estimated iteration time 126.482975 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 7 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 7 chunk(s) with sizes: 224 224 224 240 224 224 240
Integration time = 105.479807 s, average per iteration = 164.812199 ms
Integral 0 time = 106.684555 s
Likelihood time = 2.163093 s

Credit 159.86


Estimated iteration time 126.482975 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 7 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 7 chunk(s) with sizes: 224 224 224 240 224 224 240
Integration time = 132.754136 s, average per iteration = 207.428338 ms
Integral 0 time = 133.971507 s
Likelihood time = 2.156281 s

Credit 159.86

Estimated iteration time 126.482975 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 7 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 7 chunk(s) with sizes: 224 224 224 240 224 224 240
Integration time = 111.355350 s, average per iteration = 173.992734 ms
Integral 0 time = 112.548719 s
Likelihood time = 2.161938 s

Credit 159.86

Looks like they do far more calculations than what is in the estimate calculation. Credits seem to be in line with the estimate, not with the real run times. If you look at the examples above: Same low estimate, average far higher and even different up to ~25%.

Other WUs vary a little more in tun times than before but estimated to average iteration time looks normal.

The ps_separation_13_3s_free_2 WUs seems to be off with their calculation time and credit.
Examples:

(...)

Are you running more than 1 WU at once? I've noticed when testing my new system, that the "free" WUs are prone to be pushed away by other WUs running together with them, specially by the longer separation_10* WUs (and probably also separation_17, not so much by separation_13*fix*), so yes, they need longer, but the other WU needs less time than it would need if it was running with a non-"free" WU. As long as I was running only 1 WU at once, this didn't occur.

If you look at many WUs which were running after each other (starting and ending with a batch of WUs of the same type, preferably nothing with "free" in it's name), you'll see that the different run time/credit ratios even each other out in the end, at least they did it perfectly on my HD3850.

---

No, only 1 WU at once.
Tried it with 2 but the system got very sluggish again and BM got communication problems. So my choice is to take the few seconds loss and have a responsive system instead.
If the 'initial wait time' fix becomes active with the next app release I will give it another try.

ps_separation_13_3s_free_2 WUs are giving 159.xx credits and show estimated run times according to their credit but do have run times like 213.xx credit WUs.

Usually my WU log looks like this (WU: ps_separation_17_3s_fix_2):

Estimated iteration time 177.678315 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 10 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 10 chunk(s) with sizes: 160 160 160 160 160 160 160 160 160 160
Integration time = 106.226609 s, average per iteration = 165.979076 ms
Integral 0 time = 107.491211 s

(For my 5850 the estimated iteration time is slightly higher than the average iteration time since app v0.82)

ps_separation_13_3s_free_2 WUs underestimate the iteration times by ~30%.
So there is something different with these WU types.

Hmm... strange. For my HD3850 it is

Estimated iteration time 604.259418 ms
Target frequency 200.000000 Hz, polling mode 1
Dividing into 120 chunks, initially sleeping for 0 ms
Warning: Estimated number of chunks (120) too large. Using 100
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 100 chunk(s) with sizes: 16 (...)
Integration time = 946.288779 s, average per iteration = 1478.576218 ms

But they don't error out for me.

---

Up until the ps searches came around, my "statistics" graph was rising on a pretty consistent line, averaging about 800/day. However, since working the PS units, the graph is looking like the EKG of someone about to leave. The graph is now showing an increase of just 2000 in the last 6 days. There also seems be be zero consistency when it comes to the number of processors used, the time it takes to complete a unit, or what order the units are worked.