Are you running SoG or cuda?

What does -poll do?

Are you running SoG or cuda?

CUDA

What does -poll do?

Honestly? No idea.
WAG- keeps the CPU & GPU talking to each other; as I understand one of the big delays in processing is do to with all the CPU-GPU communication, so it keeps it going all the time. It did reduce the GPU WU runtimes by enough to still make it worth losing the use of the CPU cores for GPU crunching. You need 1 CPU core for each WU being crunched.
I'm pretty sure it was TBar that suggested it.

---

Grant
Darwin NT

The -poll command-line option switches Cuda synchronisation mode from sleep waits (blocking Sync) to spin synchronisation (spin on a cpu core). It's was an inactive vestige of the original Cuda implementation that I kept working, despite it didn't have high practical benefits until GPU side processing became faster than the CPU scheduling (mostly Windows). Since some people are finding it useful, then I will probably expose it in mbcuda.cfg for advanced users at some point.

default cuda mode, roughly equivalent to the OpenCL builds with -use_sleep (low Impact)
-poll mode, roughly equivalent to the OpenCL builds without -use_sleep active (high impact)

The pro for using it under certain situations, is cancelling much of the driver & OS latencies in keeping the GPU fed. The downside is spinning on a CPU effectively doing nothing, so chewing up CPU.

Probably the balance shifts & relative latency change is pointing that it's time to go asynchronous-threaded-heterogeneous, which are components Petri's been working on in the first case, and myself in the second and third.

[Edit:]

I'm pretty sure it was TBar that suggested it.

Highly likely. The system latencies on Mac seem to be even higher than on Windows, and larger Mac Pros generally have CPU on tap. Only risky situation about exposing the mode (by option or default), is that there's a trend to people stuffing as many high powered GPUs into underpowered CPU hosts, so creating a massive state of overcommit, which can be not a pretty situation.

---

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

Please let the kitties know when it might be safe to do a new Lunatics install.

I am assuming that men shall be men and we can expect same.

There is no reason for anybody to try to out-diddle each other here.
We are all in the same camp, eh?

I am confused as hell about this SOG thingy.

I only want what is best for the project, understand?

And I know you are all doing your dead level best to assure that.

I have always placed my trust in you, so stop the bickering and get back to it. Please.

Otherwise, I shall be forced to play my hand and you are going to have to endure hours of hours of Peter, Paul, and Mary clips for your eternity here.

And trust me, although endearing, they do have their limits.

---

"Time is simply the mechanism that keeps everything from happening all at once."

... there's a trend to people stuffing as many high powered GPUs into underpowered CPU hosts, so creating a massive state of overcommit, which can be not a pretty situation.

An example of that is probably my C2D (with Vista 32bit).
When it had 2 GTX 750Tis in it, running 2 WUs at a time at high priority, according to Process Explorer the DPC & Hardware interrupts were from 8-15%, generally around 9-11%. With only one video card 5% is generally the peak value, usually they're less than 3%.


Interestingly my i7 when running Win7 64 bit with the 2 GTX750Tis running 2 WUs at a time with -poll & 1 core for each WU the Interrupts & DPCs were around 5-7% with spikes to 10%.
Just moving to WIn10 (interrupts & DPCs are now combined in Process Explorer) the highest I've seen was 1.8%. Generally it's 0.5% or less.
And the only screen lag with the Guppie VLARs running is in the Task view of BOINC Manager. Even the missing letters when typing no longer occurs.

---

Grant
Darwin NT

I think I am a part of that trend, due to the fact that I have a number of boards that are a bit older, mostly running Xeon 3370s, which are 4 true cores with no HT. I am putting in new gen GPU's (7/9/10 series, over time, as $ allows) into them, well, because I can, and they will physically work, though the interface is only PCI-E 16x V1, so that may be a bottleneck, not sure.

They are mostly going to be running Vista 64 bit with 4 gig of ram in each. I wonder if a move to W10 (EGADS! The Humanity!) would make any difference in efficiency? I had planned to run Vlite on the install to try and trim it down a bit, but not sure if that is just to slim down the footprint on the HD, or if it will remove processes that are sucking up precious CPU cycles? Didn't get around to it, so still running the orig bloated version.

---

How confident are you that the NVidia drivers released with the new generation of hardware will be Vista compatible? And for how long?

Well, as Vista is supported at release, there is always those to fall back on, but I would say that probably not for much longer, maybe one or 2 releases at best after EOL on April 11th 2017? Which is still about a year away, though I know long term it isn't a solution, but it is in a better place than those machines running XP still. Those are definitely locked in to the last series - or was it the 700 series? - of GPU's due to lack of driver support.

That is what gives developers grey hair, supporting all the older hardware and drivers. The question I suppose is how far back to support, and what should the cutoff line be? Glad I'm not in charge of making those decisions.

---

Looks good to me. 'Go the little red fire engine' :D

---

"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 good to me. 'Go the little red fire engine' :D

Just a note Jason: I'm not doing this to put down CUDA in any way at all. It's just that I find it interesting that with SoG, OpenCL seems to have really grown up, so to speak.

