Hi,

I found a new version of boinc manager on chip.online today.
Version is 7.2.36 (x64).

I have been running 7.2.33.

I just got the download and tried what will happen after installation, during running projects on 7.2.33

The new version installed in the same directory, got the still runnig projects without problems.
And I think, it`s faster then before.

Have a nice day
Eckbert from Germany

I would highly recommend only downloading BOINC from their official download page. Since BOINC is open source, it is possible for a malicious person to modify the code and make it available through other sources as a method to infect your PC with malware or keyloggers to steal important account information.


Assuming that v7.2.36 has not been modified in any way, I can tell you that it is a beta version not intended for general use (BOINC is currently on v7.2.38 in beta only, the approved version is still v7.2.33). To answer your question more directly, nothing will happen to your existing tasks or projects under the new BOINC version.

Also, since BOINC doesn't do any crunching as it merely just manages your crunching projects for you, it cannot be faster in processing work by design. The only thing that can make your crunching faster is if a project releases a new application that provides greater enhancements over the previous project application.

Hi,

not official ??

http://boinc.berkeley.edu/dl/?C=M;O=D is to see, what versions are available.

And, where ever I look around vers. 7.2.36 is a normal version, and of course I looked for the author before installing.

Vers. 7.2.37 and 7.2.38 are those I know as beta.

Have a good time.
Eckbert

Being "available" and being the current recommended version are two different things. Upgrading to a newer version just because it is listed on http://boinc.berkeley.edu/dl/?C=M;O=D does not mean you should upgrade to it.

Even with that said, the fact that you found the version on a different site, one that is not hosted by the BOINC servers, means that it could have been modified and re-posted. You should only download BOINC from the official site.

As you can see here, the recommended version is still v7.2.33, making v7.2.36 not ready for prime time until the developers see fit to label it "recommended".

http://boinc.berkeley.edu/dl/?C=M;O=D is to see, what versions are available.

Better use the BOINC Change Log thread, for when a version is retracted by the developers, that thread will also reflect that. It'll also show the actual changes to the client, plus the disclaimer information about what you must expect when you want to use non-recommended versions of BOINC.

---

Hi,

you were right with your answers.

I just looked at the first result of running with 7.2.36.
Shows a very short time for working. Only some seconds were done.

It is accepted bei Seti at this time ......
But .....

And also looked into the programcode what had happend while the job.
I found some guys in it, who offer some (thay say better working) on the german seti page.

These ideas are included in 7.2.36.

But ..... I got no CPU 8 times working parallel, only 2.
And so on .....

I hope, the result is not bad for my wingman at all ........ (sh....)

Thanks for your help !!!!

Of course I`m running now with 7.2.33 as you told me.

Thanks a lot.

Have a nice day.
Eckbert

It is accepted bei Seti at this time ......
But .....

Well, yes, the results that are returned by the SETI application will be accepted. Whether they're accurate or not is another question. Of course, the SETI application has nothing to do with BOINC.

And also looked into the programcode what had happend while the job.
I found some guys in it, who offer some (thay say better working) on the german seti page.

These ideas are included in 7.2.36.

But ..... I got no CPU 8 times working parallel, only 2.
And so on .....

Not quite clear what you're saying here, but if you're saying that they've modified BOINC code to allow applications to work in parallel, that has nothing to do with BOINC and everything to do with the science applications. Most science applications are single-threaded and therefore can only run on a single CPU or core at a time. There is at least one project that I know of that has a multi-threaded application that can use two CPUs or cores at the same time, but that's it.

I would be very skeptical of any claims that by modifying the BOINC source code that they allow science applications to run faster. Either their work is not very well tested or their claims are dubious to hide more malicious intent.

