Shouldn’t one be able to trick the scheduler to give you tasks from higher frequencies?
Not much, I think. The process only generates work enough in advance to allow reasonably smooth filling of requests.
The server status page shows 12,104,080 total for S5R4, of which only 46,674 currently show as unsent (meaning, I think, generated but not sent out).
So, pretty much, "what you see is what you get". Unless something is different this time than last, it will be many, many weeks before we get work up at the frequencies that make the wiggles stand out with lots of repetitions.
So quite right Peter it's the declination/Hough/memory-bound component. And hence it would be interesting to compare on Richard's box at the ~ same frequency. That is assess the effect ( if any ) due to change in the Hough code, now weighted, in R4 v R3.
So no subsequent change in the memory specs for that box Richard?
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
So no subsequent change in the memory specs for that box Richard?
No, no hardware changes at all.
Only difference from last run is upgrade from XP SP2 to SP3, and relocate BOINC folder tree from system drive to data drive. I'm sticking with BOINC v5.10.13 for as long as possible.
Here's the first graph. With a bit of help from 256.60, we've got pretty much a full cycle:
While I had a long wait while burning down large S5R3 queues, I now have a Q6600 and an E6600 running some sequential sequences in frequencies 182.90, 291.65, and, a week or two from now, 401.45
I'll not post pictures until I have somewhat more, but the 182.90 and 291.65 sets already have plenty of data to affirm something I should have noticed in Richard Haselgrove's 265.nn set: the period is longer for a given frequency in S5R4 than in S5R3.
It remains to be seen whether the quadratic relationship between frequency and period which was such a tight fit on S5R3 holds, but with a new constant.
However, for Ready Reckoner use, the constant there termed D, or sky grid density constant, is not even close to the .000206 that gave close matching over a broad range of S5R3 frequencies.
A (very) rough first estimate that may be close if the quadratic relation still holds is .000235. This is mostly estimated from a sequence of frequency 291.65 that seems pretty clearly to have passed a local minimum about sequence number 69 or 70. It would be pretty to say this is matched in Richard's data, but unfortunately that at first glance appears to want an even higher sky grid density constant.
We'll need a broader range of frequencies to recheck the quadratic relation by observation, and we'll need more data at substantially higher sequence numbers than the first couple of dozen to get a useful fix on the right value.
As to variability, I've already seen 17% max above min, but that is, again, a rough estimate for the moment.
Remember that there is also a direct way to estimate the period for a give frequency rage: count the lines in the skygrid-file and divide by the number of skypoints in a typical workunit of that frequency range. The period measures how many workunits it takes to cover one full sweep of the sky.
The constants in S5R3 assumed ca 1200 skypoints per WU, which is no longer true (I've seen numbers in the 700s and 800s so far). The quadratic growth of the skygrid size itself is dictated by a need to get a uniform sensitivity across frequencies, so the quadratic growth of the period should still hold only if number of skypoints per WU remains rather constant.
I seem to see a decrease in what I will call "wavelength". I am seeing many more peaks now than previously in S5R3. Just had to throw in my 2 cents in on the subject. My data is not really sorted in any way. I just plot it as I fetch it. Something like date and time of completion roughly.
Remember that there is also a direct way to estimate the period for a give frequency rage: count the lines in the skygrid-file and divide by the number of skypoints in a typical workunit of that frequency range.
OK, for the 300Hz S5R4 skygrid I see 22119 lines (note to others wanting to look at this, while the file carries a .dat extension, it is actually a ZIP-type compressed file--renaming it to .zip makes it easier to decompress with e.g. WinRAR).
As to skypoints, for all currently available sequence numbers in frequency 291.65, I see 819:
including:
77 to 79 and all of 65 through 72, all report 819 skypoints.
This gives a period estimate of 27 by your suggested method. That differs dramatically from the period estimate of 17.5 using the old "curve-fit to S5R3" values in the quadratic. My attempted new fit assumed I was at the 3.5th cycle for the minimum at 69 or so. That would mean a cycle of about 20. Your method suggests that the minimum at 69 is more likely the 2.5th cycle. I should have enough points to confirm that distinction pretty soon.
Assuming 2.5th proves in, then a new provisional second guess (I already used up my first guess) for a value of D as the sky grid density constant in Ready Reckoner terminology is .000325 (was .000206 for S5R3).
I'll check these against the rather more adequate data available from my hosts tomorrow and cross-check for fit with Richard's report.
My recollection is that my fit using your method on this quadratic was not quite ideal on S5R3, possibly because of offsets in labeling vs. skygrid file use or the like, but the agreement was very close. With your insight into the program, you have probably steered me away from major error a day or two earlier than I'd have without the prod. Thanks.
Richard,
Without doing anything, (not installed latest MS update, yet), I can now see the thumbnails and use the links.
Andy
edit] uptime since last reboot 29+ days.
Did you change anything to do with popup blocking or any other ad-block software? The links had always worked for me, although one of the two methods will want to pop up an ad...
RE: Shouldn’t one be able
)
Not much, I think. The process only generates work enough in advance to allow reasonably smooth filling of requests.
The server status page shows 12,104,080 total for S5R4, of which only 46,674 currently show as unsent (meaning, I think, generated but not sent out).
So, pretty much, "what you see is what you get". Unless something is different this time than last, it will be many, many weeks before we get work up at the frequencies that make the wiggles stand out with lots of repetitions.
RE: Shouldn’t one be able
)
Yes, that would be nice :-)
( Like reservations in a DHCP pool )
Found Bernd's comment here.
So quite right Peter it's the declination/Hough/memory-bound component. And hence it would be interesting to compare on Richard's box at the ~ same frequency. That is assess the effect ( if any ) due to change in the Hough code, now weighted, in R4 v R3.
So no subsequent change in the memory specs for that box Richard?
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
RE: So no subsequent change
)
No, no hardware changes at all.
Only difference from last run is upgrade from XP SP2 to SP3, and relocate BOINC folder tree from system drive to data drive. I'm sticking with BOINC v5.10.13 for as long as possible.
RE: Here's the first graph.
)
While I had a long wait while burning down large S5R3 queues, I now have a Q6600 and an E6600 running some sequential sequences in frequencies 182.90, 291.65, and, a week or two from now, 401.45
I'll not post pictures until I have somewhat more, but the 182.90 and 291.65 sets already have plenty of data to affirm something I should have noticed in Richard Haselgrove's 265.nn set: the period is longer for a given frequency in S5R4 than in S5R3.
It remains to be seen whether the quadratic relationship between frequency and period which was such a tight fit on S5R3 holds, but with a new constant.
However, for Ready Reckoner use, the constant there termed D, or sky grid density constant, is not even close to the .000206 that gave close matching over a broad range of S5R3 frequencies.
A (very) rough first estimate that may be close if the quadratic relation still holds is .000235. This is mostly estimated from a sequence of frequency 291.65 that seems pretty clearly to have passed a local minimum about sequence number 69 or 70. It would be pretty to say this is matched in Richard's data, but unfortunately that at first glance appears to want an even higher sky grid density constant.
We'll need a broader range of frequencies to recheck the quadratic relation by observation, and we'll need more data at substantially higher sequence numbers than the first couple of dozen to get a useful fix on the right value.
As to variability, I've already seen 17% max above min, but that is, again, a rough estimate for the moment.
Hi! Remember that there is
)
Hi!
Remember that there is also a direct way to estimate the period for a give frequency rage: count the lines in the skygrid-file and divide by the number of skypoints in a typical workunit of that frequency range. The period measures how many workunits it takes to cover one full sweep of the sky.
The constants in S5R3 assumed ca 1200 skypoints per WU, which is no longer true (I've seen numbers in the 700s and 800s so far). The quadratic growth of the skygrid size itself is dictated by a need to get a uniform sensitivity across frequencies, so the quadratic growth of the period should still hold only if number of skypoints per WU remains rather constant.
Bikeman
I seem to see a decrease in
)
I seem to see a decrease in what I will call "wavelength". I am seeing many more peaks now than previously in S5R3. Just had to throw in my 2 cents in on the subject. My data is not really sorted in any way. I just plot it as I fetch it. Something like date and time of completion roughly.
bigger image
RE: Remember that there is
)
OK, for the 300Hz S5R4 skygrid I see 22119 lines (note to others wanting to look at this, while the file carries a .dat extension, it is actually a ZIP-type compressed file--renaming it to .zip makes it easier to decompress with e.g. WinRAR).
As to skypoints, for all currently available sequence numbers in frequency 291.65, I see 819:
including:
77 to 79 and all of 65 through 72, all report 819 skypoints.
This gives a period estimate of 27 by your suggested method. That differs dramatically from the period estimate of 17.5 using the old "curve-fit to S5R3" values in the quadratic. My attempted new fit assumed I was at the 3.5th cycle for the minimum at 69 or so. That would mean a cycle of about 20. Your method suggests that the minimum at 69 is more likely the 2.5th cycle. I should have enough points to confirm that distinction pretty soon.
Assuming 2.5th proves in, then a new provisional second guess (I already used up my first guess) for a value of D as the sky grid density constant in Ready Reckoner terminology is .000325 (was .000206 for S5R3).
I'll check these against the rather more adequate data available from my hosts tomorrow and cross-check for fit with Richard's report.
My recollection is that my fit using your method on this quadratic was not quite ideal on S5R3, possibly because of offsets in labeling vs. skygrid file use or the like, but the agreement was very close. With your insight into the program, you have probably steered me away from major error a day or two earlier than I'd have without the prod. Thanks.
The scheduler hasn't been
)
The scheduler hasn't been kind - I got __50 to __33 from 304.70, but then it shifted me up to the next frequency.
(direct link)
Hope that gives you enough to start some curve-fitting! 844 skypoints, 223.12 credits.
RR data:
Richard, Without doing
)
Richard,
Without doing anything, (not installed latest MS update, yet), I can now see the thumbnails and use the links.
Andy
edit] uptime since last reboot 29+ days.
RE: Richard, Without doing
)
Did you change anything to do with popup blocking or any other ad-block software? The links had always worked for me, although one of the two methods will want to pop up an ad...