Been a member since 2009 but I didn't do much then but now I am back with a computer that's dedicated for 24/7 crunching. Can anyone provide any tips for tweaking my settings so I can squeeze anymore RAC out of my Dell? This machine is dedicated to BOINC as I have another computer that's my daily machine.

Specs:
Dell T7400 Server running Windows 10 Professional
2, Quad core Xeon E5450's @ 3.0Ghz and 8 cores/8 threads (100% of the CPU's + 100% of CPU time)
32Gb DDR2 ECC RAM
Asus Expedition GTX 1060 6gb (currently running 1 task (0.367 CPUs + 1 NVIDIA GPU)
WD Blue SSD 250Gb as the boot drive
WD Blue 1Tb where BOINC and SETI@home are installed
1000w 80+ Silver PSU

System temps with 5 fans set on 60% keep the cpus around 58c-62c per ambient room temps and the gpu stays around 61c at 32% fan (automatic fan control per card temps). So far from what I can tell my machine is doing a pretty good job and has me in the mid 30's rank for active RAC in Team USA and in the top 5% from what my badge says lol!

Thanks everyone! I look forward to getting to know all of you and make some friends... I also plan on visiting the Green Bank Observatory since I live 3 hours away in Tazewell, Virginia.

---

All of this has happened before and will happen again -Battlestar Galactica

Welcome back. You are already ahead of the game as your host has avoided the usual and normal attempt by the schedulers to send you every possible app for your gpu and landed you right off with the best and fastest SoG app for Windows. Only thing I would recommend is using a more aggressive SoG parameter tuning line to get more out of your 1060. You might try adding this to your mb_cmdline_win_x86_SSE3_OpenCL_NV_SoG.txt file to run the app a bit faster.

-sbs 1024 -period_iterations_num 1 -tt 1500 -high_perf -high_prec_timer -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Welcome back. You are already ahead of the game as your host has avoided the usual and normal attempt by the schedulers to send you every possible app for your gpu and landed you right off with the best and fastest SoG app for Windows. Only thing I would recommend is using a more aggressive SoG parameter tuning line to get more out of your 1060. You might try adding this to your mb_cmdline_win_x86_SSE3_OpenCL_NV_SoG.txt file to run the app a bit faster.

-sbs 1024 -period_iterations_num 1 -tt 1500 -high_perf -high_prec_timer -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64

Hello Shannon,

Welcome to the forums. Keith gives a good commandline but might be abit aggressive for 1060. See how it runs, if you start to get lagging or lock ups then I would increase period itersations to 20 or 50 (50 is baseline) sbs would be the next thou we will see soon from your stderr report if that is too aggressive as well. Might need to half that value. As with anything, testing will determine the best parameters for your system.


Zalster

---

So I just take that and copy it to the bottom of that txt file and restart BOINC? What does it do exactly in terms of being more aggressive?

I'm actually quite impressed with this machines performance for being made in 2009 but I just recently upgraded it with those to Xeon's, memory and the GTX 1060... it's a retired computer from Virginia Tech that was in exceptional condition and it was crazy cheap!

I'm looking to do a 1950x Threadripper build later this year once prices on the X399 platform come down once X499 and the new Threadripper comes out.

---

All of this has happened before and will happen again -Battlestar Galactica

Welcome back. You are already ahead of the game as your host has avoided the usual and normal attempt by the schedulers to send you every possible app for your gpu and landed you right off with the best and fastest SoG app for Windows. Only thing I would recommend is using a more aggressive SoG parameter tuning line to get more out of your 1060. You might try adding this to your mb_cmdline_win_x86_SSE3_OpenCL_NV_SoG.txt file to run the app a bit faster.

-sbs 1024 -period_iterations_num 1 -tt 1500 -high_perf -high_prec_timer -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64

Hello Shannon,

Welcome to the forums. Keith gives a good commandline but might be abit aggressive for 1060. See how it runs, if you start to get lagging or lock ups then I would increase period itersations to 20 or 50 (50 is baseline) sbs would be the next thou we will see soon from your stderr report if that is too aggressive as well. Might need to half that value. As with anything, testing will determine the best parameters for your system.


Zalster

So what does that do exactly?

---

All of this has happened before and will happen again -Battlestar Galactica

Keith is the one to talk to about ThreadRipper builds. Once you decide to go that route, be sure to hit him up.

The commandline just setting the timing spent in the kernal call. The SBS is the memory buffer, so you are telling it how much to use (but be aware that Nvidia cards only use about 27% of available RAM on the card due to how they designed OpenCl )

There's a long explanation on all the parameters I believe over at Lunatics (that is what Keith tells me) Raistmer explains it in the forum.

http://lunatics.kwsn.info/index.php/topic,1808.msg61251/topicseen.html#new


Z

---

So far with that command line it seems to be running good... will that make the card process work units faster? They seem to take 8:47 minutes to complete...

---

All of this has happened before and will happen again -Battlestar Galactica

So I just take that and copy it to the bottom of that txt file and restart BOINC? What does it do exactly in terms of being more aggressive?

No you don't need to restart BOINC. Just with that file present with parameter content, the next gpu task reads it for how to set the app up automatically and runs with the new parameters. What that tuning line does is let the compute kernel spend as much time as possible crunching looking for signals before the gpu makes a pause to ask the cpu for more data. In a simplistic way of stating how the algorithm works. If you want to know more you can read through Raistmer's explanation of the search algorithm tuning parameters that Zalster posted in the previous message.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

So far with that command line it seems to be running good... will that make the card process work units faster? They seem to take 8:47 minutes to complete...

It should, the only other thing I would add is -hp at the end. That will make the work unit High priority.

-sbs 1024 -period_iterations_num 1 -tt 1500 -high_perf -high_prec_timer -spike_fft_thresh 4096 -tune 1 64 1 4 -oclfft_tune_gr 256 -oclfft_tune_lr 16 -oclfft_tune_wg 256 -oclfft_tune_ls 512 -oclfft_tune_bn 64 -oclfft_tune_cw 64 -hp

---

So far with that command line it seems to be running good... will that make the card process work units faster? They seem to take 8:47 minutes to complete...

I see one new task with the new tuning line show up and it shaved 50 seconds off your previous times. Now running tasks in around 8 minutes even.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Ok I'll give that a go! Thanks guys!

---

All of this has happened before and will happen again -Battlestar Galactica

So far with that command line it seems to be running good... will that make the card process work units faster? They seem to take 8:47 minutes to complete...

I see one new task with the new tuning line show up and it shaved 50 seconds off your previous times. Now running tasks in around 8 minutes even.

Where do I go to view that myself?

---

All of this has happened before and will happen again -Battlestar Galactica

stderr report of completed work units. Click on your computers then tasks, then on either valid or pending. Then look at the result. It takes a bit of getting used to for understanding what you are looking at.

Did you install the new commandline? I still see period iterations at 50.

Edit..

Ok, I see it now..lol Keith beat me to it..

---

stderr report of completed work units. Click on your computers then tasks, then on either valid or pending. Then look at the result. It takes a bit of getting used to for understanding what you are looking at.

Did you install the new commandline? I still see period iterations at 50.

Look at this task:

https://setiathome.berkeley.edu/result.php?resultid=7573936217

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

stderr report of completed work units. Click on your computers then tasks, then on either valid or pending. Then look at the result. It takes a bit of getting used to for understanding what you are looking at.

Did you install the new commandline? I still see period iterations at 50.

Look at this task:

https://setiathome.berkeley.edu/result.php?resultid=7573936217

Thanks Keith for the link

Still needs to add -hp

Priority of process adjusted successfully, below normal priority class used

---

stderr report of completed work units. Click on your computers then tasks, then on either valid or pending. Then look at the result. It takes a bit of getting used to for understanding what you are looking at.

Did you install the new commandline? I still see period iterations at 50.

Look at this task:

https://setiathome.berkeley.edu/result.php?resultid=7573936217

Thanks Keith for the link

Still needs to add -hp

Priority of process adjusted successfully, below normal priority class used

-hp added

---

All of this has happened before and will happen again -Battlestar Galactica

It should, the only other thing I would add is -hp at the end. That will make the work unit High priority.

That's the last possible tuning parameter you could add to make it perform better. That will bump the thread priority up to High that is running the gpu thread. But it can also cause system lagginess because your gpu thread has priority now over the majority of other system threads and you might then start experiencing keyboard input lag for example.

What it will do is speed the task up a bit more. If you look at your task stderr.txt report I linked you will see two timing numbers reported for the task. There is the run_time for the task which is the elapsed wall clock time for the task from starting the task to finish and uploading the task. The cpu_time is the amount of time that a cpu thread took to service the task. Because you are not running the task currently at high priority, the cpu thread took some time off from servicing the thread to service other computer housekeeping threads. If you ran with high priority the cpu_time and run_time would be almost equal since the cpu thread is not allowed to switch away from servicing the gpu thread to do something else.

With that task with high priority the run_time of the task would have been reduced to just 7 minutes 48 seconds. That would have been a full minute faster than your original stock app tuning.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

It should, the only other thing I would add is -hp at the end. That will make the work unit High priority.

That's the last possible tuning parameter you could add to make it perform better. That will bump the thread priority up to High that is running the gpu thread. But it can also cause system lagginess because your gpu thread has priority now over the majority of other system threads and you might then start experiencing keyboard input lag for example.

What it will do is speed the task up a bit more. If you look at your task stderr.txt report I linked you will see two timing numbers reported for the task. There is the run_time for the task which is the elapsed wall clock time for the task from starting the task to finish and uploading the task. The cpu_time is the amount of time that a cpu thread took to service the task. Because you are not running the task currently at high priority, the cpu thread took some time off from servicing the thread to service other computer housekeeping threads. If you ran with high priority the cpu_time and run_time would be almost equal since the cpu thread is not allowed to switch away from servicing the gpu thread to do something else.

With that task with high priority the run_time of the task would have been reduced to just 7 minutes 48 seconds. That would have been a full minute faster than your original stock app tuning.

I had to take out the -hp as it caused a lot of system lag and keyboard lag... :(

Actually still having some lag right now too but its not as bad as it was.

---

All of this has happened before and will happen again -Battlestar Galactica

I had to take out the -hp as it caused a lot of system lag and keyboard lag... :(

Actually still having some lag right now too but its not as bad as it was.

Increase the -period_iterations_num that will help a lot with the lag.
try 10 - 50 for example and then try with -hp again.

---

That is why I never ran with the -hp parameter. I never liked it. Always caused lagginess and any improvement is nullified by having to back off num_iterations. I always found that running with num_iterations=1 and with no -hp was faster than running with -hp and num_iterations=10 backed off so I didn't get keyboard input lagginess.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)