Akos is at #37 at the moment. He was down below 8000 seconds, then had a run of compute errors, and now he's back to 37000! Probably had to revert to stock to get his quota back up.....
I hope it was only the WUs he trashed, didn't blow a fuse on the box or something.
Those WUs were only "hand-aborted" without any computing problems.
I switched back to the official code because some users were irritated.
Akos is at #37 at the moment. He was down below 8000 seconds, then had a run of compute errors, and now he's back to 37000! Probably had to revert to stock to get his quota back up.....
I hope it was only the WUs he trashed, didn't blow a fuse on the box or something.
Those WUs were only "hand-aborted" without any computing problems.
I switched back to the official code because some users were irritated.
I'm glad the hear it was nothing more drastic than that.
But your switch from 'official' 4.26 to 'official' 4.32 power app has more than halved your run time (from 37Ksec to 17Ksec) - 4.32 is good, but I don't think it's been quite that good for the rest of us.
But your switch from 'official' 4.26 to 'official' 4.32 power app has more than halved your run time (from 37Ksec to 17Ksec) - 4.32 is good, but I don't think it's been quite that good for the rest of us.
Akos, did you perhaps change your clock rate at the same time? A quick comparison to my 3.006 GHz Q6600 running 4.32 suggests your 4.32 results are enough faster to imply a clock rate near 3.28 GHz, which is certainly reachable for most samples of Q6600 on many motherboards with sufficient voltage.
On the other hand, your 4.26 times are far slower than my 3.006 GHz 4.26 times.
Akos, did you perhaps change your clock rate at the same time? A quick comparison to my 3.006 GHz Q6600 running 4.32 suggests your 4.32 results are enough faster to imply a clock rate near 3.28 GHz, which is certainly reachable for most samples of Q6600 on many motherboards with sufficient voltage. On the other hand, your 4.26 times are far slower than my 3.006 GHz 4.26 times.
My Q6600 runs on 2997MHz (9x333), but it was only 1600MHz for some days.
I've uploaded the latest data for the 5 hosts shown below.
1001562 belonging to RH. 997488 belonging to peanut. 1100395 belonging to smoked trout. 1084360 belonging to nivekfalk. 1101980 belonging to RAMA.
For some reason, nivekfalk's host hasn't accumulated any new results for the last 24 hours. I confirmed this by manually browsing his results list as well.
Focussing on the wiggles at the bottom of the curve. Notice how asymmetric they are - I think that follows from, and confirms, Bikeman's theory. Ignore the slowdown for 909.25 between 442 and 471 - that corresponds exactly to the period I was running CPDN on the fourth core. But it's interesting, nonetheless - Peter (archae86) and others have commented that other projects speed up when running alongside Einstein: I think this is the first published evidence of the converse effect, and it's a small one (about 1%).
I've done a new chart for the 4.33 app, and the higher frequency band, only. This is getting towards the peak of his cycle - RR has that at 346.
The Ready Reckoner for all Peanut's data for this 10Hz frequency band (including some in the next cycle, not plotted here) gives
Period of task cycle = 173
Number of points = 199
Minimum runtime in data = 13838
Maximum runtime in data = 16208
Estimated peak runtime = 16353
Estimated average runtime = 14776
Estimated trough runtime = 13876
Estimated runtime variance = 0.151
I'm afraid I can't get anything out of the new data from Smoked Trout, Nivefalk, or Rama that we haven't seen before (except that Rama has become a Power User with 4.35). I'll keep an eye on them, and post any charts which aren't an inconclusive jumble.
Just a small observation: Peanut's file is sorted in the sequence you described to Bikeman: but the three 'first grab' files are unsorted - still seem to be in website order, or some such. Trivial to re-sort them here, but I just thought you'd like to know.
Yes, you are quite right with your observation.
When the data from a new host is collected for the very first time, what's collected becomes the final output with no other processing. When the data for a host is updated, the new items get blended with what has already been saved. Originally, the sorting was to make sure that the same lines of data that were being collected on subsequent runs didn't result in duplicate entries. The 'uniq' utility removes duplicate lines when they are adjacent in a data stream.
With a bit more thought, I had worked out some time ago how to not collect duplicate lines in the first place so the piping of the data through sort and uniq wasn't needed any more. The data was intended to be sent to RR where lines can be entered in any old order.
Obviously, for other processing schemes, and particularly for human readability, sorting of data is probably quite desirable. There's an easy change I can make to the script which will ensure that even first time collections of data are properly sorted in future.
Obviously, for other processing schemes, and particularly for human readability, sorting of data is probably quite desirable. There's an easy change I can make to the script which will ensure that even first time collections of data are properly sorted in future.
Yes please, if it's easy it would be helpful to have them sorted - makes it easy to see which points belong together in a series, and whether the sequence numbers are consecutive (I nearly put in a bug report for 'failure to make due progress' over the weekend, but just in time spotted that the scheduler had slipped in a _575 between _506 and _516 - added 10Ksec to the runtime!).
Beautiful graphs!!
The wiggles seem to have a max amplitude at phase approx 0.3 and 0.7.
The declination of the skypoints at those phases should be about
arcsin(2 * phase -1) ~ +/-22 degrees
... matching the tilting of the ecliptic plane against the equatorial plane of the coordinate system. Yes, theory and observation match very well indeed.
RE: Akos is at #37 at the
)
Those WUs were only "hand-aborted" without any computing problems.
I switched back to the official code because some users were irritated.
RE: RE: Akos is at #37 at
)
I'm glad the hear it was nothing more drastic than that.
But your switch from 'official' 4.26 to 'official' 4.32 power app has more than halved your run time (from 37Ksec to 17Ksec) - 4.32 is good, but I don't think it's been quite that good for the rest of us.
Any tips?
RE: I switched back to the
)
OK,,,,Now I'm irritated that you've switched to the official code.....LOL
Time to switch back....LOL
RE: But your switch from
)
Akos, did you perhaps change your clock rate at the same time? A quick comparison to my 3.006 GHz Q6600 running 4.32 suggests your 4.32 results are enough faster to imply a clock rate near 3.28 GHz, which is certainly reachable for most samples of Q6600 on many motherboards with sufficient voltage.
On the other hand, your 4.26 times are far slower than my 3.006 GHz 4.26 times.
RE: Akos, did you perhaps
)
My Q6600 runs on 2997MHz (9x333), but it was only 1600MHz for some days.
I've uploaded the latest data
)
I've uploaded the latest data for the 5 hosts shown below.
1001562 belonging to RH.
997488 belonging to peanut.
1100395 belonging to smoked trout.
1084360 belonging to nivekfalk.
1101980 belonging to RAMA.
For some reason, nivekfalk's host hasn't accumulated any new results for the last 24 hours. I confirmed this by manually browsing his results list as well.
Please report any errors or problems here.
Cheers,
Gary.
RE: I've uploaded the
)
Here are a couple of graphs from Gary's data:
RH -
(direct link)
Focussing on the wiggles at the bottom of the curve. Notice how asymmetric they are - I think that follows from, and confirms, Bikeman's theory. Ignore the slowdown for 909.25 between 442 and 471 - that corresponds exactly to the period I was running CPDN on the fourth core. But it's interesting, nonetheless - Peter (archae86) and others have commented that other projects speed up when running alongside Einstein: I think this is the first published evidence of the converse effect, and it's a small one (about 1%).
Peanut -
(direct link)
I've done a new chart for the 4.33 app, and the higher frequency band, only. This is getting towards the peak of his cycle - RR has that at 346.
The Ready Reckoner for all Peanut's data for this 10Hz frequency band (including some in the next cycle, not plotted here) gives
I'm afraid I can't get anything out of the new data from Smoked Trout, Nivefalk, or Rama that we haven't seen before (except that Rama has become a Power User with 4.35). I'll keep an eye on them, and post any charts which aren't an inconclusive jumble.
RE: Just a small
)
Yes, you are quite right with your observation.
When the data from a new host is collected for the very first time, what's collected becomes the final output with no other processing. When the data for a host is updated, the new items get blended with what has already been saved. Originally, the sorting was to make sure that the same lines of data that were being collected on subsequent runs didn't result in duplicate entries. The 'uniq' utility removes duplicate lines when they are adjacent in a data stream.
With a bit more thought, I had worked out some time ago how to not collect duplicate lines in the first place so the piping of the data through sort and uniq wasn't needed any more. The data was intended to be sent to RR where lines can be entered in any old order.
Obviously, for other processing schemes, and particularly for human readability, sorting of data is probably quite desirable. There's an easy change I can make to the script which will ensure that even first time collections of data are properly sorted in future.
Thanks for the report.
Cheers,
Gary.
RE: Obviously, for other
)
Yes please, if it's easy it would be helpful to have them sorted - makes it easy to see which points belong together in a series, and whether the sequence numbers are consecutive (I nearly put in a bug report for 'failure to make due progress' over the weekend, but just in time spotted that the scheduler had slipped in a _575 between _506 and _516 - added 10Ksec to the runtime!).
Hi! RE: RH
)
Hi!
Beautiful graphs!!
The wiggles seem to have a max amplitude at phase approx 0.3 and 0.7.
The declination of the skypoints at those phases should be about
arcsin(2 * phase -1) ~ +/-22 degrees
... matching the tilting of the ecliptic plane against the equatorial plane of the coordinate system. Yes, theory and observation match very well indeed.
CU
Bikeman