lol, one step at a time. The magic mouse is growing on me, but this keyboard must be made for midgets or something.

So far my win7 dev machine with a 980 is singing it's soothing song. No such comforting sound out of the mac yet, but am sure if I push it it'll have limits. Not all that worried about where they are, just that I can spread Xbranch into more areas, since I believe I have a better grasp of the synthetic-aesthetic, enough to push things a little further anyway.

Well, I use a Logitech trackball, I try to avoid the magic. This is the fan control app I use, it's free and you can have it display the CPU temp and fan speed in the menubar, http://www.crystalidea.com/macs-fan-control
Hey, it works....

will be good to check out. Just feeling my way for now. No huge surprises.

Now I would call the temps off the back a little warmer than lukewarm. Yeah the CPU app definitely could do with an update. Still deciding what Cuda GPU i'd like to whack in there. Probably will multithread all 16 threads and combine the radeon and the 680 results just to confuse credit new. Could be a lark

---

"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.

Here you go, I just updated the ATI MB App to the same version I've been using for the past few weeks. From what I can tell the major difference between the MB OpenCL app and CUDA app is the MB OpenCL App slows down on the longer tasks, making them longer than the CUDA tasks. This GPU app doesn't slow down quite as much...
http://www.arkayn.us/forum/index.php?topic=130.msg4194#msg4194

interestingly I have a smattering of VLARs now on the Mac Pro {allocated to CPUs}. I'm babying it, but Kudos to Urs/Raistmer for the radeon munching away, and the stock CPUs doing their thing. Have enabled 4 of the sixteen threads for now, just to see how hot it gets in here. So Far looks like very ugly computers with a half sucked lozenge look, do pretty good :D

Looks like everything is running smooth again. I am noting ten astropulses in this batch (about 60 CPU hours or so), and possibly a larger than average number of VLAR too. it looks like the mix is changing to something a bit more diverse than it's been in recent months.

---

Delidded i7-4790K (CLU/CLU) at 4.7GHz @ 1.310Vcore 24/7, 32GB DDR3-2400, Corsair H100i v2, Gigabyte Z97X-Gaming G1 WIFI-BK, MSI Radeon RX 480 Gaming 4G, HX-650 PSU, Corsair 750D

My CPU has been running off VLARs for at least the last 2 weeks, possibly 3..

---

Looks like everything is running smooth again.

If only.
The MB splitters are presently not producing enough work to satisfy normal demand levels, let alone the demand after an extended outage.
35/s ids the minimum to meet demand & rebuild the ready-to-send buffer. There have been the odd spurts to (almost) 40/s, but much of the time it's been less than 30.
Unfortunately not good enough to meet demand, even at the best of times.


EDIT- After lots of retries I eventually got some GPU work although most likely not enough to avoid running out before being able to get any more.
Add to that, some sticky downloads.


EDIT- I may be lucky. Although most requests for work result in none, so far I've been getting enough not to run out of work (so far). Looks like there are still a lot of VLARs about which would be helping things substantially.

---

Grant
Darwin NT

Win7 dev machine cleaned up about 63 ghosts while I was sleeping... so resend_trigger still works. Can turn that back off now. Not sure when the ghosts accumulated, as been a pretty busy time for me, but all tidy again.

---

"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.

Looks like everything is running smooth again.

If only.
The MB splitters are presently not producing enough work to satisfy normal demand levels, let alone the demand after an extended outage.
35/s ids the minimum to meet demand & rebuild the ready-to-send buffer. There have been the odd spurts to (almost) 40/s, but much of the time it's been less than 30.
Unfortunately not good enough to meet demand, even at the best of times.

I'm not sure how you get those figures, Grant. It's a long-term continuous-flow process, and what goes out has to come back in.

