For the older distros/kernels, the one gotcha might come with what GlibC or similar dependancy. That will have to fall out from user feedback for sure. [If it does, simplest solution might involve a quick rebuild in the earliest distro, supported by the toolkit, via a vm)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

It's up to 15 downloads and still No feedback. That always makes you wonder...
I decided to call success with the GTS 250 and move to newer releases. The existing Ubuntu 15.10 decided to give driver problems switching from AMD to nVidia so I ended up installing a new copy. Then I had the legendary problems trying to get CUDA & OpenCL working with the repository version of 352.63. I did manage to get CUDA to work and that worked OK. Then I switched to the nVidia 358.16 and that gave me OpenCL & CUDA. It seems to be working well and even managed to find a couple obviously errant wingpeople. Still, I'd say this version is a keeper, only a couple inconclusives over a couple days...nice.

Ah, the first Success story. A machine running;
Coprocessors: NVIDIA GeForce GTX 275 (895MB)
Operating System: Linux
2.6.37.6i
BOINC version: 6.10.58
Seems to be working well with the CUDA 42 App, https://setiathome.berkeley.edu/results.php?hostid=5940343&offset=20
The App was compiled in Ubuntu 11.04 with Kernel 2.6.x and driver 295, so, I'd expect any machine around there should work. The latest Ubuntu versions want to use driver 304 with my GTS 250. I was thinking about pairing my 250 with my 8800 GT and seeing how that worked in Ubuntu 11.04, but I'm busy with other things and I'm pretty sure the App will work with my machines.
We just need to see how it works with other machines...

Any news here? Didn't see this thread and tried since a few days to bring my GPU online for crunching... *sigh*
Thank you!

---

Probing Cuda build went to beta last week, and we determined more Cuda versions are needed to cover older Linux distribution kernels, Cuda 4.2 looking like the weapon of choice to cover the majority on that platform.

Minimum requirements for the Cuda6 build at http://jgopt.org/download.html are marginally better understood, though stock release requires completion there (to get the scheduler issuing the right things to the right hosts).

Not much since that time due to work commitments, but at least have a path to follow. Will be Juggling some more and feeding Eric further builds of mine and TBar's come weekend (which applies to both Linux and MacOSX)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Guys, don't know what are you talking about...when there's no job for my Quadro 1700 on Ubuntu 14.04LTS x64:
http://setiathome.berkeley.edu/results.php?hostid=7784676
:/

All it works is on SETi@home BETA, which is throttled on 10%...while SETi@home is on 100%!
;)

---

non-profit org. Play4Life in Zagreb, Croatia, EU

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

[snip]
(I also have another problem in that a month ago this machine started resetting without warning after a few minutes to a few hours of running boinc, and even resets during the boot up. Happens with cpu apps or large videos - have swapped mainboards with another machine, peripherals and ram, and still happens. Only constants were the video card GTX760 and PSU which I thoroughly cleaned. Hope it's not the GPU - next thing to swap and test.)

Something you might want to check on the video card: Leave the case open for a few minutes, start the computer, and check if the fan or fans on the video card are turning. If they aren't, expect the card to overheat soon and tell the whole computer that it must shut down to prevent damage to the GPU.

The video cards often come with software for showing the GPU temperature if you are running Windows; I haven't checked if such software is also available for Linux.

If you can find similar software for displaying the CPU temperature, you might want to install that also, in case the CPU fan starts to fail.

Solved it soon afterwards but didn't see opportunity to report.

The PSU's high CFM fan was the culprit and should have been my first suspect but I didn't notice at first because it draws air in through a filter on the bottom and isn't visible.
It had gotten stiff and stopped after about 3 years of continuous use, so I cleaned and oiled it to buy some time and ordered a new one.
PSU was simply overheating without enough airflow under load, and would explain why it would reboot during the POST until it had cooled down enough to complete.

Wasn't much fun fscking raid disks and resynchronizing the mysql databases several times, but it hasn't crashed since even while throwing everything I have at it. :-)

Very relieved it wasn't the GPU!

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

Don't know if it goes by 1:10 in WUs or in time consumption of GPU/CPU?! ;)

---

non-profit org. Play4Life in Zagreb, Croatia, EU

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

Don't know if it goes by 1:10 in WUs or in time consumption of GPU/CPU?! ;)

Ah right, think I know what you're asking... Task scheduling. Well the simple answer is that what the scheduler issues to you is determined by 'CreditNew' so is volatile to ~+/-30% after convergence.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

Don't know if it goes by 1:10 in WUs or in time consumption of GPU/CPU?! ;)

Ah right, think I know what you're asking... Task scheduling. Well the simple answer is that what the scheduler issues to you is determined by 'CreditNew' so is volatile to ~+/-30% after convergence.

Task scheduling is not linked into credit.

Roughly speaking, resource share translates into % time the cup/gpu spends on the projects. For CPU only that's straight forward - if you have them at 50/50 and two cores, one core goes to one project. [more or less] if you put them at 1/9 out of 10h crunching time 9h go to one project and 1 hour to the other

It gets a bit messy when GPUs are involved and the project mix comprises CPU only as well as CPU/GPU projects.

There's something called 'recent estimated credit (REC)' that gets calculated by the client but it's really only 'time spent on a project'. in an ideal world, time spend on a project would equal credit received across projects. there is no server feedback into the scheduling mechanism.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