Hi again,
here the message to the done work. As I told, I`ve only 2 compute units in my CPU. As you can see as X2.

There are several German pages wellknown and normaly correct, which tell that there is a new version
7.2.36. They also say 7.2.38 is a beta.

I will write to them authors to be wrong, to avoid complications to others, who read it and do the same, I did.

Stderr Ausgabe

<core_client_version>7.2.36</core_client_version>
<![CDATA[
<stderr_txt>
Running on device number: 0
DATA_CHUNK_UNROLL at default:2
DATA_CHUNK_UNROLL at default:2
Priority of worker thread raised successfully
Priority of process adjusted successfully, below normal priority class used
OpenCL platform detected: NVIDIA Corporation
BOINC assigns device 0
Info: BOINC provided device ID used
Used GPU device parameters are:
Number of compute units: 8
Single buffer allocation size: 256MB
max WG size: 1024
FERMI path used: yes

Build features: Non-graphics OpenCL USE_OPENCL_NV COMBINED_DECHIRP_KERNEL FFTW USE_INCREASED_PRECISION USE_SSE2 x86
CPUID: AMD Athlon(tm) II X2 250 Processor

Cache: L1=64K L2=1024K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3
AstroPulse v.6
Non-graphics FFTW USE_CONVERSION_OPT
Windows x86 rev 1316, V6 match, by Raistmer with support of Lunatics.kwsn.net team. SSE2

OpenCL version by Raistmer

ffa threshold mods by Joe Segur
SSE3 dechirping by JDWhale
Combined dechirp kernel by Frizz
Number of OpenCL platforms: 1


OpenCL Platform Name: NVIDIA CUDA
Number of devices: 1
Max compute units: 8
Max work group size: 1024
Max clock frequency: 1084Mhz
Max memory allocation: 1073741824
Cache type: Read/Write
Cache line size: 128
Cache size: 131072
Global memory size: 0
Constant buffer size: 65536
Max number of constant args: 9
Local memory type: Scratchpad
Local memory size: 49152
Queue properties:
Out-of-Order: Yes
Name: GeForce GTX 770
Vendor: NVIDIA Corporation
Driver version: 332.21
Version: OpenCL 1.1 CUDA
Extensions: cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_d3d9_sharing cl_nv_d3d10_sharing cl_khr_d3d10_sharing cl_nv_d3d11_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64


state.fold_buf_size_short=65536; state.fold_buf_size_long=262144
Info : Building Program (binary, clBuildProgram):main kernels: OK code 0


In ap_remove_radar.cpp: get_indices_to_randomize: num_ffts_forecast < 100. Blanking too much RFI?
percent blanked: 100.00
class T_remove_radar: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_main_loop_L1: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_FFT_forward: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_remove_radar_randomize: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_build_chirp_table: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_DataWrite: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_DataWrite_ns: total=0, N=0, <>=0, min=0 max=0
class T_oclReadBuf: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_ChirpWrite: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_ChirpWrite_ns: total=0, N=0, <>=0, min=0 max=0
class T_dechirp: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class Dechirp_ns: total=0, N=0, <>=0, min=0 max=0
class Half_ns: total=0, N=0, <>=0, min=0 max=0
class T_PC_single_pulse_kernel_FFA_update: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class PC_ns: total=0, N=0, <>=0, min=0 max=0
class T_oclReadBuf: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_oclWriteBuf: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_FFT_inverse: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_ffa: total=0.00e+000, N=0, <>=0.00e+000, min=1.84e+019, max=0.00e+000
class T_GPU_buffer_read_backs: total=0, N=0, <>=0, min=0 max=0
USE_OPENCL OPENCL_WRITE USE_INCREASED_PRECISION SMALL_CHIRP_TABLE COMBINED_DECHIRP_KERNEL
rev 1316
15:04:52 (3024): called boinc_finish

</stderr_txt>
]]>
Thanks Eckbert

Hi again,
here the message to the done work. As I told, I`ve only 2 compute units in my CPU. As you can see as X2.

The output you supplied (which I snipped to save the scrolling) is for an nVidia GPU unit that was able to do 2 workunits at once. Again, this doesn't have anything to do with BOINC, but the science application. This can be done with any app_config.xml file to tell BOINC to run more than once workunit on the GPU. You don't need a customized version of BOINC to do this.

There is a lesson here - Only get BOINC from the prime source, not a third party who:
a) May have "fiddled" with the source code in some way
or
b) May be distributing the general population an out-dated test version which may be problematic.

In this instance the version being distributed by chip.online is an "old" ALPHA version, and has been superseded in the test cycle, which is now (2014/01/22) at version 7.2.38....

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

There is a lesson here - Only get BOINC from the prime source, not a third party who:
a) May have "fiddled" with the source code in some way
or
b) May be distributing the general population an out-dated test version which may be problematic.

When running Linux and your only option is to get a reasonably updated BOINC from repositories, you have no choice what version is given out. In the case of many Linux distros out there, 7.0.27 was (and still is!!) a recommended update, while this one had many troubling problems as a beta, and the official recommended by BOINC was 7.0.28

