• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

BOINC

Also maybe try upping the resource share? Try giving it something ridiculous perhaps?
 
Since GPUGrid is GPU only, it shouldn't be affected by WCG's work load...
 
Touché again! I was merely thinking there may be a correlation between resource share and what downloads the majority of the buffer.
 
Naw...the client will ask for work from the project and fill up accordingly. Since it won't get GPU work from WCG, it will fill up GPUGrid. Since it won't get CPU work from GPUGrid, it will fill up WCG CPU work. They compliment each other quite nicely like that. So, you "should" get your full cache of work for both GPU and CPU. At least that is how it is designed.

Now if she had multiple GPU projects, that is where the resource share would kick in and then attempt to download accordingly.
 
Is there a folder I can check to see what GPUGRID WUs were downloaded last night? Would be nice to know if changing the cache setting is even doing anything. Given that I only have a 5 hour upload/download window each night I'm thinking this issue will only get worse if I upgrade my 560Ti cards to the latest and greatest. Maybe if POEM comes out with GPU WUs, that can fill the gaps GPUGRID is leaving.
 
I believe they are under c:\Program Data\Boinc\ unless you have changed the data directory. Then from there you may have to look in the projects folder. Probably in the slots folders. But I'm not positive since the system I have here runs on minimum cache and reports work units immediately when finished.
 
Android version of BOINC officially released 7.2.39 which supports account managers like BOINCStats BAM! and the notes say it supports x86 versions. I will be setting up a VM or two to see how well it installs...then we just need projects to make Android capable x86 apps. I'm not sure if the Linux work units will work or not.

https://play.google.com/store/apps/details?id=edu.berkeley.boinc&hl=en

I am going to install Android 4.2 x86 in a virtual machine to try and test it.

If others want to test it, here is where I'm getting my ISO's: http://www.android-x86.org/download

QCN also now runs on Android devices. http://qcn.stanford.edu/sensor/forum_thread.php?id=1040 Since it is NCI, everyone running the Android devices should attach it.
 
Last edited:
ChelseaOilman said:
SETI should point their antenna at Stanford. More likely to find aliens there. :)
Click to expand...

Doubtful. Vijay and David Anderson both have similar issues. Dr. Anderson created a terrible point system (Credit New) and refuses to fix it. I've never contacted the man, but the volunteers seem to have a lot of mixed feelings on the man. BOINC is his baby and so you gotta get him on board if you want things addressed in both the client and server software. No SETI, no BOINC.
 
But yes, many aliens and things from other planets there trying to control the world with their crazy whimsicle ideas.

The x86 android apps should be fairly easy to port, just minor changes. But how common are Intel's processors in android devices? Hopefully more so, starting with the next Nexus tablet. Fingers crossed!
 
Not common at all really. However, if AMD's ARM options truly make headway, it could be a really good thing. Since those processors will be 64bit, I'm hoping Google will make a 64bit version of Android. Many nay-sayers will say that Android doesn't need 64 bit yet because most devices don't have 4GB Ram let alone a need for more. But there are definitely BOINC uses that could totally be put in place. For example, VINA based apps like those at WCG see up to 30% speed increases running under Linux. I think more people would run VM's if the OS was simple and familiar, simple to install BOINC, simple to update BOINC, and have the option to auto update official releases. Older versions of Android (I think version 2's) only needed 32MB Ram. I'm not sure what version 4.2 needs, but I'm guessing it is still pretty light.

Here is some conflicting info on the status of 64bit Android:

Intel is ready: http://www.androidauthority.com/intel-64-bit-android-for-atom-332902/
Nobody is ready: http://arstechnica.com/gadgets/2014...-64-bit-android-but-theres-a-long-road-ahead/
 
Last edited:
Gilthanis said:
QCN also now runs on Android devices. http://qcn.stanford.edu/sensor/forum_thread.php?id=1040 Since it is NCI, everyone running the Android devices should attach it.
Click to expand...
Okay, am I the only one who wonders what the point of putting this on mobile is? I tend to plug my phone in when driving in my truck (to run more BOINC, of course), and some of the roads I drive on will make them think there's a 6.0 quake every M-F around 8:15 am!
 
Jathanis said:
Okay, am I the only one who wonders what the point of putting this on mobile is? I tend to plug my phone in when driving in my truck (to run more BOINC, of course), and some of the roads I drive on will make them think there's a 6.0 quake every M-F around 8:15 am!
Click to expand...

The intent was that users would not run their devices while actually mobile but rather when the device is charging in a non-moving environment. Such as when you go to sleep at night. If you are worried about invalid results while driving, just suspend the app until the device is sitting on a table. They also have a really hard time getting Accelerometer access from most laptop manufacturers. The only way to get a wide network of data is to be able to get it to the masses. The masses aren't buying usb devices for the PC's and not that many people really by Macbooks in the grand scheme of things. Android makes access to the accelerometer quite easy.
 
