I installed r1797 over the hiatus of the last couple of days; on my machine (AMD phenom II x6 1055T) with an empty (0 byte) cmdline.txt file it appears to be only about 5-10% faster than the old r555 I was running. Is this reasonable? Or are there parameters I could be feeding the app that would speed it up significantly?

Thanks for any help!
Jon

---

I installed r1797 over the hiatus of the last couple of days; on my machine (AMD phenom II x6 1055T) with an empty (0 byte) cmdline.txt file it appears to be only about 5-10% faster than the old r555 I was running. Is this reasonable? Or are there parameters I could be feeding the app that would speed it up significantly?

Thanks for any help!
Jon

OpenCL ReadMe studied already?
We at Lunatics spent huge amount of time to collect best usage tips, params explanations and so on there. So RTFM first ;)

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I installed r1797 over the hiatus of the last couple of days; on my machine (AMD phenom II x6 1055T) with an empty (0 byte) cmdline.txt file it appears to be only about 5-10% faster than the old r555 I was running. Is this reasonable? Or are there parameters I could be feeding the app that would speed it up significantly?

Thanks for any help!
Jon

Ah, you speaking about CPU version... No speedup expected, it's maintenance release cause r555 not available for download now.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Ah, you speaking about CPU version... No speedup expected, it's maintenance release cause r555 not available for download now.

OK - thanks - I hadn't known that.
I did notice that in Task Manager, R1797 uses a LOT less RAM/instance than R555.

I haven't worked up the nerve to try the GPU version yet - I did look at the README and it was a little intimidating, frankly. Maybe I should wait for the next Installer?

Any idea when that might happen?

---

....I haven't worked up the nerve to try the GPU version yet - I did look at the README and it was a little intimidating, frankly. Maybe I should wait for the next Installer?

Any idea when that might happen?

I have just set up a test machine for AP crunching. This one.

I found it very easy, after pasting the required files into my SAH project directory. It was just a matter of cutting and pasting the required entries from the supplied .aistub files into my app_info.xml file. My entries in the ap_cmdline line file were staight out of the readme. It worked straight off as an AP only on the GPU, AP + MB on the CPU machine.

I have been taking it slowly, first I ran MB on the CPU only to make sure the machine worked, then added the AP CPU app, then the NVidia GPU app running one task and finally going to two GPU tasks. It was all pretty straight forward with no real hassles. Mostly it's just cut and paste.

The next step is to add the x41zc MB GPU app into the mix. This machine is for experiments and testing, once I get things stable it all gets transferred to my main cruncher.