It can also happen that the maintainers have to fiddle with the source code to make it possible that a newer BOINC will build with older libraries. Not all distros have all the right updated libraries to be able to run Berkeley BOINC (or else they all would). So to then be able to make a 'newer BOINC', they'll adjust things slightly so they can build with older libraries, and without too many errors.

---

Eckbert wrote:

...
In ap_remove_radar.cpp: get_indices_to_randomize: num_ffts_forecast < 100. Blanking too much RFI?
percent blanked: 100.00
...

That's why the task took only a few seconds. When the program checked the data for RFI, it decided there wasn't enough good data to do any analysis so it just quit immediately. It was just a coincidence that was the first task after you'd installed BOINC 7.2.36.

                                                                   Joe

There is a lesson here - Only get BOINC from the prime source, not a third party who:
a) May have "fiddled" with the source code in some way
or
b) May be distributing the general population an out-dated test version which may be problematic.

When running Linux and your only option is to get a reasonably updated BOINC from repositories, you have no choice what version is given out. In the case of many Linux distros out there, 7.0.27 was (and still is!!) a recommended update, while this one had many troubling problems as a beta, and the official recommended by BOINC was 7.0.28

It can also happen that the maintainers have to fiddle with the source code to make it possible that a newer BOINC will build with older libraries. Not all distros have all the right updated libraries to be able to run Berkeley BOINC (or else they all would). So to then be able to make a 'newer BOINC', they'll adjust things slightly so they can build with older libraries, and without too many errors.

Mmmm... I'm running version 7.2.0-r1 from a linux distro repository...

The question becomes more of which of the new Boinc versions offer some sort of significant improvement. There is a trade-off between frequent updates and disruption.


As for compiling the source code from Berkeley: I hope they have it clearer and tidied up from when I last looked at it! A "simple compile" turned into a guess what is where game :-(. All this should be easy when tidily done...

(I'm very happy to be shot down in flames with comments that Berkeley have made it all easy! :-) )


Happy fast crunchin',
Martin


BTW: Never download code/programs/applications from an untrusted source!!!!!

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

The question becomes more of which of the new Boinc versions offer some sort of significant improvement. There is a trade-off between frequent updates and disruption.

There haven't been too many BOINC "recommended" releases as of late. Other than going quickly from v7.2.28 to v7.2.33 to fix a few bugs, I think the last recommended release was nearly a year prior if I recall correctly.

As for compiling the source code from Berkeley: I hope they have it clearer and tidied up from when I last looked at it! A "simple compile" turned into a guess what is where game :-(. All this should be easy when tidily done...

Last I checked the compile articles in the Wiki, they were already way out of date. I doubt that has changed in the mean time. And since there's hardly anyone from the community with that knowledge updating the Wiki(s), also due to David sometimes going in a just changing everything someone else so painstakingly wrote down, I don't think that's going to change any time soon.

I gave up adding to the User Manual Wiki due to David rewriting a lot of the stuff I put in. It's now less informative than what I had written down. I wonder if he knows what a Wiki is for. Anyway...

---

Last I checked the compile articles in the Wiki, they were already way out of date. I doubt that has changed in the mean time. And since there's hardly anyone from the community with that knowledge updating the Wiki(s), also due to David sometimes going in a just changing everything someone else so painstakingly wrote down, I don't think that's going to change any time soon.

So what is so bad about the compile articles? I'm assuming you started from Installing_BOINC#Build_from_Source(*) in User Wiki and then continued to the three pages in Trac.

The User Wiki page doesn't really say enough to get out of date and skimming though the Trac pages I don't think they are that bad. Yeah, sure, the versions numbers in the example might be old but, dammit, package managers have search capabilities. You don't need to know the exact version, just search for the package name and let the package manager do the rest.

As for the building instructions I didn't spot anything that's clearly out of date or incorrect. Maybe they aren't as clear as they could be and you need to read them twice but, still, not that bad.

<edit> Oh... I went to close the tabs and just noticed that some of the pages talk about Core Client. Ok, the pages are out of date, happy now :) </edit>

(*) There's two more pages: Compiling_the_core_client which is copied from Trac, isn't linked from anywhere and is rather brief. IMHO you could just remove it. The third page, Installing_on_Linux, doesn't have anything that the first page didn't have.