Ok, so the coincidence between runtime cycle and the traversal of the sky sphere from pole to pole is strongly suggesting that the main influence on runtime is determined by the set of sky points that are analyzed in the workunit.
The general idea is that runtime is probably greatest at the poles and smallest on the equator, so runtime would only depend on the "declination" sky coordinate.
This hypothesis would lead to the smooth sine- or quadratic-curve like graphs that we see in the ReadyReckoner. There would be no wiggles in the runtime data.
But the wiggles are not random, and coincide for different WUs that have similar frequencies and probably use the same sky-grid file.
So...let's check the exact relation between runtime and sky-positions.
Here's an experiment I conducted. I made up my own skygrid:
and executed the app for every single sky-position independently.
The following diagram shows the runtime per sky point as color code: red means slow, blue means fast.
The result is: our basic working hypothesis is almost right: runtime appears to increase near the poles and is considerably smaller near the equator.
But the data suggests there are two systematic errors in our hypothesis that the speed - skyposition relation is depending on declination only.
1) The two local runtime maxima are not exactly at the poles. The whole runtime "field" seems to be tilted about 20 degrees. Actually the "runtime poles" seem to coincide with the ecliptic poles (the ecliptic plane is tilted about 23 degrees against the RA/Dec coordinate system)
2) the points of minimum runtime do not form a grand circle as you would expect. There are two very distinct runtime minima which are better visible in a 3D scatter plot where declination and right ascension are on the x/y axis and runtime is on the z Axis:
I discussed this with Bernd and the sky points of the local runtime minima seem to have an astronomical meaning: if I understood this right they mark the intersection of the ecliptic plane with the mean velocity vector of the Earth during the S5R3 data acquisition time window...eeehhh...well....whatever, I don't claim to understand this fully :-).
What has this to do with the wiggles?
OK, the nearer we get to the equator (and the higher the frequency is, btw), the narrower will be the band of sky-points covered by a workunit
So the closer we get to the equator, (=runtime trough), the more sensitive the runtime gets to the two systematic errors mentioned above. While the first effect (tilting of "runtime field" by 23 degrees) averages out pretty much as we complete a full circle within a workunit, the second effect (two runtime minima offset from the equator) will cause wiggles in the runtime, because the runtime is not just depending on declination.
I guess this explains several things that we observe wrt. the wiggles:
1) they are more pronounced near the runtime trough.
2) they are identical for WU that seem to use the same skygrid. Runtime depends on sky points, so identical "phase" units for the same skygrid should produce the same runtime
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.
All the "Compute Errors" I saw on that host were actually "User aborted" errors, so I guess Akos switched back to the stock app after aborting ongoing workunits, for whatever reasons.
so the coincidence between runtime cycle and the traversal of the sky sphere from pole to pole ....
Absolutely fascinating! :-)
Bikeman, your are the man ... :-)
It'll take me a little while to digest this, but I think you have it right - or as right as one can be from this end of the reverse engineering pipe.
Ptolemy and Copernicus would be proud of you!
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I've uploaded the latest data for a total of 5 hosts now. At Richard's suggestion I've included the smoked trout host and two others belonging to nivekfalk and RAMA respectively. I chose the latter two on the basis of speed and lots of data. It seems that almost every time we look at a bunch of data we find interesting stuff anyway. Quite often it's not at all what we were looking for or even half expecting. Isn't that how real science goes most of the time :).
1001562 belonging to RH. 997488 belonging to peanut. 1100395 belonging to smoked trout. 1084360 belonging to nivekfalk. 1101980 belonging to RAMA.
With the three new "from scratch" files included, it took about 15 minutes to get all the data. The RH update took 15 seconds and the peanut update took 70 seconds. I was interested to see that grabbing the update takes a lot less than getting the full list from scratch.
I haven't looked at any of the data. I'm sure someone will let me know if anything is wrong :).
Please report any errors or problems here.
EDIT:
I thought I'd better at least look at the data for the new hosts - just in case ... :). At a quick glance it seems fine. Of the three, the host belonging to RAMA is the only one using beta/power user apps. He is using 4.27 and there is still one "mixed" result showing. The other two are using "official" apps with a transition in evidence but no "mixed" results. ie the transition occurred "officially" and not in mid-stream using the anonymous platform mechanism.
It doesn't feel "quite right" spying on someone else's results :).
Hmm, why does peanut's list show only 4.22 version results, he's using 4.33 for some time now, right?
There are both 4.22 and 4.33 results in there. The 4.33 results are at the end of the file. The data is sorted on frequency and sequence number - ascending order. His machine is moving up in frequency as it crunches so the latest 4.33 results will be close to the bottom of the file.
I think it's pretty clear that the 'wiggle phase' for 869.80 matches the frequencies below it: and from Peanut's chart, 909.90 belongs with the frequencies above it. Interestingly, neither host was allocated any work for exactly xxx.85, though they've both got every other x.x5 increment around that area.
Not sure what to make of this one. I've checked I've pasted the data into the right slots in my template (in case you haven't guessed, ignore the legends with lots of zeros - I'm into recycling here). Maybe there are some discontinuities at x.85 other than xx9.85?
1001562 belonging to RH. 997488 belonging to peanut. 1100395 belonging to smoked trout. 1084360 belonging to nivekfalk. 1101980 belonging to RAMA.
I haven't looked at any of the data. I'm sure someone will let me know if anything is wrong :).
Please report any errors or problems here.
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.
...continued Ok, so the
)
...continued
Ok, so the coincidence between runtime cycle and the traversal of the sky sphere from pole to pole is strongly suggesting that the main influence on runtime is determined by the set of sky points that are analyzed in the workunit.
The general idea is that runtime is probably greatest at the poles and smallest on the equator, so runtime would only depend on the "declination" sky coordinate.
This hypothesis would lead to the smooth sine- or quadratic-curve like graphs that we see in the ReadyReckoner. There would be no wiggles in the runtime data.
But the wiggles are not random, and coincide for different WUs that have similar frequencies and probably use the same sky-grid file.
So...let's check the exact relation between runtime and sky-positions.
Here's an experiment I conducted. I made up my own skygrid:
and executed the app for every single sky-position independently.
The following diagram shows the runtime per sky point as color code: red means slow, blue means fast.
The result is: our basic working hypothesis is almost right: runtime appears to increase near the poles and is considerably smaller near the equator.
But the data suggests there are two systematic errors in our hypothesis that the speed - skyposition relation is depending on declination only.
1) The two local runtime maxima are not exactly at the poles. The whole runtime "field" seems to be tilted about 20 degrees. Actually the "runtime poles" seem to coincide with the ecliptic poles (the ecliptic plane is tilted about 23 degrees against the RA/Dec coordinate system)
2) the points of minimum runtime do not form a grand circle as you would expect. There are two very distinct runtime minima which are better visible in a 3D scatter plot where declination and right ascension are on the x/y axis and runtime is on the z Axis:
I discussed this with Bernd and the sky points of the local runtime minima seem to have an astronomical meaning: if I understood this right they mark the intersection of the ecliptic plane with the mean velocity vector of the Earth during the S5R3 data acquisition time window...eeehhh...well....whatever, I don't claim to understand this fully :-).
What has this to do with the wiggles?
OK, the nearer we get to the equator (and the higher the frequency is, btw), the narrower will be the band of sky-points covered by a workunit
So the closer we get to the equator, (=runtime trough), the more sensitive the runtime gets to the two systematic errors mentioned above. While the first effect (tilting of "runtime field" by 23 degrees) averages out pretty much as we complete a full circle within a workunit, the second effect (two runtime minima offset from the equator) will cause wiggles in the runtime, because the runtime is not just depending on declination.
I guess this explains several things that we observe wrt. the wiggles:
1) they are more pronounced near the runtime trough.
2) they are identical for WU that seem to use the same skygrid. Runtime depends on sky points, so identical "phase" units for the same skygrid should produce the same runtime
CU
Bikeman
RE: Akos is at #37 at the
)
All the "Compute Errors" I saw on that host were actually "User aborted" errors, so I guess Akos switched back to the stock app after aborting ongoing workunits, for whatever reasons.
CU
Bikeman
RE: so the coincidence
)
Absolutely fascinating! :-)
Bikeman, your are the man ... :-)
It'll take me a little while to digest this, but I think you have it right - or as right as one can be from this end of the reverse engineering pipe.
Ptolemy and Copernicus would be proud of you!
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
I've uploaded the latest data
)
I've uploaded the latest data for a total of 5 hosts now. At Richard's suggestion I've included the smoked trout host and two others belonging to nivekfalk and RAMA respectively. I chose the latter two on the basis of speed and lots of data. It seems that almost every time we look at a bunch of data we find interesting stuff anyway. Quite often it's not at all what we were looking for or even half expecting. Isn't that how real science goes most of the time :).
1001562 belonging to RH.
997488 belonging to peanut.
1100395 belonging to smoked trout.
1084360 belonging to nivekfalk.
1101980 belonging to RAMA.
With the three new "from scratch" files included, it took about 15 minutes to get all the data. The RH update took 15 seconds and the peanut update took 70 seconds. I was interested to see that grabbing the update takes a lot less than getting the full list from scratch.
I haven't looked at any of the data. I'm sure someone will let me know if anything is wrong :).
Please report any errors or problems here.
EDIT:
I thought I'd better at least look at the data for the new hosts - just in case ... :). At a quick glance it seems fine. Of the three, the host belonging to RAMA is the only one using beta/power user apps. He is using 4.27 and there is still one "mixed" result showing. The other two are using "official" apps with a transition in evidence but no "mixed" results. ie the transition occurred "officially" and not in mid-stream using the anonymous platform mechanism.
It doesn't feel "quite right" spying on someone else's results :).
Cheers,
Gary.
Hi! Hmm, why does peanut's
)
Hi!
Hmm, why does peanut's list show only 4.22 version results, he's using 4.33 for some time now, right?
CU
Bikeman
RE: Hmm, why does peanut's
)
There are both 4.22 and 4.33 results in there. The 4.33 results are at the end of the file. The data is sorted on frequency and sequence number - ascending order. His machine is moving up in frequency as it crunches so the latest 4.33 results will be close to the bottom of the file.
Cheers,
Gary.
Here's Smoked Trout's chart.
)
Here's Smoked Trout's chart. Not as pretty as Peanut's, but quite useful.
(direct link)
I think it's pretty clear that the 'wiggle phase' for 869.80 matches the frequencies below it: and from Peanut's chart, 909.90 belongs with the frequencies above it. Interestingly, neither host was allocated any work for exactly xxx.85, though they've both got every other x.x5 increment around that area.
And here's Nivekfalk's:
(direct link)
Hey, I'm getting the hang of this!
And here's Rama's:
(direct link)
Not sure what to make of this one. I've checked I've pasted the data into the right slots in my template (in case you haven't guessed, ignore the legends with lots of zeros - I'm into recycling here). Maybe there are some discontinuities at x.85 other than xx9.85?
RE: 1001562 belonging to
)
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.
My C2D notebook is just going
)
My C2D notebook is just going thru a skygrid change, so I can add one data-point:
Workunit:
h1_0889.80_S5R3__409_S5R3b
command line in client_state.xml
... --Freq=889.996000372 ... --skyGridFile=skygrid_0890Hz_S5R3.dat ...
Workunit:
h1_0889.85_S5R3__426_S5R3b
command line in client_state.xml:
... --Freq=890.044419996 ... --skyGridFile=skygrid_0900Hz_S5R3.dat ...
CU
Bikeman
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.
Please report any errors or problems here.
Cheers,
Gary.