Seems that Ubuntu Linux and these work units don't get along. Now 12438349 is spitting them all back as errors like one of my other Linux boxes did earlier.
But Mac OS Sierra seems to handle them ok--although they haven't validated yet, so we'll see.
Different WUs have very different appetite for RAM. 144 Hz ~ 165 MByte 1404 Hz ~ 1.5 GByte
Nice catch 22, I didn't even look at those.
This could and will present problems. It looks like they start at low memory and build to 1.4GB per work unit on some of these GW.
Not a big deal if you only have 2-4 running but I just experimented and it showed to me that the base line setting for BOINC manager limits RAM use to 50% of all ram available.
I choose to go for 32 GB in each of my machines but with the 50% cap in place my 16 core was running only 11 of 16 with 2 waiting to run. ( I allowed for all cores to be use). I overcame this restriction by increasing the percentage of usable RAM to 90%.
My concern is some machines may have lower amounts of RAM (16 or 8) and may quickly run out of RAM for the work units.
Kind of reminds me of the Seti@home work units that were hogging the RAM on the GPUs (this of course is system RAM here on Einstein)
But it does explain why I had numerous Parkes cuda 55 error out once the GW started to crunch. They didn't have any free RAM to use for their calcualtions.
Good news. I briefly enabled new work download of the Multi-directed continuous GW sort on the same host which got zero partner tasks issued the first 48 hours after the first batch. All five tasks in this second batch got partner tasks issued within an hour and five minutes. Better yet, the seven originally forlorn tasks all have now had partner tasks issued at various times between 17:00 and 21:00 UTC on October 14. So at least from my observation point the failure to issue second tasks problem is solved.
If this was at all a wide-spread problem, possibly there will be more fulfilled quorums on which validation might be usefully attempted by sometime Saturday.
I have a good flow of the new Multi-Directed GW Search tasks coming in on my hosts and am seeing similar memory usage to what 22 reported ranging from approximately 214 MB to 1.5 GB per task. There are 24 ~1431 Hz tasks running on my AMD host with just under 16GB of total memory usage.
I had 1 computer reboot due to an unspecified error. Given that it was using a large amount of RAM plus another 7GB for the system, I think it ran out of available RAM and forced a reboot. I'll keep an eye on it and see what it does.
No validations here yet. The server status page shows zero validations, though it might not be up to speed for this application yet. The same page lists the validators for both the G and the CV flavor as "disabled". I think I recall that during the first phases of rollout of a new application they often don't put the validator on automatic until a few manually-started runs show desired results.
Seems that Ubuntu Linux and
)
Seems that Ubuntu Linux and these work units don't get along. Now 12438349 is spitting them all back as errors like one of my other Linux boxes did earlier.
But Mac OS Sierra seems to handle them ok--although they haven't validated yet, so we'll see.
Different WUs have very
)
Different WUs have very different appetite for RAM. 144 Hz ~ 165 MByte 1404 Hz ~ 1.5 GByte
22 wrote:Different WUs have
)
Nice catch 22, I didn't even look at those.
This could and will present problems. It looks like they start at low memory and build to 1.4GB per work unit on some of these GW.
Not a big deal if you only have 2-4 running but I just experimented and it showed to me that the base line setting for BOINC manager limits RAM use to 50% of all ram available.
I choose to go for 32 GB in each of my machines but with the 50% cap in place my 16 core was running only 11 of 16 with 2 waiting to run. ( I allowed for all cores to be use). I overcame this restriction by increasing the percentage of usable RAM to 90%.
My concern is some machines may have lower amounts of RAM (16 or 8) and may quickly run out of RAM for the work units.
Kind of reminds me of the Seti@home work units that were hogging the RAM on the GPUs (this of course is system RAM here on Einstein)
But it does explain why I had numerous Parkes cuda 55 error out once the GW started to crunch. They didn't have any free RAM to use for their calcualtions.
Off to change my max % on my machines.
Thanks again 22
Zalster
Good news. I briefly enabled
)
Good news. I briefly enabled new work download of the Multi-directed continuous GW sort on the same host which got zero partner tasks issued the first 48 hours after the first batch. All five tasks in this second batch got partner tasks issued within an hour and five minutes. Better yet, the seven originally forlorn tasks all have now had partner tasks issued at various times between 17:00 and 21:00 UTC on October 14. So at least from my observation point the failure to issue second tasks problem is solved.
If this was at all a wide-spread problem, possibly there will be more fulfilled quorums on which validation might be usefully attempted by sometime Saturday.
I have a good flow of the new
)
I have a good flow of the new Multi-Directed GW Search tasks coming in on my hosts and am seeing similar memory usage to what 22 reported ranging from approximately 214 MB to 1.5 GB per task. There are 24 ~1431 Hz tasks running on my AMD host with just under 16GB of total memory usage.
I had 1 computer reboot due
)
I had 1 computer reboot due to an unspecified error. Given that it was using a large amount of RAM plus another 7GB for the system, I think it ran out of available RAM and forced a reboot. I'll keep an eye on it and see what it does.
Anyone have any
)
Anyone have any Multi-Directed WU's that have validated?
I have several that have completed the quorum of 2, but still remain in pending pile.
Can't tell. Since I'm running
)
Can't tell. Since I'm running Parkes cuda55 it takes WAY too much effort to just locate a Gravity Wave in the list of validation... Sorry
No validations here yet. The
)
No validations here yet. The server status page shows zero validations, though it might not be up to speed for this application yet. The same page lists the validators for both the G and the CV flavor as "disabled". I think I recall that during the first phases of rollout of a new application they often don't put the validator on automatic until a few manually-started runs show desired results.
What is the difference
)
What is the difference between the "G" type and the "CV" type of work units?
Is it a CPU speed thing as in the previous tuning run we did?
At the moment I can only think that CV stands for "Can't Validate" as nothing has validated as yet.
Conan