This seems better. Last job finished in just less than 7 hours, giving 238.81 points, which should be rather normal. Keep up the good work.
fgrp4_test_48.0_0_-9.32e-10_0 197189388 25 Aug 2014 16:49:58 UTC 26 Aug 2014 0:41:58 UTC Completed and validated 24,652.29 24,107.27 299.92 238.81 Gamma-ray pulsar search #4 v1.03 (FGRP4-Beta)
fgrp4_test_16.0_0_-8.48e-10_3 196905969 23 Aug 2014 23:24:39 UTC 24 Aug 2014 0:25:25 UTC Completed and validated 2,782.38 2,740.89 35.26 2.58 Gamma-ray pulsar search #4 v1.03 (FGRP4-Beta)
Everything had been prepared for officially launching FGRP4 (e.g. non-Beta application versions). However there occurred a few complications on the server side which require more investigation, i.e. more time and possibly more testing.
Due to the delay of FGRP4 and as the GW search S6CasA is also running out of work, the database is pretty loaded, as the scheduler tries to find the remaining S6CasA work to fulfill CPU work request. To give it some relief, we are currently sending out BRP4 work to CPUs until FGRP4 is ready for public launch.
... a few complications on the server side which require more investigation, i.e. more time and possibly more testing.
OK, thanks very much for letting us know. I notice that FGRP3 seems to have finished (0 tasks ready to send) so I wish you good luck in sorting the remaining issues with FGRP4.
I had a host run a couple of the 'full size' beta tasks recently. They took significantly longer than a 'full size' FGRP3 task - around 40% longer. The credit award was slightly less than for FGRP3. No doubt you are already aware of this and will be making adjustments in due course when things settle down and you get some time.
They took significantly longer than a 'full size' FGRP3 task - around 40% longer. The credit award was slightly less than for FGRP3.
I confirm that on my flotilla the "80" series FGRP4 tasks took materially longer than GRP3 tasks on the same machines, so the credit award is considerably below breakeven by that particular comparison.
I can't be very accurate, as my machines have been on a temperature-dependent throttling regime which fuzzes up comparisons.
I too am getting these errors on Gamma-ray pulsar search #3 v1.11 (FGRPopencl-ati)
No you're not! We're talking about "maximum time limit exceeded" in FGRP4 beta and you're talking about a memory allocation problem in FGRP3.
Try looking at this message and see if the solution there works for you.
I am not running Ubuntu's BOINC package. Rather I downloaded BOINC and installed per their instructions.
The referenced "post/message" assumes the installation of the SDK for AMD I believe because I cannot find the file that this message references/modifies. Therefore I modified /etc/profile adding the following line:
export GPU_MAX_HEAP_SIZE=100
I stopped BOINC. exited the user I run BOINC under and logged back in causing /etc/profile to be re-read and to pick up the "export GPU_MAX_HEAP_SIZE=100" line I added. I restarted BOINC. I will now monitor to see if this procedure fixes the memory issue noted in my original post.
The above change to /etc/profile and the login/out seems to have fixed this error. I have had not additional errors in the last ~7 days.
Yesterday I issued the first 1000 "real" FGRP4 WUs (names starting with "LATeah0001D" instead of "fgrp4_test", runtimes should be comparable to "full" FGRP3 tasks, so we left credit at the same level (660 for a "full" task, shorter task will get proportionally less, deadline now the usual 14d). What we got back so far looks pretty promising, so I started continuous workunit production.
This marks the official launch of the real FGRP4 run.
There appears to be something new after all on this, for me at least. I just got my first two FGRP4 units validated, and the credits allocated for them are different, kind of variable. While around the usual 660, one is less at 647.48, one is more with 693. I have never seen this happening, except for end of batch crunches (always less). Are these in that realm, or is it something else? I think it cannot possibly be based on (CPU) processing, as that´s different between me and my wingmen, but we got the same credits.
Note that I´m not complaining about the amount of credits, if I cared too much about that, I´d be doing something else. I´m just curious and cannot seem to remember any info on this, except Credit New being tested on Albert at Home.
What got above 660 cr was most likely a "short end" of "fgrp4_test" tasks, not a regular "LATeah0001D" one. While the regular tasks has been set up to have roughly the same runtimes as FGRP3 tasks, "fgrp4_test" task will (accidentally) run 2-3x as long. Therefore for the last charges of "fgrp4_test" tasks we doubled the maximum credit to make up for that.
This seems better. Last job
)
This seems better. Last job finished in just less than 7 hours, giving 238.81 points, which should be rather normal. Keep up the good work.
fgrp4_test_48.0_0_-9.32e-10_0 197189388 25 Aug 2014 16:49:58 UTC 26 Aug 2014 0:41:58 UTC Completed and validated 24,652.29 24,107.27 299.92 238.81 Gamma-ray pulsar search #4 v1.03 (FGRP4-Beta)
fgrp4_test_16.0_0_-8.48e-10_3 196905969 23 Aug 2014 23:24:39 UTC 24 Aug 2014 0:25:25 UTC Completed and validated 2,782.38 2,740.89 35.26 2.58 Gamma-ray pulsar search #4 v1.03 (FGRP4-Beta)
With best regards
Bent, Oslo, Norway
Everything had been prepared
)
Everything had been prepared for officially launching FGRP4 (e.g. non-Beta application versions). However there occurred a few complications on the server side which require more investigation, i.e. more time and possibly more testing.
Due to the delay of FGRP4 and as the GW search S6CasA is also running out of work, the database is pretty loaded, as the scheduler tries to find the remaining S6CasA work to fulfill CPU work request. To give it some relief, we are currently sending out BRP4 work to CPUs until FGRP4 is ready for public launch.
BM
BM
RE: ... a few complications
)
OK, thanks very much for letting us know. I notice that FGRP3 seems to have finished (0 tasks ready to send) so I wish you good luck in sorting the remaining issues with FGRP4.
I had a host run a couple of the 'full size' beta tasks recently. They took significantly longer than a 'full size' FGRP3 task - around 40% longer. The credit award was slightly less than for FGRP3. No doubt you are already aware of this and will be making adjustments in due course when things settle down and you get some time.
Thanks for all your efforts.
Cheers,
Gary.
Gary Roberts wrote:They took
)
I confirm that on my flotilla the "80" series FGRP4 tasks took materially longer than GRP3 tasks on the same machines, so the credit award is considerably below breakeven by that particular comparison.
I can't be very accurate, as my machines have been on a temperature-dependent throttling regime which fuzzes up comparisons.
I just issued the first 1000
)
I just issued the first 1000 workunits (2000 tasks) that will be run by the 1.04 app version, i.e. "non-Beta".
BM
BM
RE: RE: RE: I too am
)
The above change to /etc/profile and the login/out seems to have fixed this error. I have had not additional errors in the last ~7 days.
Yesterday I issued the first
)
Yesterday I issued the first 1000 "real" FGRP4 WUs (names starting with "LATeah0001D" instead of "fgrp4_test", runtimes should be comparable to "full" FGRP3 tasks, so we left credit at the same level (660 for a "full" task, shorter task will get proportionally less, deadline now the usual 14d). What we got back so far looks pretty promising, so I started continuous workunit production.
This marks the official launch of the real FGRP4 run.
BM
BM
There appears to be something
)
There appears to be something new after all on this, for me at least. I just got my first two FGRP4 units validated, and the credits allocated for them are different, kind of variable. While around the usual 660, one is less at 647.48, one is more with 693. I have never seen this happening, except for end of batch crunches (always less). Are these in that realm, or is it something else? I think it cannot possibly be based on (CPU) processing, as that´s different between me and my wingmen, but we got the same credits.
Note that I´m not complaining about the amount of credits, if I cared too much about that, I´d be doing something else. I´m just curious and cannot seem to remember any info on this, except Credit New being tested on Albert at Home.
What got above 660 cr was
)
What got above 660 cr was most likely a "short end" of "fgrp4_test" tasks, not a regular "LATeah0001D" one. While the regular tasks has been set up to have roughly the same runtimes as FGRP3 tasks, "fgrp4_test" task will (accidentally) run 2-3x as long. Therefore for the last charges of "fgrp4_test" tasks we doubled the maximum credit to make up for that.
BM
BM
I have one of my hosts set up
)
I have one of my hosts set up for just running these tasks.
No problems at all (other than getting more than 7 tasks unless I manually ask until it stops letting me have any which ended at 17 tasks)
Right now I have 2 versions of the "FGRP4"
The longer one average time is 47,500 seconds and 693 credits
The shorter ones average time is 9,800 seconds and 150.86 credits
The finished tasks may have had the BRP Search (Arecibo) tasks running along with them.
This is just on my older PhenomII X3 720 since I borrowed its 650Ti to run GPU's in another quad-core.
Tonight I only loaded the 17 "FGRP4" tasks to see how they run alone (sort of since I also have a vLHC task running too)
http://einsteinathome.org/host/11652712/tasks