As a long-term average, we return 72,000 MB tasks per hour (from Haveland annual graph). That's, conveniently for the maths, exactly 20 per second. Anything above that will, albeit gradually, top up the buffer store (RTS). There will be times when we have to dip into that buffer, such as during a shorty storm: that's what it's there for. But 30 per second on average is a 50% margin for replacement.

What's the award for the lucky user who gets task number 2^32 - 1?

I asked a few days ago, but nobody cared. Now we are ~2 million tasks away from task 4294967295 and no plans yet.

Looks like everything is running smooth again.

If only.
The MB splitters are presently not producing enough work to satisfy normal demand levels, let alone the demand after an extended outage.
35/s ids the minimum to meet demand & rebuild the ready-to-send buffer. There have been the odd spurts to (almost) 40/s, but much of the time it's been less than 30.
Unfortunately not good enough to meet demand, even at the best of times.

I'm not sure how you get those figures, Grant. It's a long-term continuous-flow process, and what goes out has to come back in.

As a long-term average, we return 72,000 MB tasks per hour (from Haveland annual graph). That's, conveniently for the maths, exactly 20 per second. Anything above that will, albeit gradually, top up the buffer store (RTS). There will be times when we have to dip into that buffer, such as during a shorty storm: that's what it's there for. But 30 per second on average is a 50% margin for replacement.

That's the long term average, with outages (and short term spikes) having their impact. Along with the availability/non-availability of AP.

