Yes, i have added the tuning section in the read me files.

Last modification of the files i made in june before the Installer 0.43b has been released.

The work group size has nothing to do with cuda cores.
The 980TI also has a work group size of 1024.
Changing it will have no possitive affect for the 980TI.
Using higher work group size for high end cards results in bigger run times.
It only helps for entry level cards like the 720 with less than 10 compute units for example.

For high end cards like Titan X or 980TI the best way to speed up the card further more is to increase -unroll when -use_sleep is in place.
FFA_fetch values are max possible without getting false overflows.

Increasing unroll might require to reduce ffa_fetch values on some GPU host combos.

---

With each crime and every kindness we birth our future.

Increasing unroll might require to reduce ffa_fetch values on some GPU host combos.

And this possible relation can't be explained from algorithm point of view :)
Maybe kernel calls batched in some undivisible blocks there...
Big -ffa_block sizes reasonably would require drop in -ffa_block_fetch value.

Increasing unroll might require to reduce ffa_fetch values on some GPU host combos.

And this possible relation can't be explained from algorithm point of view :)
Maybe kernel calls batched in some undivisible blocks there...
Big -ffa_block sizes reasonably would require drop in -ffa_block_fetch value.

I mean both -ffa_block and -ffa_block_fetch value.
With 16384 8192 i got some lags using -unroll bigger 24 on some NV cards during my tests.
On the 780TI for example.
The card can handle -ffa_block 12288 and -ffa_block_fetch 6144 with -unroll 28.

---

With each crime and every kindness we birth our future.

Increasing unroll might require to reduce ffa_fetch values on some GPU host combos.

And this possible relation can't be explained from algorithm point of view :)
Maybe kernel calls batched in some undivisible blocks there...
Big -ffa_block sizes reasonably would require drop in -ffa_block_fetch value.

I've noticed in Linux the smaller ffa numbers work better. At least on the cards that have tried it.
I've also noticed with some drivers you don't need the -Sleep cmd, checkout these times Not using sleep, http://setiathome.berkeley.edu/results.php?hostid=7771865&offset=60&appid=20
Then these cpu times, http://setiathome.berkeley.edu/results.php?hostid=7611256&appid=20
My nVidia in Ubuntu, Not using Sleep, http://setiathome.berkeley.edu/results.php?hostid=7258715&offset=100
The same card in OSX is the same without using Sleep.

Increasing unroll might require to reduce ffa_fetch values on some GPU host combos.

And this possible relation can't be explained from algorithm point of view :)
Maybe kernel calls batched in some undivisible blocks there...
Big -ffa_block sizes reasonably would require drop in -ffa_block_fetch value.

I've noticed in Linux the smaller ffa numbers work better. At least on the cards that have tried it.
I've also noticed with some drivers you don't need the -Sleep cmd, checkout these times Not using sleep, http://setiathome.berkeley.edu/results.php?hostid=7771865&offset=60&appid=20
Then these cpu times, http://setiathome.berkeley.edu/results.php?hostid=7611256&appid=20
My nVidia in Ubuntu, Not using Sleep, http://setiathome.berkeley.edu/results.php?hostid=7258715&offset=100
The same card in OSX is the same without using Sleep.

Yes, we are talking about win only in this case.

---

With each crime and every kindness we birth our future.

I've also noticed with some drivers you don't need the -Sleep cmd,

Same on Windows but those drivers that don't need sleep became ancient ones ....

I've also noticed with some drivers you don't need the -Sleep cmd,

Same on Windows but those drivers that don't need sleep became ancient ones ....

Yes, but the drivers in Linux Are Not ancient.

Can we stay on topic please.

This guys are asking for optimisation on their hosts.
Non of them running Linux or OSX.

---

With each crime and every kindness we birth our future.

Can we stay on topic please.

This guys are asking for optimisation on their hosts.
Non of them running Linux or OSX.

If they discovered it would optimize better they might.
It is on Topic, just the Topic You don't like.

Can we stay on topic please.

This guys are asking for optimisation on their hosts.
Non of them running Linux or OSX.

If they discovered it would optimize better they might.
It is on Topic, just the Topic You don't like.

I run Linux so why do you think i don`t like it ?

---

With each crime and every kindness we birth our future.

Can we stay on topic please.

This guys are asking for optimisation on their hosts.
Non of them running Linux or OSX.

If they discovered it would optimize better they might.
It is on Topic, just the Topic You don't like.

I run Linux so why do you think i don`t like it ?

Why are you telling me that Linux Optimizations are off topic?
If the cards runs better in Linux why say it's off topic?

Optimization by OS change is viable way, but one should consider overall performance gain then cause it's hardly possible w/o unacceptable overhead to put NV card "under Linux" and staying with Windows for all other devices. This makes transition to Linux more complex optimization than simple param space tuning for particular GPU.
Would be interesting to get full-host transition case studies Linux vs Windows (OS X should be excluded cause it requires different hardware/firmware AFAK) in separate thread. That accounts for CPU parformance change as well and other possible intrications for multi-GPU hosts.
Having such thread would be really great in view of Win10 concerns...

Are you telling me I can set-up my computer to run Seti on Linux, while still being able to actively use my computer on Windows?[/quote]

---

Are you telling me I can set-up my computer to run Seti on Linux, while still being able to actively use my computer on Windows?

[/quote]
It depends on how you would "actively use" it.
Playing 3D games - probably not. Browsing and office work - yes, it's quite possible.
Just run windows OS under VM in Linux.