Congrats to Grandpa for hitting the 100M BOINC mark! What was that, 3 months or so?! :D I should be there by October or so...

Actuall, here's a fun race - who can hit 100M first - me, currently at 68M, or ChelseaOilman, who just joined? looks like it'll be a good 10 month "race" (or can I gasp over the finish line first before I get seriously mowed...)
 
Yeah..I think the BOINC leader board is going to drastically change pretty quick/soon. And I love it. :cool:
 
Well...I think I found out why my 4870 was having problems with drivers crashing causing Windows to crash as well.

http://setiathome.berkeley.edu/forum_thread.php?id=73953&postid=1471561

Setiathome won't send Seti v7 work to hosts running Cat 13.1 either because of an APP runtime 1084.4 compiler Bug, which caused the v7 ATI GPU app to cause driver restarts (under windows),
Click to expand...

I wasn't running SETI, but it is probably related since 13.1 was what I had running. So, maybe I need to give it another chance...
 
Not for nothing, 14.1 beta is finally out. The primary changes are the additions of mantle support, but maybe it'll prove to be a good crunching driver? I just installed it and will let you know if there is any instability, or that compiler bug in seti.
 
What is odd, my 4550 was stable with 13.1 but 4870 was the one crashing. I don't know if it was the work unit (not SETI) or if it was just more strained. Keep me posted if you encounter any issues with 14.1
 
Got my IB GPU working on SETI now, seems to be crunching fine so far (around 15% through its first WU) and it's drawing an extra 5W or so, so that's pretty good. I'll see how it goes, if it stays stable I'll leave it on SETI - even if the points aren't great, it's better than it sitting there doing nothing or constantly crashing on Einstein. Interestingly, I saw somewhere that using the iGPU would require a dummy plug, but I'm not using one and it seems to be fine, so maybe that only applied to older drivers or something.

Had a bit of a move around in the computer/storage room today in preparation for getting the other systems up and running in the very near future. Looks like I have two more quads, a hex, a 6970, GTX 460, GTX 295 and 9800GT to bring to the party, and if I could find another case, one more quad.
 
CaptainUnlikely said:
Got my IB GPU working on SETI now, seems to be crunching fine so far (around 15% through its first WU) and it's drawing an extra 5W or so, so that's pretty good. I'll see how it goes, if it stays stable I'll leave it on SETI - even if the points aren't great, it's better than it sitting there doing nothing or constantly crashing on Einstein. Interestingly, I saw somewhere that using the iGPU would require a dummy plug, but I'm not using one and it seems to be fine, so maybe that only applied to older drivers or something.

Had a bit of a move around in the computer/storage room today in preparation for getting the other systems up and running in the very near future. Looks like I have two more quads, a hex, a 6970, GTX 460, GTX 295 and 9800GT to bring to the party, and if I could find another case, one more quad.
Click to expand...

This is good news Captain. I know I had mentioned rumors stated the IGP needed to be connected to the monitor (so that may have came from me), but that may depend on system too. I know the OptiPlex 7010's at work would only work with IGP and PCIe cards if there was a monitor plugged into the IGP. Even then, you couldn't let the BIOS stay on the automatic option but rather had to tell it to use it as the primary display.
 
I think I read it elsewhere too, basically that without a monitor or dummy plug the GPU just wouldn't do any work. Maybe it does depend on the system though.
I know the need for a dummy plug was eliminated with a driver update for AMD and Nvidia cards so I figured maybe it was a similar thing here as OpenCL Intel GPUs are still relatively new.

Edit: just checked and its first unit is complete with a runtime of 6947 seconds. Validation is inconclusive so no credit yet. Next unit is 10% done so I'll keep an eye on things.
 
Last edited:
For the heavy hitters that are slowly moving over to BOINC, I have recently read people having issues with systems that have more than 32 cores/threads getting work beyond 32 work units. There are two things to try if you end up having this issues.

1. Make sure you are running the 64bit client instead of the 32bit one. Then verify your preferences at the project itself in case there is an option there to limit the number of work units.

2. You can try adding the following to a cc_config.xml file.

<cc_config>
<options>
<ncpus>48</ncpus>
</options>
</cc_config>

48 is just an example for a 48 core machine. Change this number to however many cores you have.
 
LHC@home Six Trac is experimenting with larger work units. Don't be surprised if you see them.
 
Gilthanis said:
For the heavy hitters that are slowly moving over to BOINC, I have recently read people having issues with systems that have more than 32 cores/threads getting work beyond 32 work units. There are two things to try if you end up having this issues.

1. Make sure you are running the 64bit client instead of the 32bit one. Then verify your preferences at the project itself in case there is an option there to limit the number of work units.

2. You can try adding the following to a cc_config.xml file.