Take no notice of the errors on the machine above, they were all my fault as I was trying different driver versions, different apps etc. Most were caused by typos in the app_info file as I swapped back and forth :(.

One tip. I found you definitely need a <flops> entry in the AP GPU section of the app_info file. Without it the calculated ETA's were around 150 hours, even after 20 units had been processed (crunching time 35 minutes) and this was stopping BOINC from requesting new units.

T.A.

One tip. I found you definitely need a <flops> entry in the AP GPU section of the app_info file. Without it the calculated ETA's were around 150 hours, even after 20 units had been processed (crunching time 35 minutes) and this was stopping BOINC from requesting new units.

After receiving a couple of PM's on this subject, may I point out that for Astropulse the flops entry has be in scientific notation format. i.e XXXXe0x, where x is the number of zeros after the integer eg, 9 for Gigaflops, 8 for 100's of Megaflops etc.

Thus the entry for my GTX470 (1120GF)is...
<flops>1120e09</flops>

For a GTX550Ti (486GF) it would be
<flops>486e09</flops>

for a GTX 580 (1679GF)
<flops>1679e09</flops>

For a low powered card such as a GTS250 (756MF IIRC) (not recommended for AP work.)
the entry would be something like
<flops>756e08</flops>

and so on.

The flops value can be found at the top of the BOINC messages tab where the boot up details are.

This information is available in other threads, but it's buried pretty deep.

T.A.

Edit:
@ Raistmer, may I suggest that this information be added to the r1761 Readme.txt file.

@ Raistmer, may I suggest that this information be added to the r1761 Readme.txt file.

Done. Not for r1761 of course but for current rev.
If someone can propose adequate values for ATi cards or Intel GPU I would add such info in corresponding readmes.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

@ Raistmer, may I suggest that this information be added to the r1761 Readme.txt file.

Done. Not for r1761 of course but for current rev.
If someone can propose adequate values for ATi cards or Intel GPU I would add such info in corresponding readmes.

What exactly have you written? There seems to be scope for confusion here (not least, if people are sending TA advice by PM - where it isn't subject to peer review).

From what I remember of writing advice of how to set Flops entries back in 2009/10, before the advice was made redundant by the self-calibrating APR server, the format was irrelevant - you could use either a long string of digits, or exponential/scientific format, entirely to taste: whatever fits better with your early-years mathematical training.

The important thing, whichever style you choose, is to get the order of magnitude of the value right. Remember that the figure is FLOPS - not kiloflops, megaflops, gigaflops, or any other cultural collective like lakhs or crores of flops.

I'm guessing that the anonymous helpers were simply pointing out an easy way of keeping track of the numbers: there is certainly no way that a particular format could be needed just for Astropulse and not for setiathome_enhanced, since both values are being read and used by the same BOINC client.

Richard, just look svn. Committed.
If you have better wording you are welcomed.
The real issue not 1e9 or 1000000, real issue is completely inadequate BOINC time estimation. And we see such estimations again and again, and again, and again... no matter how newest BOINC's algorithm is.

EDIT:

self-calibrating APR server

we see on beta how such calibration misbehaves each new release. And sometimes it misbehaves TOO much to complete any task w/o BOINC aborting task.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Richard, just look svn. Committed.
If you have better wording you are welcomed.
The real issue not 1e9 or 1000000, real issue is completely inadequate BOINC time estimation. And we see such estimations again and again, and again, and again... no matter how newest BOINC's algorithm is.

Yes, I saw your checkin - where your quote suggests that the real issue is "... has [to] be in scientific notation format ..." - the opposite of what you've just said here. And the noun is 'advice', BTW.

If you experience problems with time to completion estimations from BOINC you could try this advise

IMHO quite clear when this advice should apply :)
Will try to re-formulate text below too though.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

From what I remember of writing advice of how to set Flops entries back in 2009/10, before the advice was made redundant by the self-calibrating APR server, the format was irrelevant - you could use either a long string of digits, or exponential/scientific format, entirely to taste: whatever fits better with your early-years mathematical training.

As I said, the information on setting flops values for AP was about, but it was deeply buried. The entry was required because the self calibration wasn't "self calibrating", as I said above, even after 20 completed units the ETA was still around 150 hours for GPU units that were only taking 35 minutes to complete.

I forget where I saw that info about entering the flops value in scientific notation (I looked at a lot of pages that night), it might have been here or over at Lunatics, but I did find that <flops>1120e09</flops> worked but <flops>1120000000000</flops> didn't.

The people who PM'ed me also had experience playing with flops values in app_info files and they couldn't get the long notation entries working either, hence my post above.

T.A.

Edit: BTW the PM's were asking me how I did it after reading this entry in a previous post of mine

One tip. I found you definitely need a <flops> entry in the AP GPU section of the app_info file. Without it the calculated ETA's were around 150 hours, even after 20 units had been processed (crunching time 35 minutes) and this was stopping BOINC from requesting new units.

The people who PM'ed me also had experience playing with flops values in app_info files and they couldn't get the long notation entries working either, hence my post above.

I am one of the people who asked TA about the flops.
I have been working with flops through the years (my app_info file was already scattered with flops for various projects and items), but this time it was behaving strangely.
Anyway, I now have put flops in scientific format and I am waiting for the first AP to be downloaded (no AP splitting at the moment) to see how it works.
The various tests have caused some WU loss in the process, but now everything is running smoothly again and I hope I can fine tune the flops value as soon as I get an AP WU.

In the meantime, many thanks to TA for helping in this process.

Sleepy

---

I forget where I saw that info about entering the flops value in scientific notation (I looked at a lot of pages that night), it might have been here or over at Lunatics, but I did find that <flops>1120e09</flops> worked but <flops>1120000000000</flops> didn't.

The people who PM'ed me also had experience playing with flops values in app_info files and they couldn't get the long notation entries working either, hence my post above.

T.A.

I'm having real difficulty getting my head round this one. In common with most 'real world' programming projects, BOINC makes extensive use of subroutines and library functions - small pieces of standardised code, which are used and reused again and again.

Getting some digits out of an XML file and interpreting the result as a number is one of those little chores that programmers have to do over and over again - so it's given to a subroutine. FLOPS is just another place where a string (up to 256 characters) is converted to a double-precision number.

BOINC has to handle numbers far larger than your 1,120,000,000,000 (13-digit) flops - I have a workunit with <rsc_fpops_bound> 7,000,000,000,000,000,000,000 (22 digits - not at this project). If the subroutine can't handle 13 digits, then there are much more significant problems to be found and cured down the line.

So, I'd really like to work out what's going wrong here, and cure it at source: putting a small note in an obscure readme file doesn't feel like an appropriate or adequate response.

Sorry Richard, I can't help you there, I'm just a hacker (in it's original sense). I try something, if it works, problem solved, if it doesn't I try something else. All the time without really knowing the why's and wherefore's what I'm doing.

I've learned up bits here and there from picking the brains of of people such as yourself but when it comes to programming, I'm a "black box" technician. :)

T.A.

Some memories:

Ive never used the scientific notation for flops and it allways worked on BOINC 6.10 and in BOINC 6.12, but, the longest number used was of 12 digits.

There was a lot of issues with the estimations not working on server side with ATI/AMD GPUS as their results were never counted as elegible for the estimations... and the only workaround was to use the FLOPS. But it works for NVIDIA GPUs.

---

I have downloaded an AP WU.
All is working fine now.
All was actually about the scientific notation.

Many many thanks to TA for pointing this out.

Happy crunching!

Sleepy

---

Sorry Richard, I can't help you there, I'm just a hacker (in it's original sense). I try something, if it works, problem solved, if it doesn't I try something else. All the time without really knowing the why's and wherefore's what I'm doing.

I've learned up bits here and there from picking the brains of of people such as yourself but when it comes to programming, I'm a "black box" technician. :)

T.A.

Ok, if you say it 'works' with scientific notation and 'does not work' when typing out the digits how exactly do you define 'work'?

Edit: I'm with Richard on this one. It shouldn't bloody matter which notation you use'. I've used non-scientific notation and it did its job.
The bloody flops arrive in non-scientific notation from the server, for God's sake. If you provide a setting in app_info.xml you just replace the server generated figure.
[And as Joe has pointed out on occasion, runtime estimate are not purely governed by the app_info.xml <flops> setting but by the server generated APR as well. I forgot the exact formula.]
If there are cases where that assumption turn out to be untrue it needs to be dissected very carefully.
NB scientific notation is 'easier' to use because it's so easy to miscount the number of '0' you need... For that reasdon scientific notation might be preferable but they should BOTH work.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Ok, if you say it 'works' with scientific notation and 'does not work' when typing out the digits how exactly do you define 'work'?

In my case, once the flops value was entered in the format XXXXe0x it brought the ETA down from ~150 Hrs to 38 minutes with nothing else being touched. BOINC immediately downloaded more AP units for the GPU instead of waiting till the running unit completed before requesting more units and only being given one.

Fellas please. Give me some credit for not being a complete idiot !

I can find my way around an app_info file, I can count to 9 without using my fingers and I do make sure of my facts before before posting.

In the past I've some some good wins, which include finding the reason for a quirk in the use of the original Rescheduling program and (not SAH related) a work around for a bug in the Fedora installation program which had all the "gurus" stumped. There are others, but I can't recall them atm.

I agree it should not make any difference what format the flops value is entered in but evidently it does and I'm not the only one to find this.

I've used non-scientific notation and it did its job.

So have I ! But in this case it didn't work. Do you really think I would have posted if it did ?

Because I'm not a programmer, I can't fix it. So I'm passing it on to those who's area of expertise is in that domain.

So stop inferring I'm a f***wit and if something needs to be fixed, fix it.

T.A.

After my outburst above, here is some information that might prove useful.

The ETA's for GPU units on my rig were currently sitting at 43 minutes.

I stopped the rig and edited the app_info file, entering the flops value in the long format. On restart the GPU ETA's were 50 minutes.

I then removed the flops entry completely and the ETA's blew out to 258 hours. Nearly 100 Hours more than the original estimate.

However, when I fired up the NV_r1761 app for the first time, the ETA's were ~160 hours. I entered the flops value in long format and the ETA's did not change.

I double checked my app_info file and the flops entry was in the correct position and had the correct number of zeros.

I then went looking, both here and on Lunatics because I vaguely remembered reading something that the flops value for AP was calculated differently than it was for MB. It was during this search that I found the reference that said for AP the flops entry had to be in scientific notation.

I then entered the flops value this way and on a restart the ETA's were within five minutes of the actual crunching time.

Since then the rig has completed around 400 GPU units. So any server side calculations would now have had a chance to stabilise and under these conditions the long format entry works.

Maybe this problem only occurs on new installs of the app ?

@ Sleepy. Since you would have only completed a few units. Could you please repeat the experiment I did and report what you find ?

Edited for clarity

T.A.