Since I have trouble with the video lag when running SoG bulds on my host. Explained on this thread https://setiathome.berkeley.edu/forum_thread.php?id=82094
And no problem with that lag when run CUDA builds but crunch blc builds with CUDA is to slow, i think on a detour.
Besides the obvious path of rescheduling the WU from GPU to CPU etc. was thinking if is possible to configurate the Seti (or Boinc) to crunch Normal GPU WU with CUDA and if the rescheduled leave some blc to the GPU crunch them with the SoG builds?
If that detour could be programed on the GPU0 only, the one who generate the video output? Leaving the other s running normaly?
That could not fix the problem but certainly will give a help.

But i want to run Seti on that GPU, but CUDA if there are arecibo WU and SoG when blc.

Just not know how to configurate to do that.

I think that it could probably be done by assigning different plan classes to each type of task, but you'd need to do a bit of custom rescheduling to accomplish that. The tasks for the GPUs would all download under one plan class (whichever of the two you place first in your app_info), but then you'd need to reassign the tasks for the other plan class after the download.

But i want to run Seti on that GPU, but CUDA if there are arecibo WU and SoG when blc.

Just not know how to configurate to do that.

I think that it could probably be done by assigning different plan classes to each type of task, but you'd need to do a bit of custom rescheduling to accomplish that. The tasks for the GPUs would all download under one plan class (whichever of the two you place first in your app_info), but then you'd need to reassign the tasks for the other plan class after the download.

My i7 2600 with 2 GTX 1070s is able to play HD YouTube videos with only slight occasional stutters with very aggressive command line settings

With the 1070 the lag is very occasional as you said, but still exist. But what i try to configurate first is the 1060 host.

Yeah, I just find it odd that your GTX 1060 system is getting the stutter/lag even with such high period_iterations_num and low TT values. And removing the High_perf option doesn't help?

And the version of SoG you are running was one of those Raistmer optimized to reduce lag on much lower powered GPU hardware than yours, so even running without any command line values, i'd have expected it to be OK.Grant
Darwin NT

I think that it could probably be done by assigning different plan classes to each type of task, but you'd need to do a bit of custom rescheduling to accomplish that. The tasks for the GPUs would all download under one plan class (whichever of the two you place first in your app_info), but then you'd need to reassign the tasks for the other plan class after the download.

I was thinking much the same. And I think W3Perl would be the one to talk to about customizing a cpu2gpu script for that. Basically take all the GPU tasks and split them off to 2 different plan_classes by file name. With a 1060 running it every 18 hours should work OK.

This lag is something like when we try to run a Vlar on the CUDA builds.....

(that's quite BIG lag )

So, to make it clear, you see lag with SoG app on non-VLAR tasks? on all of them? Or on VHAR ones only?
Did you try to correlate lag with startup time (before real GPU prcessing start).
Can you post any picture from GPU-Z showing GPU load correlated with moments of LAG occurence?
Is lag the rare/occasional or on some tasks you see lags when, for example, key pressed and sequence of same letter printed in CMD window?

EDIT: and did you try just to change driver version on another (bigger/smaller - no matter, jsut another)SETI apps news
We're not gonna fight them. We're gonna transcend them.

Run the MB8 win x86 SSE3 OpenCL NV SoG r3584 app at vanilla settings to do the testing & use this command line parameter in the app_info.xml file, <cmdline>-hp</cmdline>. The -hp command line parameter elevates the app CPU priority to high to keep the GPU processing to the maximum level.

For all the test i run an allready DL episode of The Walking Dead in low resolution (about 480 MB the entire 50 min file) stored on the SSD , so i imagine there is no internet or HDD lag.

I Made 4 test, two with CUDA builds and Arecibo NonVlar WU and no Lag appears as i explain before. Not try blc with CUDA since we all know it´s a waste of time... LoL

The others 2 are with the SoG builds with this command line: -use_sleep -sbs 128 -period_iterations_num 250 -tt 150 -no_defaults_scaling

To try to isolate the problem i run the test crunching GPU WU only the entire CPU was free .

The first one is with Arecibo Non Vlar and the second with blw WU, in both i see the lag on the screen, both are in the middle of the processing of the WU

Something interesting, each time the lag apears, in the memory controler graphics it show´s a dive, can´t say if thas happening before of after the efect the lag (too fast for my human eyes).

During the test i run on the host, Boinc, The crunching builds, MPC (for the movie) and GPU-Z only. The Boinc data & program directories are in a exception of the AV and nothing else was running on the host (at least not shows any other process active in the task manager screen). NO OC on CPU (6800)/GPU and just Plain Win 10

Replace img with [ ] and [/ ] with the text img inside, without any spaces or clicking the URL button, but next you again have the preview being visible from the code itself.

Trying to be helpful, only thing I can say is that making it a link here only strains things a little and it better should be embedded in the page itself, except for making it too large in size,
which once happened to me in the past.

The others 2 are with the SoG builds with this command line: -use_sleep -sbs 128 -period_iterations_num 250 -tt 150 -no_defaults_scaling

While I looking more precisely, this CMD line definitely not for lag-free cards.
-tt 150 means to allow ~150ms length of kernel. That is, 0.15s . Such intervals can be visible by human senses indeed.
I would attempt to test with such line: -sbs 256 -period_iterations_num 500 -tt 10
(and allow all scaling app needs for first test then to add -no_defaults_scaling on second iteration if lags remain)

Now something just came to mind that I did many years ago which may be of help.

Modern browsers and many video playback apps these days have a setting called "use hardware acceleration" (or similar) which I turned off many years ago here due to lag I was suffering back then. This setting is usually on by default and uses the GPU for that "hardware acceleration" so I wonder if this could be the root of your problem.

The only point all the hosts have in common is all are X99 MB, with 6800 or 6850 CPU´s

And driver versions?

Well, you need to download and install nSight profiler or smth alike and most probably to run modified build to get any results (modification required due to unfriendly way BOINC framework dictates scientific app exit sequence: there is no call for exit() that does all required maintenance including profiler data flushing to file, there is just hard termination on OS level that leaves profiler data files empty (true for all profilers I used so far: CPU(PGO)/ATi/NV). And this requires working build environment and I still lack of such currently.
So, more advanced debugging should be postponed.

Currently try to run with -high_prec_timer -cpu_lock_fixed_cpu 2 (I assume you have at least 3 CPUs in your host).

If lag still there try to run with -v 6 option and upload stderr.txt for examination.SETI apps news
We're not gonna fight them. We're gonna transcend them.