This post is not actually on beyond 800 work but on the transition.
Until today my two Core 2 hosts have been marching steadily through a single frequency each.
But not having reached sequence number 0, and in fact quite a few hours away at current progress rates, both have downloaded new below 800 skygrids.
One got just a single WU downloaded from the new skygrid before hopping to yet a third. The other did two before hopping back to its previous skygrid but at a different frequency.
All are _0 or _1 results, so this is not a matter of backfilling for failed original quorum partners.
Just to be a little alarmist: given that skygrids are pretty big downloads, if my experience is typical we may be heading into a period of heavy server load.
This post is not actually on beyond 800 work but on the transition.
Until today my two Core 2 hosts have been marching steadily through a single frequency each.
But not having reached sequence number 0, and in fact quite a few hours away at current progress rates, both have downloaded new below 800 skygrids.
One got just a single WU downloaded from the new skygrid before hopping to yet a third. The other did two before hopping back to its previous skygrid but at a different frequency.
All are _0 or _1 results, so this is not a matter of backfilling for failed original quorum partners.
Just to be a little alarmist: given that skygrids are pretty big downloads, if my experience is typical we may be heading into a period of heavy server load.
I actually got a combination on my last work fetch. I received 3 "backfill" tasks for 779Hz, then got a download of a new data set for 807 with 3 more tasks for that frequency...
Just to be a little alarmist: given that skygrids are pretty big downloads, if my experience is typical we may be heading into a period of heavy server load.
On the server status page, the unsent results are listed at around 58K. It was around 500K earlier when all the remaining 800 tasks so there can't be too many old tasks left now. We are in 'dregs cleanup' mode with a bit of a difference. Only (a rapidly diminishing) part of the tasks on hand are 'dregs' so the server load shouldn't be as much of a problem as it might otherwise be if this were a full 'end of run' situation.
This post is not actually on beyond 800 work but on the transition.
Well reading the title S5R3 beyond 800 work has led me to the wrong conclusion then.
I did make mention of only one computer (my Opteron 275) as my others are all still doing sub 800 work and thought to share with you all that the higher frequencies don't appear any harder to process.
As 921 is greater or beyond 800 I thought progress on these frequencies went here, I stand corrected and will not bother this thread anymore.
This post is not actually on beyond 800 work but on the transition.
As 921 is greater or beyond 800 I thought progress on these frequencies went here, I stand corrected and will not bother this thread anymore.
Your 921 data was precisely on the thread topic. Thank you. My comment that you quoted was an acknowledgment that the specific post of mine was a bit aside the nominal thread topic, though still in its penumbra, I think.
"Oldest unsent result" is suddenly only 6 d 23 h 20 m old, where it had been over twice that. So, it would appear, all the sub-800 has been sent out at least once.
My two hosts that got new result downloads today both got beyond 800 work, both for the first time.
The deadline extension makes the transition easy to spot in the task list.
All four of my hosts have run results from the "good, long, new" flavor of beyond 800 Hz work.
The quick summary is that the individual results seem entirely normal, and CPU times using the Windows 4.32 "power users" ap seem the same as my relatively small sample of sub 800 work.
For my 3.006 GHz Q6600, Mike Hewson's Ready Reckoner V7c, running with inputs preprocessed to bump up the frequency to the next higher integer multiple of 10 Hz, and using a sky grid constant of .00020417, thinks this of a sample of results starting somewhat below peak and descending to right about the trough, all in the third cycle:
Frequency : 910.433
Period of task cycle = 170.8
Number of points = 32
Minimum runtime in data = 17749.73
Maximum runtime in data = 22662.08
Estimated peak runtime = 24570
Estimated average runtime = 20311
Estimated trough runtime = 17880
Estimated runtime variance = 0.272
for comparison, on sub-800 4.32 work on this host I previously reported "This gives an estimate of 24384 peak time and .286 variance, for an overall estimated runtime average of 19939."
For my same speed E6600, this:
Frequency : 850.433
Period of task cycle = 149
Number of points = 18
Minimum runtime in data = 17292.17
Maximum runtime in data = 21969.25
Estimated peak runtime = 23800
Estimated average runtime = 19543
Estimated trough runtime = 17113
Estimated runtime variance = 0.281
for comparison, for sub-800 4.32 work on this host I previously reported "this gives an estimate of 22448 peak time and .286 variance, for an over all estimated runtime average of 18923."
Given the noise in the data, and a difference in the estimation techniques (I did not use the 10-Hz step plus .00020417 constant approach in estimating the sub-800 work, I think these should be considered equivalent within the measurement capability. At face value they suggest that CPU times are a couple of percent longer.
One thing I have noticed is that both my Q6600 and my E6600 keep getting new work from yet higher .05 frequency steps. Apparently the work generator is not populating lower sequence numbers at their frequencies fast enough to keep them supplied. Unfortunately this means it may be some time before my hosts see sequence number populating a full cycle.
This post is not actually on
)
This post is not actually on beyond 800 work but on the transition.
Until today my two Core 2 hosts have been marching steadily through a single frequency each.
But not having reached sequence number 0, and in fact quite a few hours away at current progress rates, both have downloaded new below 800 skygrids.
One got just a single WU downloaded from the new skygrid before hopping to yet a third. The other did two before hopping back to its previous skygrid but at a different frequency.
All are _0 or _1 results, so this is not a matter of backfilling for failed original quorum partners.
Just to be a little alarmist: given that skygrids are pretty big downloads, if my experience is typical we may be heading into a period of heavy server load.
RE: This post is not
)
I actually got a combination on my last work fetch. I received 3 "backfill" tasks for 779Hz, then got a download of a new data set for 807 with 3 more tasks for that frequency...
RE: Just to be a little
)
On the server status page, the unsent results are listed at around 58K. It was around 500K earlier when all the remaining 800 tasks so there can't be too many old tasks left now. We are in 'dregs cleanup' mode with a bit of a difference. Only (a rapidly diminishing) part of the tasks on hand are 'dregs' so the server load shouldn't be as much of a problem as it might otherwise be if this were a full 'end of run' situation.
Cheers,
Gary.
RE: This post is not
)
Well reading the title S5R3 beyond 800 work has led me to the wrong conclusion then.
I did make mention of only one computer (my Opteron 275) as my others are all still doing sub 800 work and thought to share with you all that the higher frequencies don't appear any harder to process.
As 921 is greater or beyond 800 I thought progress on these frequencies went here, I stand corrected and will not bother this thread anymore.
Please continue your discussion.
RE: RE: This post is not
)
Your 921 data was precisely on the thread topic. Thank you. My comment that you quoted was an acknowledgment that the specific post of mine was a bit aside the nominal thread topic, though still in its penumbra, I think.
I had only two >800 "b" WUs
)
I had only two >800 "b" WUs so i take it with a grain of salt but still, they were slower than peak runtime on 800 ones were run at 4GHz)
Team Philippines
"Oldest unsent result" is
)
"Oldest unsent result" is suddenly only 6 d 23 h 20 m old, where it had been over twice that. So, it would appear, all the sub-800 has been sent out at least once.
My two hosts that got new result downloads today both got beyond 800 work, both for the first time.
The deadline extension makes the transition easy to spot in the task list.
All four of my hosts have run
)
All four of my hosts have run results from the "good, long, new" flavor of beyond 800 Hz work.
The quick summary is that the individual results seem entirely normal, and CPU times using the Windows 4.32 "power users" ap seem the same as my relatively small sample of sub 800 work.
For my 3.006 GHz Q6600, Mike Hewson's Ready Reckoner V7c, running with inputs preprocessed to bump up the frequency to the next higher integer multiple of 10 Hz, and using a sky grid constant of .00020417, thinks this of a sample of results starting somewhat below peak and descending to right about the trough, all in the third cycle:
Frequency : 910.433
Period of task cycle = 170.8
Number of points = 32
Minimum runtime in data = 17749.73
Maximum runtime in data = 22662.08
Estimated peak runtime = 24570
Estimated average runtime = 20311
Estimated trough runtime = 17880
Estimated runtime variance = 0.272
for comparison, on sub-800 4.32 work on this host I previously reported "This gives an estimate of 24384 peak time and .286 variance, for an overall estimated runtime average of 19939."
For my same speed E6600, this:
Frequency : 850.433
Period of task cycle = 149
Number of points = 18
Minimum runtime in data = 17292.17
Maximum runtime in data = 21969.25
Estimated peak runtime = 23800
Estimated average runtime = 19543
Estimated trough runtime = 17113
Estimated runtime variance = 0.281
for comparison, for sub-800 4.32 work on this host I previously reported "this gives an estimate of 22448 peak time and .286 variance, for an over all estimated runtime average of 18923."
Given the noise in the data, and a difference in the estimation techniques (I did not use the 10-Hz step plus .00020417 constant approach in estimating the sub-800 work, I think these should be considered equivalent within the measurement capability. At face value they suggest that CPU times are a couple of percent longer.
One thing I have noticed is that both my Q6600 and my E6600 keep getting new work from yet higher .05 frequency steps. Apparently the work generator is not populating lower sequence numbers at their frequencies fast enough to keep them supplied. Unfortunately this means it may be some time before my hosts see sequence number populating a full cycle.