Actually news, but I didn't come to write the details yet. We found we had to break the current run in two parts at 800Hz frequency. The display shows the work remaining below 800Hz. We'll have set up the upper half in a few days.
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
Would it be possible to keep the runtime unchanged and adjust the credit instead? This would reduce alot of the grumbling from people with older machines that aren't on 24/7.
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
Would it be possible to keep the runtime unchanged and adjust the credit instead? This would reduce alot of the grumbling from people with older machines that aren't on 24/7.
If the official Windows app becomes 4.26, there may be enough of a speed boost to help the GUM (Great Unwashed Masses). If not, then boosting deadlines up to 16-18 days until SSE can be implemented in the Windows app may also help...
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
Would it be possible to keep the runtime unchanged and adjust the credit instead? This would reduce alot of the grumbling from people with older machines that aren't on 24/7.
If the official Windows app becomes 4.26, there may be enough of a speed boost to help the GUM (Great Unwashed Masses). If not, then boosting deadlines up to 16-18 days until SSE can be implemented in the Windows app may also help...
Hmmm. . .
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
Would it be possible to keep the runtime unchanged and adjust the credit instead? This would reduce alot of the grumbling from people with older machines that aren't on 24/7.
If the official Windows app becomes 4.26, there may be enough of a speed boost to help the GUM (Great Unwashed Masses). If not, then boosting deadlines up to 16-18 days until SSE can be implemented in the Windows app may also help...
Hmmm. . .
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
Yes, and what I stated does depend on the runtime staying consistent between the =. If >= 800 takes longer than < 800, then there is definitely going to be some need for panic...
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
Depends on what Bernd meant. The way i read it was that the WUs were completing all the work they needed to do in significantly less time than was expected.
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
Depends on what Bernd meant. The way i read it was that the WUs were completing all the work they needed to do in significantly less time than was expected.
If that's the case, then I don't understand what the problem is.
Hopefully, we'll get some more amplifying info on this later.
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
Depends on what Bernd meant. The way i read it was that the WUs were completing all the work they needed to do in significantly less time than was expected.
If that's the case, then I don't understand what the problem is.
Hopefully, we'll get some more amplifying info on this later.
The way I translated it, the workunits ran much faster than anticipated. What isn't stated is why they ran faster than anticipated. Another related message here was about how tasks at the 799.xx frequency were erroring out immediately...
I unno... I've asked multiple times about deadline extensions. I was considering not asking again based upon the increase in speed by Windows 4.26. Will have to wait and see...
Sudden lurch in remaining work display
)
Actually news, but I didn't come to write the details yet. We found we had to break the current run in two parts at 800Hz frequency. The display shows the work remaining below 800Hz. We'll have set up the upper half in a few days.
BM
BM
I noticed all the WUs i had
)
I noticed all the WUs i had above 800 gives way too much credit, will future WUs in that range give lower credits?
Team Philippines
RE: I noticed all the WUs i
)
Apn unexpected side-effect of the problems we have found with the >=800Hz WUs is that they run shorter as intended. The new ones will get the same credit, but run noticeably longer.
BM
BM
RE: RE: I noticed all the
)
Would it be possible to keep the runtime unchanged and adjust the credit instead? This would reduce alot of the grumbling from people with older machines that aren't on 24/7.
RE: RE: RE: I noticed
)
If the official Windows app becomes 4.26, there may be enough of a speed boost to help the GUM (Great Unwashed Masses). If not, then boosting deadlines up to 16-18 days until SSE can be implemented in the Windows app may also help...
RE: RE: RE: RE: I
)
Hmmm. . .
I don't know. If I understand Bernd correctly, it sounds like these >= 800Hz workunits don't run long enough to complete all of the needed calculations. Thus, the need to create new workunits with longer runtimes.
RE: RE: RE: RE: Quote
)
Yes, and what I stated does depend on the runtime staying consistent between the =. If >= 800 takes longer than < 800, then there is definitely going to be some need for panic...
RE: I don't know. If I
)
Depends on what Bernd meant. The way i read it was that the WUs were completing all the work they needed to do in significantly less time than was expected.
RE: RE: I don't know.
)
If that's the case, then I don't understand what the problem is.
Hopefully, we'll get some more amplifying info on this later.
RE: RE: RE: I don't
)
The way I translated it, the workunits ran much faster than anticipated. What isn't stated is why they ran faster than anticipated. Another related message here was about how tasks at the 799.xx frequency were erroring out immediately...
I unno... I've asked multiple times about deadline extensions. I was considering not asking again based upon the increase in speed by Windows 4.26. Will have to wait and see...