I have a new machine running stock (arf-PC), and it was going along very nicely, running the SoG stock app and no CPU work at all. The CPU (i7-950 with HT on - so 8 cores) was running in the 70% or so range.

I then decided to try the command line Zalster suggested in the "It's Been A While...." thread:

-use_sleep -sbs 512 -period_iterations_num 10 -hp

Now everything is still running OK, as best as I can tell (I'll wait to see how fast the WUs complete, but it will be a HUGE pain w/o the replica database to allow me to look at the results).

BUT: now the CPU is running at <5%!!!

That's a heck of a drop-off...why would that big an effect occur?

---

Because -use_sleep reduce CPU usage but will most probably increase run times a little bit.

---

With each crime and every kindness we birth our future.

If you want to see the run times better, just stop your network activity for awhile and let some tasks built up waiting to be returned.

ADDED:
You will also see an increase in work done by the GPU if you use -hp without -use_sleep.

If you want to see the run times better, just stop your network activity for awhile and let some tasks built up waiting to be returned.

Excellent idea. I will give it a try.

---

ADDED:
You will also see an increase in work done by the GPU if you use -hp without -use_sleep.

That will depend on how aggressive your command line settings are, and your CPU.
I've got pretty aggressive command line settings- on my i7 system -hp gave a definite performance boost. On my Core 2 Duo there was barely any change in crunching times, but the system became less responsive/more sluggish.
I've got 1 CPU core reserved for each GPU WU being crunched, and i'm only crunching 1 WU at a time per GPU.

---

Grant
Darwin NT

Don't know if you use it but I use something called BoincTasks

http://efmer.com/b/?q=boinctasks_download

I like it because it gives me a look at how much Memory my cards are using, but it also has a history button that lets you look back at returned results to see how long it took to complete task.

You can use it alongside of BOINC manager or use it in place of it.

I like using the -hp but you can remove it and see how it affects your times

---

@Zalster - I d/l BoincTasks and installed it.

Meanwhile, the APR on the machine (runs SoG only) has dropped from upper 130s to under 125 in 12 hours, so I am thinking of going back to no command line. Or should I just drop use_sleep from the line I have (and go back to high CPU utilization, I assume)?

EDIT: Is there a concise writeup of the various command line parameters, and their effects on computations (ie, which are most important and/or easiest to use)?

---

@Zalster - I d/l BoincTasks and installed it.

Meanwhile, the APR on the machine (runs SoG only) has dropped from upper 130s to under 125 in 12 hours, so I am thinking of going back to no command line. Or should I just drop use_sleep from the line I have (and go back to high CPU utilization, I assume)?

EDIT: Is there a concise writeup of the various command line parameters, and their effects on computations (ie, which are most important and/or easiest to use)?

There should be a readme file somewhere in your project folder.
On the bottom you will find some examples.

In short:
You can just remove -use_sleep to speed up processing.
Also adding -sbs 384 and -period_iterations_num 10 or lower will reduce run times significantly.

But beware -period_iterations_num >40 can result in screen lags.
So testing required because its GPU/host specific.

---

With each crime and every kindness we birth our future.

I removed use_sleep from the command line around 5am EDT today, when APR was about 122. Now, 6 hours later, it is back to 138 and still climbing. And CPU use is back to ~70% again.

Also (thanks to BoincTasks) I can see that GBT WUs are now running <20 minutes (@3/GPU) where they were running a bit over 40 before I dropped use_sleep.

EDIT: with SoG and the command line, I find that GBT MBs typically run ~90% CPU, but Arecibo WUs run much less, in the 20-50% CPU range.

---

A further question: How IS Average Processing Rate computed for an app? The value seems to change too fast for it to be a true average... is there a published formula?

---

@Zalster - I d/l BoincTasks and installed it.

Meanwhile, the APR on the machine (runs SoG only) has dropped from upper 130s to under 125 in 12 hours, so I am thinking of going back to no command line. Or should I just drop use_sleep from the line I have (and go back to high CPU utilization, I assume)?

EDIT: Is there a concise writeup of the various command line parameters, and their effects on computations (ie, which are most important and/or easiest to use)?

Sorry for the delay, I'm not at home this weekend so not a lot of connecting with the project.

Mike is the go to person here for commandlines, so best to see what he recommends.

I don't use the -use_sleep as I like my GPU to process the work as fast as possible but I also don't use that computer for anything other than crunching. I only recommend it so that CPU usage would go down and you could have a more responsive computer. If you are not worried about CPU usage or responsiveness then you can definitely do without it.

I'll leave you in Mike's capable hands.

Zalster

---

But beware -period_iterations_num >40 can result in screen lags.

That should be:
"But beware -period_iterations_num < 40 can result in screen lags."

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

you probably should copy over the command lines to the .sah program as well.
Its seems that the server will deliver a cluster of .sahs and a then alternate with a cluster of .SoGs.

you probably should copy over the command lines to the .sah program as well.
Its seems that the server will deliver a cluster of .sahs and a then alternate with a cluster of .SoGs.

Not so. My machine at startup got CUDA42 and CUDA50 as well as _sah and _SoG. After each had completed and validated the minimum amount of WUs (I believe it is 10 or 11), I stopped getting any CUDAs (APR was in the 30-40 range, but, since sah and SOG were nearly tied around an APR of 110-120, I still got both of those. Then after another few hours, SoG pulled significantly ahead of sah, and I haven't seen an sah in several days.

---

you probably should copy over the command lines to the .sah program as well.
Its seems that the server will deliver a cluster of .sahs and a then alternate with a cluster of .SoGs.

Not so. My machine at startup got CUDA42 and CUDA50 as well as _sah and _SoG. After each had completed and validated the minimum amount of WUs (I believe it is 10 or 11), I stopped getting any CUDAs (APR was in the 30-40 range, but, since sah and SOG were nearly tied around an APR of 110-120, I still got both of those. Then after another few hours, SoG pulled significantly ahead of sah, and I haven't seen an sah in several days.

It depends on the luck of the draw.
When I first went over to Beta, the Manager ended up picking the slowest application as being the fastest due to the work that was being handed out at the time.

---

Grant
Darwin NT

You are right, I think. I just couldn't figure out how to express the same thought coherently...


BUT: I reset SETI on one of my machines that had been running Lunatics (don't ask!), and it sent me sah, but not SoG. What does that mean, and what did I do wrong?

---

If you are running Lunatics, you should probably use the latest one if you want SoG

If you let the server send you wantever it wants, you will get a random sampling of the different work units.

I don't know what version of Lunatics you use but v45 beta 4 has the SoG app in it.

---

If you are running Lunatics, you should probably use the latest one if you want SoG

If you let the server send you wantever it wants, you will get a random sampling of the different work units.

I don't know what version of Lunatics you use but v45 beta 4 has the SoG app in it.

On another machine, I started SETI up cold, stock, and it sent me cuda42, cuda50, sah and SoG code and WUs so it could sort out which was best for me (highest APR, I assume). My question was why the reset machine, which already had cuda42 and -50 on board (and in the application info stored for the machine) only sent me sah and not SoG which were not previously there when reverting to stock.

And I just noticed "8.19" WUs on my stock machine, which seems to be the SoG from Beta anyway. So why do Lunatics now?

---

The only reason to do Lunatics is to keep only those apps you want and not any others that may download, which is known to happen periodically when you don't expect it.

But it's your choice, happy crunching either way.

Zalster

---

As said, "the only reason" (in this case) is you KNOW which version you have, and won't have it updated until you want it to.
On the other side, Lunatics is (occasionally/usually) ahead of the curve, and using it means you're using features before anyone using Stock apps.

---