Don't know if it goes by 1:10 in WUs or in time consumption of GPU/CPU?! ;)

Ah right, think I know what you're asking... Task scheduling. Well the simple answer is that what the scheduler issues to you is determined by 'CreditNew' so is volatile to ~+/-30% after convergence.

Task scheduling is not linked into credit.

Roughly speaking, resource share translates into % time the cup/gpu spends on the projects. For CPU only that's straight forward - if you have them at 50/50 and two cores, one core goes to one project. [more or less] if you put them at 1/9 out of 10h crunching time 9h go to one project and 1 hour to the other

It gets a bit messy when GPUs are involved and the project mix comprises CPU only as well as CPU/GPU projects.

There's something called 'recent estimated credit (REC)' that gets calculated by the client but it's really only 'time spent on a project'. in an ideal world, time spend on a project would equal credit received across projects. there is no server feedback into the scheduling mechanism.

Task scheduling (server issue) IS linked into CreditNew (not Credit Directly), via the task estimates, effectively a simulation of your host before giving you the tasks. Find someone that hasn;t read the code to debunk.

[Edit:] note that client side task scheduling is also linked into estimates, which IS CreditNew.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

If you're looking for or expecting stock deployment on main, there are some problems to solve first, at outlined in the previous post.

Don't know if it goes by 1:10 in WUs or in time consumption of GPU/CPU?! ;)

Ah right, think I know what you're asking... Task scheduling. Well the simple answer is that what the scheduler issues to you is determined by 'CreditNew' so is volatile to ~+/-30% after convergence.

Task scheduling is not linked into credit.

Roughly speaking, resource share translates into % time the cup/gpu spends on the projects. For CPU only that's straight forward - if you have them at 50/50 and two cores, one core goes to one project. [more or less] if you put them at 1/9 out of 10h crunching time 9h go to one project and 1 hour to the other

It gets a bit messy when GPUs are involved and the project mix comprises CPU only as well as CPU/GPU projects.

There's something called 'recent estimated credit (REC)' that gets calculated by the client but it's really only 'time spent on a project'. in an ideal world, time spend on a project would equal credit received across projects. there is no server feedback into the scheduling mechanism.

Task scheduling (server issue) IS linked into CreditNew (not Credit Directly), via the task estimates, effectively a simulation of your host before giving you the tasks. Find someone that hasn;t read the code to debunk.

[Edit:] note that client side task scheduling is also linked into estimates, which IS CreditNew.

Yes, the crappy estimates are derived from CreditNew. But the question how BOINC distributes resources across projects depends on the resource share assigned, not on the actual output of the apps.

edit: to clarify by 'output' I mean credit received, usually monitored by the user via RAC.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Yes, the crappy estimates are derived from CreditNew. But the question how BOINC distributes resources across projects depends on the resource share assigned, not on the actual output of the apps.

No the crappy estimates ARE CreditNew, and those will directly impact your client side resource scheduling, and so mispredict resource share.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Yes, the crappy estimates are derived from CreditNew. But the question how BOINC distributes resources across projects depends on the resource share assigned, not on the actual output of the apps.

No the crappy estimates ARE CreditNew, and those will directly impact your client side resource scheduling, and so mispredict resource share.

Do you want to codewalk? :P

Estimates don't matter.
as per previous example if the % of resource share is 50, then BOINC will schedule tasks, so that the project gets 50% of available time. [task availability permitting] IIRC GPUs have a factor attached. it's been a long time that I walked that area.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

edit: to clarify by 'output' I mean credit received, usually monitored by the user via RAC.

Volatility in RAC (under steady state, and extreme conditions) is purely a symptom of deeper problems in the estimate mechanism.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Estimates don't matter.
as per previous example if the % of resource share is 50, then BOINC will schedule tasks, so that the project gets 50% of available time. [task availability permitting] IIRC GPUs have a factor attached. it's been a long time that I walked that area.

Estimates matter, at both server issue, and for client side scheduling. In fact they are key to avoiding the boom/bust behaviour seen throughout. They are the main direct cause of oscillation in the mechanism.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Estimates don't matter.
as per previous example if the % of resource share is 50, then BOINC will schedule tasks, so that the project gets 50% of available time. [task availability permitting] IIRC GPUs have a factor attached. it's been a long time that I walked that area.

Estimates matter, at both server issue, and for client side scheduling. In fact they are key to avoiding the boom/bust behaviour seen throughout. They are the main direct cause of oscillation in the mechanism.

It's purely time allocation. I don't have the time right now to shove the code under your nose.
We are talking about a BOINC v7 with the revamped work fetch and scheduling mechanism.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Estimates don't matter.
as per previous example if the % of resource share is 50, then BOINC will schedule tasks, so that the project gets 50% of available time. [task availability permitting] IIRC GPUs have a factor attached. it's been a long time that I walked that area.

Estimates matter, at both server issue, and for client side scheduling. In fact they are key to avoiding the boom/bust behaviour seen throughout. They are the main direct cause of oscillation in the mechanism.

It's purely time allocation. I don't have the time right now to shove the code under your nose.
We are talking about a BOINC v7 with the revamped work fetch and scheduling mechanism.

With estimates all over the shop, anything after that is nonsensical... As even with fixed timeslots, you aren't requesting the right amount of work to fill those slots (oscillation instability propagated).

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.