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...
Not that I can remember, looking at pop-up blocker, all temps are removed, and I can still see them.
Got a chance to set up an x64 'Longhorn' server yesterday. Guy who will be managing it locally called in sick today, so I offered to do some burn-in testing - guess what with!
Got issued, somewhat to my surprise, with WUs 0739.10_S5R4__479 and downwards. We don't usually get data so far up the frequency space this early in the run. Keep an eye on it, if you want to check theories about cycle length. (but NB it probably won't be available for long-term crunching - I'll try and keep it up until early next week, but no promises.)
Got a chance to set up an x64 'Longhorn' server yesterday.
Interesting. The work generation does seem to be behaving differently on this run.
At a preliminary guess, the cycle length for 739.10 frequency may be about 177. If so your samples will be most helpful in refining the estimate if they continue a way past the estimated minimum near 444. From that point of view, I'd be happy if the units issued you had some holes, the better to step down past the minimum.
However, this host/frequency may actually be even more useful for a look at the wiggles. The cycle length may be long enough to get a good first look. From that point of view sequential observations at a single frequency would be best.
Got a chance to set up an x64 'Longhorn' server yesterday. Guy who will be managing it locally called in sick today, so I offered to do some burn-in testing - guess what with!
Got issued, somewhat to my surprise, with WUs 0739.10_S5R4__479 and downwards. We don't usually get data so far up the frequency space this early in the run. Keep an eye on it, if you want to check theories about cycle length. (but NB it probably won't be available for long-term crunching - I'll try and keep it up until early next week, but no promises.)
So far the work issue seems not inclined to give you long sequence runs on the Longhorn host. Time will tell whether we get useful cycle learning from the execution. I was just convinced that it would just keep bumping up to higher frequencies while keeping very near sequence number 477 when I noticed two near 638--maybe there is hope for seeing a peak or valley yet.
If it is convenient for you unzip and get the line count of the skygrid file
(presumably skygrid_0740Hz_S5R4.dat), or just mail it to me, that would provide another point of the curve of cycle length vs. frequency by the Bikeman method. The highest skygrid file I have is the 440Hz one.
If it is convenient for you unzip and get the line count of the skygrid file (presumably skygrid_0740Hz_S5R4.dat), or just mail it to me, that would provide another point of the curve of cycle length vs. frequency by the Bikeman method. The highest skygrid file I have is the 440Hz one.
Luckily, one of the first things I do when setting up a new server is to get the remote control working!
Yes, the server has skygrid_0740Hz_S5R4.dat, and I have a copy at home now. Linecount 134,316, size zipped 927,203 bytes, size unzipped 4,432,428 bytes (as a sanity check on the linecount - they look like fixed-length lines of 32 bytes). Let me know if you want me to email the whole file.
PS - Didn't take me long fishing around in the download directory structure of my local mirror to find the same data for skygrid_1080Hz_S5R4:
Yes, the server has skygrid_0740Hz_S5R4.dat, and I have a copy at home now. Linecount 134,316, size zipped 927,203 bytes, size unzipped 4,432,428 bytes (as a sanity check on the linecount - they look like fixed-length lines of 32 bytes). Let me know if you want me to email the whole file.
PS - Didn't take me long fishing around in the download directory structure of my local mirror to find the same data for skygrid_1080Hz_S5R4:
I can't use the Bikeman method on your 1080 Hz result without a skypoint count, which so far as I know we need task execution to get, though most we have seen so far in the low 800's they may be climbing with frequency.
But for 739.2 Hz we have both components and Bikeman's method forecasts a cycle length of 160. This is bad news for the quadratic model or for my tidiness, as my rough sky grid density constant fit of .000325 would make it 177--well outside the error limits of simple noise in my lower frequency observations. Maybe I just botched something--I'll look again in a day or two. For the moment it appears to me that the Bikeman method is, for some reason, not quite matching the reality but is very close, and that the simple quadratic model's "constant" needs a steady decreasing value (so far from about .000325 to about .0003) with increasing frequency to fit the data. All preliminary, at the moment.
If it is convenient for you unzip and get the line count of the skygrid file
(presumably skygrid_0740Hz_S5R4.dat), or just mail it to me, that would provide another point of the curve of cycle length vs. frequency by the Bikeman method. The highest skygrid file I have is the 440Hz one.
If it helps at all, the R4 skygrids seem to have the exact same number of lines as their R3 counterparts (at least for the small number I checked). I have about 50 different skygrids saved now up to close to 1100Hz. I also have tasks on many hosts to go with these. If I get some time I'll make a 3 column table of freq, #lines, and #skypoints for as many as possible before the tedium of doing it gets to me :-).
If it helps at all, the R4 skygrids seem to have the exact same number of lines as their R3 counterparts (at least for the small number I checked). I have about 50 different skygrids saved now up to close to 1100Hz. I also have tasks on many hosts to go with these. If I get some time I'll make a 3 column table of freq, #lines, and #skypoints for as many as possible before the tedium of doing it gets to me :-).
Thanks, upon your note I checked the couple of skygrids that I have in both flavors, and they were exact matches also.
My vague impression is that the pattern of skypoint variation may differ some--of course the typical value for number of skypoints has shifted down quite a bit.
At the moment, my most fond wish would be several different frequencies with sufficient sequence numbers out in the third or fourth cycle to define the cycle length pretty accurately. This works better on hosts with little task-to-task random variation, which probably means in turn good memory performance (so variation in contention causes less noise), and with few non-Einstein cycles (again to reduce variation noise). Fully sequential data for a quarter-cycle near the minimum would be nifty for those with an interest in the "wiggles", but otherwise one just needs sequential samples on both sides of the maximum (to define both position and height, and a good enough sampled set around the minimum to define its depth well.
My Q6600, which does not have especially fast memory and does have some competing applications (I'm typing on it now), seems noticeably noisier than my E6600, which fortunately has just now gotten stocked up with sequence numbers 143 to 93 of frequency 401.45 with only about four missing counts. However that will take well over a week to complete if I let them all run undisturbed.
I don't expect to have much new in terms of final model to offer for a while. In the meantime I welcome any data posting, especially data or interpretation which runs counter to anything I've said.
I think we have a reasonable max/min span for the new frequency band (37963.89 - 32501.38), and an interpolated cycle length of between 27.5 and 28.0
I can't explain the extended run times for 304.75__44 and __45 - I don't remember doing anything on the machine that would interfere, but that's what it looks like.
Work allocation coming up is even spottier, and I've also got 8 (so far) S5R3 resends. So I'll just let them work through at their own pace, and hope that the faster work request rate as the DCF adjusts will get us a more complete set in the next frequency band it sends me.
I'll post three sequences from two hosts. Both are Conroe-class running on the same motherboard at 2.79 GHz, but as one is a quad and one a duo and they don't have the same environment of other tasks, I've separated them.
Stoll3 is the duo (E6600) and gets less usage for non-BOINC things, so can be expected to have less random variation in runtimes. The 182.90 sequence provides a rough cycle time estimate between 10 and 11. The 401.45 sequence provides a cycle time estimate of about 49, seems to have some odd variations in the upper 120s, and appears to require more CPU time at cycle minimum and maximum than the 182.90 set on the same host.
Stoll4 is the quad (Q6600) and is my daily use machine for web browsing, my audio hobby, and some other things. It has processed an almost totally populated sequence over almost three complete cycles of 291.65. An initial cycle time estimate is near 27.
There appears to be a distinct up-trend in required CPU at the higher sequence numbers of this single frequency. The second maximum is higher than the first, and the third higher still. The same is true of the three visible minima.
While the uptrend in CPU time with sequence number seems clearest in the 291.65 data from Stoll4, with that pattern in mind, the 182.90 data from Stoll3 may support it.
Meanwhile, within the Stoll3 set, the entire 401.45 set clearly requires more CPU than the 182.90 set. The subset of sequence numbers available unfortunately leaves it rather ambiguous as to whether this is additional evidence of an uptrend in CPU requirement by sequence number within a frequency, or rather evidence of an uptrend in CPU requirement by frequency.
I definitely saw some frequency-dependent CPU use in S5R3, but think it was less than this.
I've leave it to wiggle specialists to interpret variation near the minima in 291.65 as to whether any wiggle behavior is discernible within the noise.
I'm afraid we may not be seeing again anywhere near this many cycles of a single frequency form a single host. The pattern of issue seems to be heading toward issuing work units from sequence numbers from a small fraction of a cycle, then bumping up the frequency by .05 or more, and often repeating in the same small cycle fraction.
I'm not ready to discuss cycle length vs. frequency, from which you may correctly infer that it does not seem to be fitting so tidily as I would like.
RE: RE: Richard, Without
)
Not that I can remember, looking at pop-up blocker, all temps are removed, and I can still see them.
Got a chance to set up an x64
)
Got a chance to set up an x64 'Longhorn' server yesterday. Guy who will be managing it locally called in sick today, so I offered to do some burn-in testing - guess what with!
Got issued, somewhat to my surprise, with WUs 0739.10_S5R4__479 and downwards. We don't usually get data so far up the frequency space this early in the run. Keep an eye on it, if you want to check theories about cycle length. (but NB it probably won't be available for long-term crunching - I'll try and keep it up until early next week, but no promises.)
RE: Got a chance to set up
)
Interesting. The work generation does seem to be behaving differently on this run.
At a preliminary guess, the cycle length for 739.10 frequency may be about 177. If so your samples will be most helpful in refining the estimate if they continue a way past the estimated minimum near 444. From that point of view, I'd be happy if the units issued you had some holes, the better to step down past the minimum.
However, this host/frequency may actually be even more useful for a look at the wiggles. The cycle length may be long enough to get a good first look. From that point of view sequential observations at a single frequency would be best.
RE: Got a chance to set up
)
So far the work issue seems not inclined to give you long sequence runs on the Longhorn host. Time will tell whether we get useful cycle learning from the execution. I was just convinced that it would just keep bumping up to higher frequencies while keeping very near sequence number 477 when I noticed two near 638--maybe there is hope for seeing a peak or valley yet.
If it is convenient for you unzip and get the line count of the skygrid file
(presumably skygrid_0740Hz_S5R4.dat), or just mail it to me, that would provide another point of the curve of cycle length vs. frequency by the Bikeman method. The highest skygrid file I have is the 440Hz one.
RE: If it is convenient for
)
Luckily, one of the first things I do when setting up a new server is to get the remote control working!
Yes, the server has skygrid_0740Hz_S5R4.dat, and I have a copy at home now. Linecount 134,316, size zipped 927,203 bytes, size unzipped 4,432,428 bytes (as a sanity check on the linecount - they look like fixed-length lines of 32 bytes). Let me know if you want me to email the whole file.
PS - Didn't take me long fishing around in the download directory structure of my local mirror to find the same data for skygrid_1080Hz_S5R4:
285,998 lines, zipped 1,928,898 bytes, unzipped 9,437,934 bytes.
RE: Yes, the server has
)
I can't use the Bikeman method on your 1080 Hz result without a skypoint count, which so far as I know we need task execution to get, though most we have seen so far in the low 800's they may be climbing with frequency.
But for 739.2 Hz we have both components and Bikeman's method forecasts a cycle length of 160. This is bad news for the quadratic model or for my tidiness, as my rough sky grid density constant fit of .000325 would make it 177--well outside the error limits of simple noise in my lower frequency observations. Maybe I just botched something--I'll look again in a day or two. For the moment it appears to me that the Bikeman method is, for some reason, not quite matching the reality but is very close, and that the simple quadratic model's "constant" needs a steady decreasing value (so far from about .000325 to about .0003) with increasing frequency to fit the data. All preliminary, at the moment.
RE: If it is convenient for
)
If it helps at all, the R4 skygrids seem to have the exact same number of lines as their R3 counterparts (at least for the small number I checked). I have about 50 different skygrids saved now up to close to 1100Hz. I also have tasks on many hosts to go with these. If I get some time I'll make a 3 column table of freq, #lines, and #skypoints for as many as possible before the tedium of doing it gets to me :-).
Cheers,
Gary.
RE: If it helps at all, the
)
Thanks, upon your note I checked the couple of skygrids that I have in both flavors, and they were exact matches also.
My vague impression is that the pattern of skypoint variation may differ some--of course the typical value for number of skypoints has shifted down quite a bit.
At the moment, my most fond wish would be several different frequencies with sufficient sequence numbers out in the third or fourth cycle to define the cycle length pretty accurately. This works better on hosts with little task-to-task random variation, which probably means in turn good memory performance (so variation in contention causes less noise), and with few non-Einstein cycles (again to reduce variation noise). Fully sequential data for a quarter-cycle near the minimum would be nifty for those with an interest in the "wiggles", but otherwise one just needs sequential samples on both sides of the maximum (to define both position and height, and a good enough sampled set around the minimum to define its depth well.
My Q6600, which does not have especially fast memory and does have some competing applications (I'm typing on it now), seems noticeably noisier than my E6600, which fortunately has just now gotten stocked up with sequence numbers 143 to 93 of frequency 401.45 with only about four missing counts. However that will take well over a week to complete if I let them all run undisturbed.
I don't expect to have much new in terms of final model to offer for a while. In the meantime I welcome any data posting, especially data or interpretation which runs counter to anything I've said.
Latest graph - as others have
)
Latest graph - as others have said, very spotty on the work allocation.
(direct link)
I think we have a reasonable max/min span for the new frequency band (37963.89 - 32501.38), and an interpolated cycle length of between 27.5 and 28.0
I can't explain the extended run times for 304.75__44 and __45 - I don't remember doing anything on the machine that would interfere, but that's what it looks like.
Work allocation coming up is even spottier, and I've also got 8 (so far) S5R3 resends. So I'll just let them work through at their own pace, and hope that the faster work request rate as the DCF adjusts will get us a more complete set in the next frequency band it sends me.
I'll post three sequences
)
I'll post three sequences from two hosts. Both are Conroe-class running on the same motherboard at 2.79 GHz, but as one is a quad and one a duo and they don't have the same environment of other tasks, I've separated them.
Stoll3 is the duo (E6600) and gets less usage for non-BOINC things, so can be expected to have less random variation in runtimes. The 182.90 sequence provides a rough cycle time estimate between 10 and 11. The 401.45 sequence provides a cycle time estimate of about 49, seems to have some odd variations in the upper 120s, and appears to require more CPU time at cycle minimum and maximum than the 182.90 set on the same host.
Stoll4 is the quad (Q6600) and is my daily use machine for web browsing, my audio hobby, and some other things. It has processed an almost totally populated sequence over almost three complete cycles of 291.65. An initial cycle time estimate is near 27.
There appears to be a distinct up-trend in required CPU at the higher sequence numbers of this single frequency. The second maximum is higher than the first, and the third higher still. The same is true of the three visible minima.
While the uptrend in CPU time with sequence number seems clearest in the 291.65 data from Stoll4, with that pattern in mind, the 182.90 data from Stoll3 may support it.
Meanwhile, within the Stoll3 set, the entire 401.45 set clearly requires more CPU than the 182.90 set. The subset of sequence numbers available unfortunately leaves it rather ambiguous as to whether this is additional evidence of an uptrend in CPU requirement by sequence number within a frequency, or rather evidence of an uptrend in CPU requirement by frequency.
I definitely saw some frequency-dependent CPU use in S5R3, but think it was less than this.
I've leave it to wiggle specialists to interpret variation near the minima in 291.65 as to whether any wiggle behavior is discernible within the noise.
I'm afraid we may not be seeing again anywhere near this many cycles of a single frequency form a single host. The pattern of issue seems to be heading toward issuing work units from sequence numbers from a small fraction of a cycle, then bumping up the frequency by .05 or more, and often repeating in the same small cycle fraction.
I'm not ready to discuss cycle length vs. frequency, from which you may correctly infer that it does not seem to be fitting so tidily as I would like.