The new app version 1.11 reserves 8% of the work for the "follow up" stage at the end. The time this stage takes is unpredicatable, but 8% should be a reasonably close upper bound. Better than the task sitting at 100% done for hours.
However these 8% is calculated for a CPU task, simply because the variety of GPU runtimes is so large and we currently know of now way to adapt it for a given system.
Assume my Intel HD 2500 integrated GPU is not picking up any FGRP3 work because it has 1.984GB of memory, where 2.0GB is required?
Thanks!
That's not the reason, the reason is that there is no Intel GPU application to process FGRP3 work. Look at this page for the available applications and on what platforms they run.
Assume my Intel HD 2500 integrated GPU is not picking up any FGRP3 work because it has 1.984GB of memory, where 2.0GB is required?
Thanks!
That's not the reason, the reason is that there is no Intel GPU application to process FGRP3 work. Look at this page for the available applications and on what platforms they run.
The only work available for Intel GPUs is BRP4.
Oops! I made a bad assumption, that the Albert@home 1.11 (FGRPopencl-intel_gpu) application was also on EAH. Thanks for pointing that out! Hopefully, the intel_gpu app will come over to EAH sometime in the future!
Odd: Got a new wu FGRP 3 1.11 (had 1.09 before). It ran for 52 minutes to 7% or so and then dropped to .793%. wu: 184763722. No explanation for the sudden drop. Will see what it does until completion. Other task version 1.09 at the same time did not have a drop that i could see.
That's not my experience. I promoted and then watched a 1.11 task and it sat on 0.000% for around an hour and 9 mins before going to 0.737%. There was no progress to over 7% before dropping back to 0.7%. I've observed two more iterations to 1.708% at 1:17 and 2.679% at 1:25. This is 0.971% every 8 minutes which is pretty much precisely what this machine does with v1.09 tasks. You had me worried for a bit about going to 7% and then dropping back :-).
Bernd wrote :-
Quote:
The new app version 1.11 reserves 8% of the work for the "follow up" stage at the end. The time this stage takes is unpredicatable, but 8% should be a reasonably close upper bound. Better than the task sitting at 100% done for hours.
I never saw a task sitting on 100% done and still running - even for a few seconds. Mine would sit on something like 99.029%. They might take quite a while to tick over to 100% but that's a lot less concerning than actually seeming to be at exactly 100%.
I think you've traded one 'problem' for another. I think it might be more concering for less experienced people to see a newly started task sit at 0.000% for such a long time. At least when sitting on 99.07% you know the thing has been progressing and probably just needs more time to finish. There would be some reluctance to 'interfere' with a task so close to finishing. If people see tasks sitting at 0% for a long time, they might decide there must be something wrong and abort them.
With 104 sky points (103 intervals) in a standard task (ie 0.9708738% per interval) I guess the 'trick' you are using is to start the progress at -8% and increment it by 0.9708738% every time a checkpoint is written and to display the negative numbers (-8.0%, -7.029%, -6.058% ... -0.233) as 0.000%. The next in the sequence is 0.737% so that explains the 'odd' percentage I saw after 1:09mins.
I'm wondering if you've considered adjusting the % increment rather than starting from -8%. You could assume 8% more sky points (say 112 instead of 104) and work out the increment per interval to be 0.901% rather than 0.971%. That way you could start seeing progress increments as normal but they would stop at around 92.2% when the follow-up stage started. However you could keep adding the 0.901% increments at calculated intervals to keep the punters happy that 'progress' was being made, even if checkpoints weren't actually being written.
I'm not asking you to do anything as I understand your time constraints. Unless other tweaks occurred as well, I'd have been quite happy to have stayed on 1.09 :-). I'll also be happy to be on 1.11 now that I understand what's happening with the protracted 0.000% progress :-).
EDIT: Of course, if the progress interval were to be set at 0.901% and the last checkpoint was written around 92.2% with 'simulated checkpoints' after that, you do stand to lose quite a bit of crunching if you stop after any subsequent progress value greater than 92.2%.
Also, if I'm correct above in my assumptions of how 1.11 is working, progress will stop at 92% and then jump to 100% at the end of the follow-up calculations. I'll be interested to come back and watch the 1.11 task when it gets close to the end. It should get there around 8.00PM tonight.
Currently FGRP is not at all affected by the 'Run CPU versions of applications for which GPU versions are available' setting, which is a bug we'll hope to fix in the next app version release.
BM
This still appears to be an issue with the new app version, unless I am missing something. Since I am running 100% GPU's on one machine, the additional downloading of CPU versions is a waste of time and resources. So hopefully this is still "on the radar" to be fixed.
Currently FGRP is not at all affected by the 'Run CPU versions of applications for which GPU versions are available' setting, which is a bug we'll hope to fix in the next app version release.
That's not my experience. I promoted and then watched a 1.11 task and it sat on 0.000% for around an hour and 9 mins before going to 0.737%. There was no progress to over 7% before dropping back to 0.7%. I've observed two more iterations to 1.708% at 1:17 and 2.679% at 1:25. This is 0.971% every 8 minutes which is pretty much precisely what this machine does with v1.09 tasks. You had me worried for a bit about going to 7% and then dropping back :-).
The same as before just happened again. About 50 minutes to 7% or so and then drop to .793. Subsequent intervals are just a couple of minutes. Run time of the first file in total was around 37000 seconds on a single task. (both GPU's are also running one task at the same time). The 1.09 task was about the same runtime so even though i noticed the drop in total time there was not much difference.
I have to add these were the first completed FGRP 3 CPU tasks on my new machine. What does surprise me is the runtime. On my previous MBPro, which was less powerful, the runtime was mostly under 28000 seconds for a task. That was 1.09. I have not been doing 1.11 wu's on the MBPro after getting the new machine. No idea where the extra 3 hours come from on a quicker machine.
Hallo!
I´m runnung a quadcore non HT CPU intel i5 4430. Before the GPU-version of FGRP3 I had allway 3 tasks running of FGRP3 and 1 of BRP5 on the GPU which gave an CPU-load of at all about 83%. With the new FGRP3 version 1.11 I´ve running only one task for CPU and 1 task for GPU giving at all about 52% of CPU-load. That´s too low. I hope it will become possible to choose whether to crunch GPU or CPU version of FRP3 tasks. Meanwhile I disabled FGRP3 tasks.
The new app version 1.11
)
The new app version 1.11 reserves 8% of the work for the "follow up" stage at the end. The time this stage takes is unpredicatable, but 8% should be a reasonably close upper bound. Better than the task sitting at 100% done for hours.
However these 8% is calculated for a CPU task, simply because the variety of GPU runtimes is so large and we currently know of now way to adapt it for a given system.
BM
BM
Ah, clear. Good to know.
)
Ah, clear. Good to know. Already happy that it runs. :)
Assume my Intel HD 2500
)
Assume my Intel HD 2500 integrated GPU is not picking up any FGRP3 work because it has 1.984GB of memory, where 2.0GB is required?
Thanks!
RE: Assume my Intel HD 2500
)
That's not the reason, the reason is that there is no Intel GPU application to process FGRP3 work. Look at this page for the available applications and on what platforms they run.
The only work available for Intel GPUs is BRP4.
RE: RE: Assume my Intel
)
Oops! I made a bad assumption, that the Albert@home 1.11 (FGRPopencl-intel_gpu) application was also on EAH. Thanks for pointing that out! Hopefully, the intel_gpu app will come over to EAH sometime in the future!
Senamun wrote
)
Senamun wrote :-
That's not my experience. I promoted and then watched a 1.11 task and it sat on 0.000% for around an hour and 9 mins before going to 0.737%. There was no progress to over 7% before dropping back to 0.7%. I've observed two more iterations to 1.708% at 1:17 and 2.679% at 1:25. This is 0.971% every 8 minutes which is pretty much precisely what this machine does with v1.09 tasks. You had me worried for a bit about going to 7% and then dropping back :-).
Bernd wrote :-
I never saw a task sitting on 100% done and still running - even for a few seconds. Mine would sit on something like 99.029%. They might take quite a while to tick over to 100% but that's a lot less concerning than actually seeming to be at exactly 100%.
I think you've traded one 'problem' for another. I think it might be more concering for less experienced people to see a newly started task sit at 0.000% for such a long time. At least when sitting on 99.07% you know the thing has been progressing and probably just needs more time to finish. There would be some reluctance to 'interfere' with a task so close to finishing. If people see tasks sitting at 0% for a long time, they might decide there must be something wrong and abort them.
With 104 sky points (103 intervals) in a standard task (ie 0.9708738% per interval) I guess the 'trick' you are using is to start the progress at -8% and increment it by 0.9708738% every time a checkpoint is written and to display the negative numbers (-8.0%, -7.029%, -6.058% ... -0.233) as 0.000%. The next in the sequence is 0.737% so that explains the 'odd' percentage I saw after 1:09mins.
I'm wondering if you've considered adjusting the % increment rather than starting from -8%. You could assume 8% more sky points (say 112 instead of 104) and work out the increment per interval to be 0.901% rather than 0.971%. That way you could start seeing progress increments as normal but they would stop at around 92.2% when the follow-up stage started. However you could keep adding the 0.901% increments at calculated intervals to keep the punters happy that 'progress' was being made, even if checkpoints weren't actually being written.
I'm not asking you to do anything as I understand your time constraints. Unless other tweaks occurred as well, I'd have been quite happy to have stayed on 1.09 :-). I'll also be happy to be on 1.11 now that I understand what's happening with the protracted 0.000% progress :-).
EDIT: Of course, if the progress interval were to be set at 0.901% and the last checkpoint was written around 92.2% with 'simulated checkpoints' after that, you do stand to lose quite a bit of crunching if you stop after any subsequent progress value greater than 92.2%.
Also, if I'm correct above in my assumptions of how 1.11 is working, progress will stop at 92% and then jump to 100% at the end of the follow-up calculations. I'll be interested to come back and watch the 1.11 task when it gets close to the end. It should get there around 8.00PM tonight.
Cheers,
Gary.
RE: Currently FGRP is not
)
This still appears to be an issue with the new app version, unless I am missing something. Since I am running 100% GPU's on one machine, the additional downloading of CPU versions is a waste of time and resources. So hopefully this is still "on the radar" to be fixed.
Thanks!
RE: Currently FGRP is not
)
Should be fixed now.
BM
BM
RE: That's not my
)
The same as before just happened again. About 50 minutes to 7% or so and then drop to .793. Subsequent intervals are just a couple of minutes. Run time of the first file in total was around 37000 seconds on a single task. (both GPU's are also running one task at the same time). The 1.09 task was about the same runtime so even though i noticed the drop in total time there was not much difference.
I have to add these were the first completed FGRP 3 CPU tasks on my new machine. What does surprise me is the runtime. On my previous MBPro, which was less powerful, the runtime was mostly under 28000 seconds for a task. That was 1.09. I have not been doing 1.11 wu's on the MBPro after getting the new machine. No idea where the extra 3 hours come from on a quicker machine.
Hallo! I´m runnung a
)
Hallo!
I´m runnung a quadcore non HT CPU intel i5 4430. Before the GPU-version of FGRP3 I had allway 3 tasks running of FGRP3 and 1 of BRP5 on the GPU which gave an CPU-load of at all about 83%. With the new FGRP3 version 1.11 I´ve running only one task for CPU and 1 task for GPU giving at all about 52% of CPU-load. That´s too low. I hope it will become possible to choose whether to crunch GPU or CPU version of FRP3 tasks. Meanwhile I disabled FGRP3 tasks.
Kind regards and happy crunching
Martin