<cc_config>
<options>
<ncpus>48</ncpus>
</options>
</cc_config>

48 is just an example for a 48 core machine. Change this number to however many cores you have.
Click to expand...

Just to add a little something to this since it is about 4P boards, Roseta@Home has higher memory requirements and will not run on a i4P (64 threads) with 16GB of memory it uses it all, and then uses all available swap space, I also believe there are some other problems trying to run Roseta on the i4P's but I need to get with tear on this and see what he can figure out there for some reason it will lock up boinc even when it has enough memory.
 
Grandpa_01 said:
Just to add a little something to this since it is about 4P boards, Roseta@Home has higher memory requirements and will not run on a i4P (64 threads) with 16GB of memory it uses it all, and then uses all available swap space, I also believe there are some other problems trying to run Roseta on the i4P's but I need to get with tear on this and see what he can figure out there for some reason it will lock up boinc even when it has enough memory.
Click to expand...

Thanks for the heads up Grandpa. Keep us informed on what you find out.


Too bad you don't have Ready Boost setup...LOL j/k

Also Grandpa, you may even want to add a low memory project like Asteroids to keep those extra cores busy. I believe Asteroids is something really small like maybe 6MB, but I could be totally brain farting. Use WUProp to get a good idea of project requirements. http://wuprop.boinc-af.org/results/ram.py?plateforme=linux&tri=projet&sort=asc

If you want to stay bio/med, Docking is like 12-32 under Linux depending on 32 or 64 bit and I believe SIMAP is even less.
 
Last edited:
Rosetta is definitely a memory hog. I resurrected my 980x and gave rosetta 6 threads to play with. Thank goodness I had 12 gigs of RAM because Rosetta ate up about half it. :eek:
 
I've looking at Rosetta@Home, if I move to Boinc. Can anyone confirm the memory consumption per core? My 4p is running Ubuntu 12.04.
 
From Gilthanis' link above, Rosetta consumes 391.5MB/core on 32 bit and 428.2MB/core on 64 bit, so you should be fine at 0.5GB/core.

Edit: But more wouldn't hurt.
graph_ram.py
 
Keep in mind that BOINC will detect the available memory and if you don't have enough to go around, it will pause some of the work units until memory is freed up. So keep in mind the settings that you set for amount of RAM BOINC has while active and while idle. If you run into idle cores/threads, consider mixing projects since there are many that use much less memory. I will have to look at the proper settings, but there is a way to force BOINC to NOT run more than a certain number of work units of a specific type. I believe it is one of the app_config settings.
 
Gilthanis said:
I will have to look at the proper settings, but there is a way to force BOINC to NOT run more than a certain number of work units of a specific type. I believe it is one of the app_config settings.
Click to expand...

Here is the structure to use in the app_config file:

<app_config>
<app>
<name>name</name>
<max_concurrent>N</max_concurrent>
</app>
</app_config>
 
Last edited:
Uplinger posted the following at WCG: https://secure.worldcommunitygrid.org/forums/wcg/viewthread_thread,36247

We have stopped sending out new work for the CEP2 project. We have been alerted that there is a issue on their server that they are currently working on correcting. This affects the upload of the large data file that is transferred directly back to them. Member will see that 2 things:

1. No new work being downloaded for CEP2.
2. Work that has complete will be stuck in a transferring mode waiting for the large file to upload.

We thank you for your patience as we work towards correcting the issue.

Thanks,
-Uplinger
Click to expand...
 
I was wondering why I had an 80mb transfer that was stuck at 0% for hours. That would explain it.
 
GTX460 and another quad now running. Pointed the GPU at Einstein for now to see how it performs, looks like Einstein has a lot of overtake opportunities for us and my 5770 is already there so this should just about double my output to help out there.

On a side note, the board in that system really has no clue about what CPU it's running. It identifies it properly, but when I checked through the settings it gave the normal vcore at 1.175V, current vcore at 1.475V, without me changing anything. If I enable clock control, it also sets the FSB to 400, instead of the default 333. Odd bugs, but not entirely unexpected, it was never meant to take this CPU after all :p not entirely sure it's reading the temperature correctly either.

I do love my hacked up systems!
 
Collatz is back up and sending out one of the three previous WU types, but there have been some significant changes made:

  • All WU are now OpenCL
  • WUs are taking longer than previous, not word yet on updated point values
  • GPU tasks are reportedly using > 0.9 CPU per WU, causing issues with multi-GPU systems
  • Not currently working on any ATI card 47XX and below due to driver issues
  • CPU OpenCL tasks can now multi-thread, so on an i7, Slicker (Project Admin) claims each WU will run 8X faster, but one WU at a time...
Ongoing discussion here: http://boinc.thesonntags.com/collatz/forum_thread.php?id=1112#18302
 
You must log in or register to reply here.
Back
Top