Version 1.03 has recently been listed on the Applications page and also the files are in the download directory so I guess FGRP4 beta will start again soon. I've set up a host to ask for work but there's nothing available just yet.
New tasks for V1.03 are now being sent. I've got three with estimates of around 40 mins. So far two are showing 10% progress after about 45 mins. Looks like the estimates haven't yet been fixed.
They show a strange behaviour. After ~ 6 min the progress bar shows 25%, making a big step backwards then to 2,4%.
My first wu is now at 20% after 52 mins, the second at 16% after 47 min. Remaining time shows 3h35min and 3h16min now.
A third one started right now.
In the first stages the estimatet remaining time is at ~20 min.
They show a strange behaviour. After ~ 6 min the progress bar shows 25%, making a big step backwards then to 2,4%.
My first wu is now at 20% after 52 mins, the second at 16% after 47 min. Remaining time shows 3h35min and 3h16min now.
A third one started right now.
In the first stages the estimatet remaining time is at ~20 min.
See my explanation in the technical news area, replying to your matching post there.
2. the credit awarded (as seen here and elsewhere) of 2.58 seems very low in relation to the CPU work required.
3. I'm very happy to see CPU work available in small enough doses of computation required to be suitable either for lower output machines which run 24/7, or for somewhat higher output machines which run intermittently (as does my laptop).
Apparently I was simply wrong in supposing that the short work many of us got initially was typical of FGRP4, instead of just being the "short ends" type work previously observed.
Now I and others have gotten some FGRP4 work with much longer execution times (a bit under 10x). As the ones I have seen receive credit of this flavor are getting 24.95 cobblestones, these also have a severely low "pay" rate. I also think as distributed they arrive with a severely low completion time estimate, which coupled with the very short deadline for beta work can be expected to cause this work to preempt other work with High Priority execution, and to mangle the Duration Correction Factor for hosts running it, with attendant work fetch, queue, and High Priority disruptions.
For the first time in days, I think there is newly made FGRP4 work.
I've been watching the Einstein Server Status page, and for the last couple of days it has commonly shown zero to three FGRP4 Tasks to send, with Tasks in Progress and workunits without canonical results steadily declining.
At the moment of writing, the 25 Aug 2014 15:35:01 UTC update shows 172 tasks to send, and a considerable increase in Tasks in Progress and Workunits without canonical result.
My newest PC received one of this batch of newly made work with a stated creation date of 25 Aug 2014 14:04:35 UTC.
While it did immediately go into high priority processing, this appears to be a combination of the still-short (48 hours) beta test related deadline, coupled with a moderately high host DCF not yet fully recovered from previous bad-estimate FGRP4 work. In fact, the relationship between the CPU time consumed, percent completion, and estimated time left suggests to me that this unit may have arrived with a much longer time estimate (however that gets delivered) than previous FGRP4 work.
Perhaps others can comment on possible changes to the estimate accuracy matter.
I think this batch of FGRP4 work production ceased several hours ago. The Tasks to Send dropped steadily, and has recently been zero, while the Workunits Total has been stable at 2050 for several hours. That number is better to watch as a sign of new production than is the Tasks total, as Tasks total grows with resends.
My evidence that this new work arrives with lower estimates is strengthened by observing the Duration Correction Factor adjustment on its completion. This host had been fairly far along in recovery from DCF elevation attendant to running the previous FGRP4 batch. For example, reporting of the last Perseus job it completed before completing this FGRP4 job lowed DCF from 2.87 to 2.73. Reporting this FGRP4 job lowered the DCF to 2.50--while under the prior regime it would have leaped upward.
My host has received yet another of these, but neither quorum partner has reported, so it may be a while before I can see on these tasks whether there has been any adjustment to the (very low) credit awarded for this work. If unchanged, it seems likely that the award will 24.85 or 28.95, while equity with GRP3 CPU work would suggest over 200, I think.
Aha--one of my "August 25 original creation date" batch has been awarded credit, and got 238.81. I've done no detailed calculations, but that fits the somewhat over 200 I thought about right.
Workunits total is still 2050, so no more have been made in a half day or so--probably waiting to see how this batch works out in the field.
Jeroen has reported over in Technical News that there is a yet longer to process variant in this batch, and indeed has has received for different units credits of 238.81 and 607.84.
... while the Workunits Total has been stable at 2050 for several hours. That number is better to watch as a sign of new production than is the Tasks total, as Tasks total grows with resends.
Yes, indeed. I noticed that the initial work allocation several days ago was 1900 WUs - ie, 3800 primary tasks. The latest release was a further 150 WUs (300 tasks), giving the total of 2050 WUs all up (4100 primary tasks). At the time of writing, tasks total was 6541 which means that so far there have been 6541-4100=2441 resends.
If you look at Jeroen's spread of results, the credit claim has been reasonably consistent with the run time, throughout all tasks. The credit award was wrong for the initial series but has been fixed in the latest series. That should be the end of 'max time limit exceeded' problems.
Another new batch has been created. Three of my hosts have received a total of four of them. The new workunit total is 2550, so 500 new ones since the previously reported progress point.
The four that I received have creation dates in the narrow time window of 26 Aug 2014 6:52:08 UTC to 6:58:03. They were sent to my hosts between 7:13 and 10:22 (i.e. not right away).
Here is the odd part, to me. As of now (about 13:50 UTC) NONE of the four has been sent to a quorum partner.
Maybe not so odd--I suppose not very many users have set their preferences to accept beta-test work, and many of those that did may currently be grinding down their DCF to a level that does not call their current queue-length greater than requested, so this sub-population may be unusually unlikely to request work just now. Also some may have turned off their beta-test acceptance in response to previous problems.
Version 1.03 has recently
)
Version 1.03 has recently been listed on the Applications page and also the files are in the download directory so I guess FGRP4 beta will start again soon. I've set up a host to ask for work but there's nothing available just yet.
Cheers,
Gary.
New tasks for V1.03 are now
)
New tasks for V1.03 are now being sent. I've got three with estimates of around 40 mins. So far two are showing 10% progress after about 45 mins. Looks like the estimates haven't yet been fixed.
Cheers,
Gary.
They show a strange
)
They show a strange behaviour. After ~ 6 min the progress bar shows 25%, making a big step backwards then to 2,4%.
My first wu is now at 20% after 52 mins, the second at 16% after 47 min. Remaining time shows 3h35min and 3h16min now.
A third one started right now.
In the first stages the estimatet remaining time is at ~20 min.
RE: They show a strange
)
See my explanation in the technical news area, replying to your matching post there.
archae86 wrote: 2. the credit
)
Apparently I was simply wrong in supposing that the short work many of us got initially was typical of FGRP4, instead of just being the "short ends" type work previously observed.
Now I and others have gotten some FGRP4 work with much longer execution times (a bit under 10x). As the ones I have seen receive credit of this flavor are getting 24.95 cobblestones, these also have a severely low "pay" rate. I also think as distributed they arrive with a severely low completion time estimate, which coupled with the very short deadline for beta work can be expected to cause this work to preempt other work with High Priority execution, and to mangle the Duration Correction Factor for hosts running it, with attendant work fetch, queue, and High Priority disruptions.
For the first time in days, I
)
For the first time in days, I think there is newly made FGRP4 work.
I've been watching the Einstein Server Status page, and for the last couple of days it has commonly shown zero to three FGRP4 Tasks to send, with Tasks in Progress and workunits without canonical results steadily declining.
At the moment of writing, the 25 Aug 2014 15:35:01 UTC update shows 172 tasks to send, and a considerable increase in Tasks in Progress and Workunits without canonical result.
My newest PC received one of this batch of newly made work with a stated creation date of 25 Aug 2014 14:04:35 UTC.
While it did immediately go into high priority processing, this appears to be a combination of the still-short (48 hours) beta test related deadline, coupled with a moderately high host DCF not yet fully recovered from previous bad-estimate FGRP4 work. In fact, the relationship between the CPU time consumed, percent completion, and estimated time left suggests to me that this unit may have arrived with a much longer time estimate (however that gets delivered) than previous FGRP4 work.
Perhaps others can comment on possible changes to the estimate accuracy matter.
I think this batch of FGRP4
)
I think this batch of FGRP4 work production ceased several hours ago. The Tasks to Send dropped steadily, and has recently been zero, while the Workunits Total has been stable at 2050 for several hours. That number is better to watch as a sign of new production than is the Tasks total, as Tasks total grows with resends.
My evidence that this new work arrives with lower estimates is strengthened by observing the Duration Correction Factor adjustment on its completion. This host had been fairly far along in recovery from DCF elevation attendant to running the previous FGRP4 batch. For example, reporting of the last Perseus job it completed before completing this FGRP4 job lowed DCF from 2.87 to 2.73. Reporting this FGRP4 job lowered the DCF to 2.50--while under the prior regime it would have leaped upward.
My host has received yet another of these, but neither quorum partner has reported, so it may be a while before I can see on these tasks whether there has been any adjustment to the (very low) credit awarded for this work. If unchanged, it seems likely that the award will 24.85 or 28.95, while equity with GRP3 CPU work would suggest over 200, I think.
Aha--one of my "August 25
)
Aha--one of my "August 25 original creation date" batch has been awarded credit, and got 238.81. I've done no detailed calculations, but that fits the somewhat over 200 I thought about right.
Workunits total is still 2050, so no more have been made in a half day or so--probably waiting to see how this batch works out in the field.
Jeroen has reported over in Technical News that there is a yet longer to process variant in this batch, and indeed has has received for different units credits of 238.81 and 607.84.
RE: ... while the Workunits
)
Yes, indeed. I noticed that the initial work allocation several days ago was 1900 WUs - ie, 3800 primary tasks. The latest release was a further 150 WUs (300 tasks), giving the total of 2050 WUs all up (4100 primary tasks). At the time of writing, tasks total was 6541 which means that so far there have been 6541-4100=2441 resends.
If you look at Jeroen's spread of results, the credit claim has been reasonably consistent with the run time, throughout all tasks. The credit award was wrong for the initial series but has been fixed in the latest series. That should be the end of 'max time limit exceeded' problems.
Cheers,
Gary.
Another new batch has been
)
Another new batch has been created. Three of my hosts have received a total of four of them. The new workunit total is 2550, so 500 new ones since the previously reported progress point.
The four that I received have creation dates in the narrow time window of 26 Aug 2014 6:52:08 UTC to 6:58:03. They were sent to my hosts between 7:13 and 10:22 (i.e. not right away).
Here is the odd part, to me. As of now (about 13:50 UTC) NONE of the four has been sent to a quorum partner.
Maybe not so odd--I suppose not very many users have set their preferences to accept beta-test work, and many of those that did may currently be grinding down their DCF to a level that does not call their current queue-length greater than requested, so this sub-population may be unusually unlikely to request work just now. Also some may have turned off their beta-test acceptance in response to previous problems.