Until the recent extended period of VLARs there were several weeks of shorties about & no AP for the AP crowd & the returned per hour was between 90-102,000.
Generally (when it's not mostly shorties or VLARs, and no AP available) the returned per hour has generally been around 80,000.
If my maths is right, that's around 23/s just to meet demand when caches are full. When caches are empty, demand will be higher than the actual amount returned per hour (at least until they are full again).
If the caches don't refill, then demand will continue to exceed supply & you'll get many requests for work resulting in none just because there isn't enough there, and so more load on the Scheduler from people continuously asking for work to fill those caches.


Assuming no AP available, and nothing but shorties, and empty caches, I like to see the splitters capable of 35/s as a minimum to meet demand & to rebuild the ready-to-send buffer. Even more would be nice, so that if a couple of spitters go down those that are left are still up to the job.

I just like to build in a healthy margin for error.

---

Grant
Darwin NT

What's the award for the lucky user who gets task number 2^32 - 1?

I asked a few days ago, but nobody cared. Now we are ~2 million tasks away from task 4294967295 and no plans yet.

I was under the understanding that when the project was down and started back up again on Wednesday morning this was to apply a fix to this issue

---

What's the award for the lucky user who gets task number 2^32 - 1?

I asked a few days ago, but nobody cared. Now we are ~2 million tasks away from task 4294967295 and no plans yet.

I was under the understanding that when the project was down and started back up again on Wednesday morning this was to apply a fix to this issue

That is correct. That's what this week's quirks and general weirdness has been all about.. making the shift from 32-bit to 64-bit on key processes and variables.

But the questions is still the same as when I brought this subject up last week: I wonder who is going to get 2^32 - 1 or 2^32? I don't think any kind of recognition or reward is warranted, but it could at least be bragging rights or something. Unfortunately, the way things go, I have a strong feeling it's going to go to someone who never comes to the forums, or someone who trashes WUs, or one of those machines that gets a pile of tasks on the first and only-ever contact, and is never heard from again.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

anyone notice that some of the old 500 series cards produce a lot of invalids lately?

I got 24 inconclusive and looking at the WU's most of em are old fermi cards that cause it

---

I came down with a bad case of i don't give a crap

anyone notice that some of the old 500 series cards produce a lot of invalids lately?

I got 24 inconclusive and looking at the WU's most of em are old fermi cards that cause it

Wasn't there an issue with those cards & certain drivers? If they used a server side block to stop them from getting work, it's possible that it didn't get reinstated after all the goings on- eg the VLARs going to video cards for a while again.

---

Grant
Darwin NT

anyone notice that some of the old 500 series cards produce a lot of invalids lately?

I got 24 inconclusive and looking at the WU's most of em are old fermi cards that cause it

Wasn't there an issue with those cards & certain drivers? If they used a server side block to stop them from getting work, it's possible that it didn't get reinstated after all the goings on- eg the VLARs going to video cards for a while again.

Yes, there is a driver limitation on pre-Fermi cards... My old GTX-275 was recommended NOT to exceed 337.88; and, I ran 266.58 on it. Now, I've replaced that card with a used GTX-750 TI in Prometheus. Unfortunately, I found out the hard way, that Prometheus still CANNOT take the latest drivers; because, my Motherboard has a GeForce 9400 soldered in, and is preventing the system from going above 337.88. When I try installing drivers above 337.88, they crash on the reboot, and then Windows force installs the generic Win Drivers, and then BOINC complains that there's NO GPU to crunch with. :-( So, 337.88 is the latest driver I can use on Prometheus. (Until, and unless I can get a newer Motherboard and CPU combo...)


TL

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

Oh dammit, once again i've wasted a lot of time and energy:

http://setiathome.berkeley.edu/workunit.php?wuid=1855579030

4288626668 	6261161 	27 Jul 2015, 23:43:58 UTC 	27 Jul 2015, 23:49:07 UTC 	Error while computing 	11.37 	0.00 	--- 	AstroPulse v7 v7.09 (opencl_ati_100)
4288626669 	7208793 	27 Jul 2015, 23:43:58 UTC 	27 Jul 2015, 23:49:08 UTC 	Error while computing 	0.00 	0.00 	--- 	AstroPulse v7 v7.04 (sse2)
4288628836 	157931 	27 Jul 2015, 23:49:11 UTC 	29 Jul 2015, 17:49:25 UTC 	Completed, can't validate 	31,113.14 	22,827.13 	0.00 	AstroPulse v7
Anonymous platform (CPU)
4288629020 	6689485 	27 Jul 2015, 23:49:14 UTC 	28 Jul 2015, 0:00:05 UTC 	Error while computing 	0.00 	0.00 	--- 	AstroPulse v7 v7.07 (opencl_ati_mac)
4288633895 	7121137 	28 Jul 2015, 0:00:06 UTC 	28 Jul 2015, 21:10:35 UTC 	Error while computing 	299.80 	0.37 	--- 	AstroPulse v7 v7.08 (opencl_nvidia_cc1)
4289918349 	7112114 	29 Jul 2015, 23:16:17 UTC 	1 Aug 2015, 3:10:13 UTC 	Error while computing 	1.19 	0.16 	--- 	Not in DB
4293319669 	6163616 	1 Aug 2015, 3:10:16 UTC 	1 Aug 2015, 4:54:34 UTC 	Error while computing 	0.00 	0.00 	--- 	AstroPulse v7 v7.07 (opencl_nvidia_mac)

Am i the only one to configure GPU crunching correctly?

---

Aloha, Uli

As far as I can see, you were caught in a twist with only erroneous returnees.
Aside from this person who does manage to return some good work on CPU and GPU, all the others only return faulty results and then almost nothing but.

---

No, it wasn't me who took the BOINC forums down. Was it you, Mark?

Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111) in /mydisks/a/users/boincadm/projects/dev/html/inc/db_conn.inc on line 46

Project is down
The project's database server is down. Please check back in a few hours. 

---

I think the font page news is prettier.

No, it wasn't me who took the BOINC forums down. Was it you, Mark?

Warning: mysql_pconnect(): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111) in /mydisks/a/users/boincadm/projects/dev/html/inc/db_conn.inc on line 46

Project is down
The project's database server is down. Please check back in a few hours. 

You have to pick a better password Jord! :)

Does this mean 2^32 bit a project with no tasks?

Ah, well, Saturday morning and no funds, now we get to see what happens.

---