Before this app can be released for general use it needs to be modified to detect whether SSE is available on the system. If it doesn't, we'll have perhaps thousands of hosts bombing as soon as it starts.
.... So to have the correct estimated time to completion, I should have an RDCF of 0.302000, which in my opinion is way too low for a project like Einstein.
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
.... So to have the correct estimated time to completion, I should have an RDCF of 0.302000, which in my opinion is way too low for a project like Einstein.
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
If so Einstein is only just now catching up to SETI on Windows XP platforms.
I've been running the Windows Einstein aps as soon as they came out.
For comparison, here are the task/result duration correction factors for my four hosts on SETI and Einstein
Granted, the Einstein numbers are trending downward, and will continue somewhat further, but I suspect on the 4.36 release they won't get below the SETI values on my main hosts.
I'm not sure what bad effect Ageless has in mind, but it seems to me that the main one is less prefetching for new hosts or newly reset hosts than the longterm value. Many folks posting on the SETI forums complaining about large queues of abandoned work might regard that as a feature, rather than a problem.
.... So to have the correct estimated time to completion, I should have an RDCF of 0.302000, which in my opinion is way too low for a project like Einstein.
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
If so Einstein is only just now catching up to SETI on Windows XP platforms.
I've been running the Windows Einstein aps as soon as they came out.
For comparison, here are the task/result duration correction factors for my four hosts on SETI and Einstein
Granted, the Einstein numbers are trending downward, and will continue somewhat further, but I suspect on the 4.36 release they won't get below the SETI values on my main hosts.
You are quite correct that Einstein is just now being able to catch up with the potential over at SETI. Sure, the stock app won't yield those low values, but the optimized app will.
Just for kicks, here's how my AMD stacks up:
_CPU_ SETI Einstein
3700+ .195 .302
I don't know what Jord is seeing as a "problem", unless it is a concern about huge queues and abandoned work...
At this moment a severe headache, which makes thinking problematic.
Nothing But Idle Time wrote:
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
The problem with the low RDCF is that eventually we'll change to another application and in the long term to a new S5 run. Not knowing the effects of the new application or the run time of the completely new run's initial tasks will have a lot of machines that run with this low an RDCF fetch a whole lot of work they can't possibly crunch within the allotted time.
So yes to your second question, it's bad. With a lower RDCF BOINC estimates more correctly what the times of the present work is. Change the work, which will eventually happen and tasks that now run in 4 hours will then run in 48 hours (example given).
At this moment a severe headache, which makes thinking problematic.
Nothing But Idle Time wrote:
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
The problem with the low RDCF is that eventually we'll change to another application and in the long term to a new S5 run. Not knowing the effects of the new application or the run time of the completely new run's initial tasks will have a lot of machines that run with this low an RDCF fetch a whole lot of work they can't possibly crunch within the allotted time.
So yes to your second question, it's bad. With a lower RDCF BOINC estimates more correctly what the times of the present work is. Change the work, which will eventually happen and tasks that now run in 4 hours will then run in 48 hours (example given).
I'm not sure I get your point. The effect you mention will happen whenever a project goes from short-running WUs/apps to longer-running WUs/apps, no matter what the absolute value of the RDCF value is(be it 0.1 or 100), right?
There must be some events that will reset the RDCF to 1.0, tho, but I can't remember what those are. Anyone?
There must be some events that will reset the RDCF to 1.0, tho, but I can't remember what those are. Anyone?
CU
Bikeman
Restting the project also resets the DCF to 1.0; I've observed it many times.
As for a mix of short and long running tasks... the dcf will be middle of the road, moving up and down slightly in response to the varying task lengths. But Ageless is right also, a consistently low task time will ultimately set the dcf to some low value, and then when a new set of longer running tasks come along there will be a tendency to overload the cache, though it's anybody's guess whether that will lead to missed deadlines.
There must be some events that will reset the RDCF to 1.0, tho, but I can't remember what those are. Anyone?
CU
Bikeman
Restting the project also resets the DCF to 1.0; I've observed it many times.
As for a mix of short and long running tasks... the dcf will be middle of the road, moving up and down slightly in response to the varying task lengths. But Ageless is right also, a consistently low task time will ultimately set the dcf to some low value, and then when a new set of longer running tasks come along there will be a tendency to overload the cache, though it's anybody's guess whether that will lead to missed deadlines.
I think Jord has a point, but only in regards to people running stock applications, which would be the majority of the user base. I think it would be a good idea to try to keep DCF fairly close to 1 in regards to the stock app. For those of us using optimized apps, I would have the expectation that we should "keep up with the bouncing ball" and realize that there will be a period of relearning when longer running tasks come out.
The "pain" of all of this could be lessened by testing new applications / new longer-running tasks in a separate beta area. This would allow testing / debugging of the application as well as the estimates used by the WU generator, before releasing out to the GUM (Great Unwashed Masses)...
Edit: One large caveat is if feature detection is worked out so that one application can go out to the GUM and it will do x87 on processors that don't support SSE, but SSE on those that do...
The problem of RDCF or should that be TDCF now, is a problem at the moment on SetiBeta. They are running two applications Seti enhanced V.6 and AstroPulse (AP) V4.26. Enhanced is fairly well optimised and lowers the DCF but AP is relatively new, and ironing out basic bugs, and drives the DCF up.
If you have run Enhanced V.6 for some time and then the project wants to test the next AP app you end up d/loading too many 50+hr units, and vice versa you end up not d/loading enough 30 min enhanced units.
4.36
Frequency : 828.5
Period of task cycle = 140.8
Number of points = 13
Minimum runtime in data = 10024.09
Maximum runtime in data = 10483.66
Estimated peak runtime = 11905
Estimated average runtime = 10631
Estimated trough runtime = 9904
Estimated runtime variance = 0.168
4.32
Frequency : 828.55
Period of task cycle = 140.8
Number of points = 9
Minimum runtime in data = 12291.81
Maximum runtime in data = 14205.61
Estimated peak runtime = 15986
Estimated average runtime = 13648
Estimated trough runtime = 12314
Estimated runtime variance = 0.23
So also a decrease in runtime variance (like my Q6600). Keep up the good work.
RE: Before this app can be
)
How hard it is to program that feature?
RE: .... So to have the
)
Are you implying that the task estimates are too high given the newer and faster app? Is a RDCF that approaches zero a bad precedent?
RE: RE: .... So to have
)
If so Einstein is only just now catching up to SETI on Windows XP platforms.
I've been running the Windows Einstein aps as soon as they came out.
For comparison, here are the task/result duration correction factors for my four hosts on SETI and Einstein
Granted, the Einstein numbers are trending downward, and will continue somewhat further, but I suspect on the 4.36 release they won't get below the SETI values on my main hosts.
I'm not sure what bad effect Ageless has in mind, but it seems to me that the main one is less prefetching for new hosts or newly reset hosts than the longterm value. Many folks posting on the SETI forums complaining about large queues of abandoned work might regard that as a feature, rather than a problem.
RE: RE: RE: .... So to
)
You are quite correct that Einstein is just now being able to catch up with the potential over at SETI. Sure, the stock app won't yield those low values, but the optimized app will.
Just for kicks, here's how my AMD stacks up:
I don't know what Jord is seeing as a "problem", unless it is a concern about huge queues and abandoned work...
archae86 wrote:I'm not sure
)
At this moment a severe headache, which makes thinking problematic.
The problem with the low RDCF is that eventually we'll change to another application and in the long term to a new S5 run. Not knowing the effects of the new application or the run time of the completely new run's initial tasks will have a lot of machines that run with this low an RDCF fetch a whole lot of work they can't possibly crunch within the allotted time.
So yes to your second question, it's bad. With a lower RDCF BOINC estimates more correctly what the times of the present work is. Change the work, which will eventually happen and tasks that now run in 4 hours will then run in 48 hours (example given).
RE: archae86 wrote:I'm not
)
I'm not sure I get your point. The effect you mention will happen whenever a project goes from short-running WUs/apps to longer-running WUs/apps, no matter what the absolute value of the RDCF value is(be it 0.1 or 100), right?
There must be some events that will reset the RDCF to 1.0, tho, but I can't remember what those are. Anyone?
CU
Bikeman
RE: There must be some
)
Restting the project also resets the DCF to 1.0; I've observed it many times.
As for a mix of short and long running tasks... the dcf will be middle of the road, moving up and down slightly in response to the varying task lengths. But Ageless is right also, a consistently low task time will ultimately set the dcf to some low value, and then when a new set of longer running tasks come along there will be a tendency to overload the cache, though it's anybody's guess whether that will lead to missed deadlines.
RE: RE: There must be
)
I think Jord has a point, but only in regards to people running stock applications, which would be the majority of the user base. I think it would be a good idea to try to keep DCF fairly close to 1 in regards to the stock app. For those of us using optimized apps, I would have the expectation that we should "keep up with the bouncing ball" and realize that there will be a period of relearning when longer running tasks come out.
The "pain" of all of this could be lessened by testing new applications / new longer-running tasks in a separate beta area. This would allow testing / debugging of the application as well as the estimates used by the WU generator, before releasing out to the GUM (Great Unwashed Masses)...
Edit: One large caveat is if feature detection is worked out so that one application can go out to the GUM and it will do x87 on processors that don't support SSE, but SSE on those that do...
The problem of RDCF or should
)
The problem of RDCF or should that be TDCF now, is a problem at the moment on SetiBeta. They are running two applications Seti enhanced V.6 and AstroPulse (AP) V4.26. Enhanced is fairly well optimised and lowers the DCF but AP is relatively new, and ironing out basic bugs, and drives the DCF up.
If you have run Enhanced V.6 for some time and then the project wants to test the next AP app you end up d/loading too many 50+hr units, and vice versa you end up not d/loading enough 30 min enhanced units.
I have the first results from
)
I have the first results from my E8400 @ 4GHz
4.36
Frequency : 828.5
Period of task cycle = 140.8
Number of points = 13
Minimum runtime in data = 10024.09
Maximum runtime in data = 10483.66
Estimated peak runtime = 11905
Estimated average runtime = 10631
Estimated trough runtime = 9904
Estimated runtime variance = 0.168
4.32
Frequency : 828.55
Period of task cycle = 140.8
Number of points = 9
Minimum runtime in data = 12291.81
Maximum runtime in data = 14205.61
Estimated peak runtime = 15986
Estimated average runtime = 13648
Estimated trough runtime = 12314
Estimated runtime variance = 0.23
So also a decrease in runtime variance (like my Q6600). Keep up the good work.