@Claggy = I see. Well with luck, this NVIDIA Kepler will give me some breathing room. I still dunno what if anything *I can do re: my i5 and Intel graphics that could have any bearing on the project(s)- especially since I don't connect my monitor to it. Hoping Windows and Boinc and *everybody can get to it for some benefit if helpful.
Appreciate it Claggy - found your post and got the thing. Will give it a spin. Of course makes NO sense to my driver update hound sensibilities but what the heck I'll give it a whirl and see if it benefits and if fails rollback to where I was (latest Intel)- I mean, at least with *this driver onboard in my windows driver store cache along with the others would hope windows/intel/boinc could just find what they need without me. One day at a time here.
PS - do you advise updating BOINC to new release, or leave it alone? Dunno if it would benefit these bugs or not -
Boinc 7.4.36 is better than 7.4.27, it at least has the backup project 0 resource share problem fixed, as well as a few other fixes and changes:
Quote:
•Attaching to World Community Grid
•Back-up projects (0 Resource Share)
•Better detection of notice updates (reduces the number of system notifications)
•Suspending GPUs should not suspend Bitcoin Miners
•Increasing the maximum number of coprocessor devices to 64
•Updates to OpenSSL(1.0.1j) and LibCurl?(7.39.0)
OK thanks for that. Next question: what about Lunatics new installer? The readme sounds like it may circumvent some of the driver issues between my CPU and both GPUs by itself, as far as assigning optimized apps per my config on both Einstein *and SETI (if there *is such a thing) ie eliminating probs before they can occur. PS still waiting for my new GPU *correction UPS just handed it to me! SO - my plan is to shutdown now and install new Corsair PS and this GT 640 2048. Question is, should I leave it at that for now and just let Boinc see my new hardware (( shouldn't I exit Boinc in the first place?- I know it'll take 2-3 reboots to settle in the new card and driver updates ?)) - and just let SETI run a bit first, then Restore/Resume Einstein with the Run with my preferences Activity switch so it'll behave, then add/Resume Rosetta...kinda in that order is what I'm thinking.
53 tasks pending Validation at SETI (you told me that was a wingmen thing-sorry still bugs me!
OK installed new Boinc after getting the GT 640 settled and updated to NVIDIA 9.18.13.4709 (347.09) whql dated 12.12.2014
Restarted Boinc and SETI had happily loaded me up with a bunch of cuda42's and one cuda50 plus it launched a fractional CPU + 1 NVIDIA job like Einstein had done earlier. Hmm and now a cuda32.
Im noting my new card sez OpenCL 1.1
And I know my CPU has 1.1 and 1.2 plus SSE <4.2
Intel Driver hunt didn't pan on Intel site - it listed .3628 as closest to .3621 that u recommended as vetted. And the readme within the download at forum link sez its for 3rd and 4th gen i5's (my 2500 is a 2nd gen *they say and I can't make any sense of the bridge and core renaming going on - every util I run sez I'm a Sandy bridge - dunno if it's Haswell or exactly which HD graphics it is; I suspect 2000. The board is an Intel DZ75ML-45K with the 9.4.0.1027 chipset driver
So, I'm just leary of attempting the .3621 driver and cutting Einstein loose.
But if you *think it'll work as advertised.... I'll give it a go
Guess I can try and if it does yay -
I did disable the Intel IGD in my BIOS so I could setup new NVIDIA. Can reboot and turn it back on and try the 3621 driver install
Next stop is whether to avail Lunatics.
And the readme within the download at forum link sez its for 3rd and 4th gen i5's (my 2500 is a 2nd gen *they say and I can't make any sense of the bridge and core renaming going on - every util I run sez I'm a Sandy bridge - dunno if it's Haswell or exactly which HD graphics it is; I suspect 2000
Sorry, didn't realise you had sandybridge, that CPU too early for OpenCL support for the Intel GPU, need ivybridge or later, you can still get find drivers to enable OpenCL support for the CPU (Not that any projects use that yet)
Hmm - Intel ARK specs CPU at Open CL 1.1 and 1.2 onboard plus the SSE <4.2 complement. And Boinc is posting OpenCL 1.1 for my NVIDIA under my computers
At any rate do I skip the 3621 then and just verify Intel latest (19.xxxxxx) for the graphics and see what happens at Einstein?
Actually, PC was pretty unhappy when I re-enabled the Intel IGD so I just disabled it again. The OpenCL 1.1 and 1.2 and SSE's are all on the chip anyway.
NVIDIA boasting OpenGL 4.xx and OpenCL 1.1
I've seen SSE and SSE2 on Astropulses at SETI and the GravWav S6 jobs at Einstein.
My beef w Einstein is their seeming lack of respect with my Preferences ie. hogging my Resources and interfering with my SETI queue. I've set them at 50(20%) and have SETI at 200(80%) but E activity doesn't appear to jive with that. The S6bucket jobs are huge. Binaries not far behind and it just resumed chewing on one. Sigh - then again I'm still getting used to this stuff. Sorry for the whine.
My beef w Einstein is their seeming lack of respect with my Preferences ie. hogging my Resources and interfering with my SETI queue. I've set them at 50(20%) and have SETI at 200(80%) but E activity doesn't appear to jive with that. The S6bucket jobs are huge. Binaries not far behind and it just resumed chewing on one. Sigh - then again I'm still getting used to this stuff. Sorry for the whine.
Maybe you'd like to re-evaluate your 'beef' once you think through and understand how things work.
No individual project can disrespect your preference settings. The first thing you need to understand is that individual projects have no say in what work is requested and when it will be scheduled to run. Both of these things are entirely up to BOINC. So if you have a low resource share for Einstein and yet you have a lot of Einstein work, you have to ask yourself why that might be? There are lots of possible factors in the mix but here is one of the common scenarios.
Let's assume you have a rather large work cache setting - several days or more. Most people who run Seti tend to have this for fairly obvious reasons. BOINC will try to keep that large cache full and will most likely request work from the project to which you have given the highest resource share, unless it really is time for one of the 'lesser' projects to top up. So BOINC asks Seti for work but unfortunately Seti can't supply at the time of the request. I believe this tends to happen quite a lot.
When rejected by Seti, BOINC is likely to turn to a lesser project and get the entire shortfall from that project, because BOINC is really determined to fill the cache. This can easily lead to a situation where a 'reliable' lesser project (like Einstein, which always has work) supplies far more work than is prudent, if your real aim is to do mostly Seti. So when BOINC is forced (at some later stage) to put Einstein in 'panic' mode just to get the excess work done, who do you think should take the 'blame'? Unfortunately, the reliable lesser project always seems to be the one to cop it.
Einstein's only 'sin' was to always supply work when asked by BOINC. So, should we really blame BOINC for asking? Well, we might, if we're not really thinking it through. The real blame could probably go to Seti for not always supplying when asked. But that would be a cop out as well, since you can manage BOINC to better handle the Seti situation. If you had really low cache settings, say 0.5 days max, this would severely restrict BOINC from ever loading up with lots of 'lesser project' tasks. If Seti is 'out' the lesser project will keep supplying for as long as it takes. Once Seti has work again, all future work requests will go to Seti because of its higher resource share. BOINC will keep favouring Seti until the resource shares have been honoured. In the longer term, BOINC will always attempt to honour your resource shares.
If you really understand this, then what does it matter if BOINC does 2 weeks of Einstein tasks because Seti was out for that time? Once Seti can supply, BOINC will only ask Seti (for many weeks) until the balance is redressed. And if you want to manage work flow around known future Seti outages, you can always bump the work cache from 0.5 days to several days, just before the known outage kicks in. Once you have the work, set your cache back to 0.5 days to prevent BOINC from asking for any Einstein work until it really is time to get some.
There are other strategies as well to better control BOINC - things like 'backup' projects (resource share of zero) but I have no experience with this so I wouldn't try to offer advice about it. Using a backup project will not allow you to set a specific resource share - like your current 80/20 mix. If you really want Einstein to have a certain share, then managing your cache settings to cover the outages (as suggested above) would be the way to get the best results.
@Claggy = I see. Well with
)
@Claggy = I see. Well with luck, this NVIDIA Kepler will give me some breathing room. I still dunno what if anything *I can do re: my i5 and Intel graphics that could have any bearing on the project(s)- especially since I don't connect my monitor to it. Hoping Windows and Boinc and *everybody can get to it for some benefit if helpful.
Appreciate it Claggy - found
)
Appreciate it Claggy - found your post and got the thing. Will give it a spin. Of course makes NO sense to my driver update hound sensibilities but what the heck I'll give it a whirl and see if it benefits and if fails rollback to where I was (latest Intel)- I mean, at least with *this driver onboard in my windows driver store cache along with the others would hope windows/intel/boinc could just find what they need without me. One day at a time here.
PS - do you advise updating
)
PS - do you advise updating BOINC to new release, or leave it alone? Dunno if it would benefit these bugs or not -
RE: PS - do you advise
)
Boinc 7.4.36 is better than 7.4.27, it at least has the backup project 0 resource share problem fixed, as well as a few other fixes and changes:
Claggy
OK thanks for that. Next
)
OK thanks for that. Next question: what about Lunatics new installer? The readme sounds like it may circumvent some of the driver issues between my CPU and both GPUs by itself, as far as assigning optimized apps per my config on both Einstein *and SETI (if there *is such a thing) ie eliminating probs before they can occur. PS still waiting for my new GPU *correction UPS just handed it to me! SO - my plan is to shutdown now and install new Corsair PS and this GT 640 2048. Question is, should I leave it at that for now and just let Boinc see my new hardware (( shouldn't I exit Boinc in the first place?- I know it'll take 2-3 reboots to settle in the new card and driver updates ?)) - and just let SETI run a bit first, then Restore/Resume Einstein with the Run with my preferences Activity switch so it'll behave, then add/Resume Rosetta...kinda in that order is what I'm thinking.
53 tasks pending Validation at SETI (you told me that was a wingmen thing-sorry still bugs me!
OK installed new Boinc after
)
OK installed new Boinc after getting the GT 640 settled and updated to NVIDIA 9.18.13.4709 (347.09) whql dated 12.12.2014
Restarted Boinc and SETI had happily loaded me up with a bunch of cuda42's and one cuda50 plus it launched a fractional CPU + 1 NVIDIA job like Einstein had done earlier. Hmm and now a cuda32.
Im noting my new card sez OpenCL 1.1
And I know my CPU has 1.1 and 1.2 plus SSE <4.2
Intel Driver hunt didn't pan on Intel site - it listed .3628 as closest to .3621 that u recommended as vetted. And the readme within the download at forum link sez its for 3rd and 4th gen i5's (my 2500 is a 2nd gen *they say and I can't make any sense of the bridge and core renaming going on - every util I run sez I'm a Sandy bridge - dunno if it's Haswell or exactly which HD graphics it is; I suspect 2000. The board is an Intel DZ75ML-45K with the 9.4.0.1027 chipset driver
So, I'm just leary of attempting the .3621 driver and cutting Einstein loose.
But if you *think it'll work as advertised.... I'll give it a go
Guess I can try and if it does yay -
I did disable the Intel IGD in my BIOS so I could setup new NVIDIA. Can reboot and turn it back on and try the 3621 driver install
Next stop is whether to avail Lunatics.
RE: And the readme within
)
Sorry, didn't realise you had sandybridge, that CPU too early for OpenCL support for the Intel GPU, need ivybridge or later, you can still get find drivers to enable OpenCL support for the CPU (Not that any projects use that yet)
Claggy
Hmm - Intel ARK specs CPU at
)
Hmm - Intel ARK specs CPU at Open CL 1.1 and 1.2 onboard plus the SSE <4.2 complement. And Boinc is posting OpenCL 1.1 for my NVIDIA under my computers
At any rate do I skip the 3621 then and just verify Intel latest (19.xxxxxx) for the graphics and see what happens at Einstein?
Actually, PC was pretty
)
Actually, PC was pretty unhappy when I re-enabled the Intel IGD so I just disabled it again. The OpenCL 1.1 and 1.2 and SSE's are all on the chip anyway.
NVIDIA boasting OpenGL 4.xx and OpenCL 1.1
I've seen SSE and SSE2 on Astropulses at SETI and the GravWav S6 jobs at Einstein.
My beef w Einstein is their seeming lack of respect with my Preferences ie. hogging my Resources and interfering with my SETI queue. I've set them at 50(20%) and have SETI at 200(80%) but E activity doesn't appear to jive with that. The S6bucket jobs are huge. Binaries not far behind and it just resumed chewing on one. Sigh - then again I'm still getting used to this stuff. Sorry for the whine.
RE: My beef w Einstein is
)
Maybe you'd like to re-evaluate your 'beef' once you think through and understand how things work.
No individual project can disrespect your preference settings. The first thing you need to understand is that individual projects have no say in what work is requested and when it will be scheduled to run. Both of these things are entirely up to BOINC. So if you have a low resource share for Einstein and yet you have a lot of Einstein work, you have to ask yourself why that might be? There are lots of possible factors in the mix but here is one of the common scenarios.
Let's assume you have a rather large work cache setting - several days or more. Most people who run Seti tend to have this for fairly obvious reasons. BOINC will try to keep that large cache full and will most likely request work from the project to which you have given the highest resource share, unless it really is time for one of the 'lesser' projects to top up. So BOINC asks Seti for work but unfortunately Seti can't supply at the time of the request. I believe this tends to happen quite a lot.
When rejected by Seti, BOINC is likely to turn to a lesser project and get the entire shortfall from that project, because BOINC is really determined to fill the cache. This can easily lead to a situation where a 'reliable' lesser project (like Einstein, which always has work) supplies far more work than is prudent, if your real aim is to do mostly Seti. So when BOINC is forced (at some later stage) to put Einstein in 'panic' mode just to get the excess work done, who do you think should take the 'blame'? Unfortunately, the reliable lesser project always seems to be the one to cop it.
Einstein's only 'sin' was to always supply work when asked by BOINC. So, should we really blame BOINC for asking? Well, we might, if we're not really thinking it through. The real blame could probably go to Seti for not always supplying when asked. But that would be a cop out as well, since you can manage BOINC to better handle the Seti situation. If you had really low cache settings, say 0.5 days max, this would severely restrict BOINC from ever loading up with lots of 'lesser project' tasks. If Seti is 'out' the lesser project will keep supplying for as long as it takes. Once Seti has work again, all future work requests will go to Seti because of its higher resource share. BOINC will keep favouring Seti until the resource shares have been honoured. In the longer term, BOINC will always attempt to honour your resource shares.
If you really understand this, then what does it matter if BOINC does 2 weeks of Einstein tasks because Seti was out for that time? Once Seti can supply, BOINC will only ask Seti (for many weeks) until the balance is redressed. And if you want to manage work flow around known future Seti outages, you can always bump the work cache from 0.5 days to several days, just before the known outage kicks in. Once you have the work, set your cache back to 0.5 days to prevent BOINC from asking for any Einstein work until it really is time to get some.
There are other strategies as well to better control BOINC - things like 'backup' projects (resource share of zero) but I have no experience with this so I wouldn't try to offer advice about it. Using a backup project will not allow you to set a specific resource share - like your current 80/20 mix. If you really want Einstein to have a certain share, then managing your cache settings to cover the outages (as suggested above) would be the way to get the best results.
Cheers,
Gary.