Not taking it that way. What you (maybe) need to realise, as with all, is that open source development comes from all directions. We might have cultural, ethical, philosophical, religious or personality differences that could be irreconcilable. None of that baggage matters for Sh@t when the future might be at stake.

---

"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 good to me. 'Go the little red fire engine' :D

. . Que?

. . What means "little red fire engine"?

Looks good to me. 'Go the little red fire engine' :D

Just a note Jason: I'm not doing this to put down CUDA in any way at all. It's just that I find it interesting that with SoG, OpenCL seems to have really grown up, so to speak.

Not taking it that way. What you (maybe) need to realise, as with all, is that open source development comes from all directions. We might have cultural, ethical, philosophical, religious or personality differences that could be irreconcilable. None of that baggage matters for Sh@t when the future might be at stake.

Oh, that became serious enough Jason. Future at stake, holy Moses, where's my bottle of Cognac? :-)

. . And here have I run out of Pear Schnappes! Oh dear.

. . :)

. . I am taking this as the "thread that Raistmer is monitoring" referred to by Richard in the "Beta 0.45 SoG" thread. If I am wrong I am confident I will be told so.

. . Beta running nicely despite Seti picking a lousy time to be down. Right when I had minimum cache because I had run it dry before launching into the Beta of Lunatics 0.45. But after a prolonged WU drought I now have a full cache and things are humming.

. . Before installing Beta version:-

. . Core i5-6400, GTX950, Win 10 core 64, running stock apps. Running 3 CPU WUs and whatever I was getting for the GPU one at a time.

. . Noise bombs - run for a few seconds.
. . Halflings (VHAR) - run about 7 mins.
. . Normals - run about 13 to 14 mins.
. . Guppis (SoG) - run about 30 to 32 mins,
. . Guppis (CUDA) - run about 50 to 60 mins (aarrggghh!)

. . CPU cores running happily at about 80% to 90% (all four).
. . GPU running as each WU demanded (75% to 85% for CUDA 50 Arecibo and 95% plus for CUDA50 & SoG Guppis)
. . When SoG running all CPU loads increased.

. . After installing Beta, running 3 CPU WUs and only OpenCL SOG on GPU.

. . Normals now about 12 mins and Guppis about 29 Mins. But ...

. . CPU cores all 4 running flatlined at 100% (no headroom left)
. . GPU running at about 95% with FB's at 90%.

. . Downside CPU runtimes up about 10 to 15 % over previous AVX times.

. . Correction: Dropped one CPU WU. Now 2 CPU and one GPU task running.

. . CPU cores all running lower loads (average about 80% to 90%)
. . CPU runtimes closer to previous times.

. . I was going to post the graphs of running loads but cannot get paste to work.

. . It would be nice to balance SoG runtimes against CPU loads but I don't know enough about tweaking configs to do that. A few mins longer on SoG runtimes would be worth it for a 20% to 30% drop in SoG CPU load so I could return to 3 CPU WUs.

. . I have seen the messages about implementing the -use_Sleep command but do not know how (i.e. where to place it).

Looks good to me. 'Go the little red fire engine' :D

. . Que?

. . What means "little red fire engine"?

Just my misquoting of "Go you big red fire engine!"(urban dictionary)

---

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

Just my misquoting of "Go you big red fire engine!"(urban dictionary)

. . OK I will look up the reference.

Looks good to me. 'Go the little red fire engine' :D

. . Que?

. . What means "little red fire engine"?

Just my misquoting of "Go you big red fire engine!"(urban dictionary)

. . OK, while I have your attention.

. . Can you tell me where and how to implement the -use_sleep command. I would like to free up some CPU time for all these SoG tasks I am now running under Lunatics 0.45 Beta.

Do you know where your seti@home folder is?

If yes, then you are looking for the mb_cmdline_win_x86_SSE3_OpenCL_NV.txt

Left click and open with Notepad

Type in -use_sleep and save

Next time any mb start it should read that command. You can add other commands to that file but need to have a space between them.

Do you know where your seti@home folder is?

If yes, then you are looking for the mb_cmdline_win_x86_SSE3_OpenCL_NV.txt

Left click and open with Notepad

Type in -use_sleep and save

Next time any mb start it should read that command. You can add other commands to that file but need to have a space between them.

. . Thanks for that. I will add it right away. And I am pleased that I do not have to restart BOINC to get it to take effect.

. . A few questions though if I may:

1) Is it the same file for both x86 and x64 apps?
. . . Asked and answered, it took effect on the very next task as indicated.

2) Do additional commands have to be on the same line or can they be listed sequentially on following lines?

3) Can you point me to the doc file (*.txt) that explains all this?

. . Thanks again

Stephen

2) Do additional commands have to be on the same line or can they be listed sequentially on following lines?

yes they all have to be on the same line with a space between them, not listed sequentially.

3) Can you point me to the doc file (*.txt) that explains all this?

. . Thanks again

Stephen

That part I can't, but one of the others can. I only know that little part after TONS of help from Mike, Jason, Raistmer, William, Ageless, Richard and many others. Hopefully one of them can point you in the right direction.

Can you point me to the doc file (*.txt) that explains all this?

Check for a file called ReadMe_MultiBeam_OpenCL.txt.

---

With each crime and every kindness we birth our future.