64 bit systems now using 32 bit application for Linux
log in

Advanced search

Message boards : Number crunching : 64 bit systems now using 32 bit application for Linux

Author Message
Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2560 - Posted: 25 Aug 2015, 1:20:00 UTC

I just noticed that my 64 bit systems that used to use the 64 bit vina application are now using the 32 bit version. I double checked and it certainly appears that way. They are all using the i686 version rather than the X86_64 version. All are Linux systems. I used the file command on the executables to assure myself that the 32 bit version is being used. Looks like this started happening within the past week or so. At the same time I've noticed a serious drop in my average credit.

Ben, can you check this out? Let me know what other info you may need.

Charlie
____________

Ananas
Send message
Joined: 8 Jun 13
Posts: 128
Credit: 1,947,833
RAC: 0
Message 2561 - Posted: 25 Aug 2015, 2:12:51 UTC - in response to Message 2560.

Under Win XP x64 it seems to be a bit random, wether it uses x64 or x86 version.

It started to use x64 some time ago (it might even have happened on the same date when the behaviour of your boxes changed) - but under Windows it doesn't make any difference, the two binaries differ only in the name but other than that they are exactly identical.

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2562 - Posted: 25 Aug 2015, 12:16:14 UTC

I stopped new tasks from downloading. I let the tasks I had all finish. I then reset the project. The project folder emptied except for my app_config.xml file. I then allowed new tasks. Along with all the new tasks it only downloaded the 32 bit executable. So, all tasks are running with the 32 bit and not the 64 bit executable.

Charlie
____________

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2577 - Posted: 11 Sep 2015, 15:38:02 UTC

Just bumping this to see if anyone else is seeing this.
____________

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2580 - Posted: 14 Sep 2015, 19:57:24 UTC

Just tried something else. Stopped new tasks from being downloaded and let the system finish everything it had. Then I stopped boinc, reinstalled both the boinc-client and boinc-manager packages from the fedora repository (they have not changed in ages). Started boinc back up and attached to the project. Same thing. It only downloads the 32 bit executable. This is my system:

http://findah.ucd.ie/show_host_detail.php?hostid=35108

What makes a project's BOINC server decide whether to use the 32 bit executable or the 64 bit executable for a particular host?

Charlie
____________

Profile Ben
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 17 Nov 14
Posts: 316
Credit: 1
RAC: 0
Message 2581 - Posted: 16 Sep 2015, 9:59:43 UTC - in response to Message 2580.

I checked the file signature and it's correct. So, I don't know why you can't use Vina x64...

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2582 - Posted: 16 Sep 2015, 11:44:18 UTC

Do you know how it decides whether to send me 32 or 64 bit tasks? Maybe something is wrong on my end and my system is sending bad information. Maybe I'm missing some 64 bit version of some library. I realize it's not critical. It's just something that bothers me.

Charlie
____________

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2583 - Posted: 16 Sep 2015, 12:28:44 UTC

I looked at the file /var/lib/boinc/sched_request_findah.ucd.ie.xml. I noticed this snippet:

<platform_name>x86_64-pc-linux-gnu</platform_name> <alt_platform> <name>i686-pc-linux-gnu</name> </alt_platform>


Need to figure out what is causing the alt_platform section. Hints appreciated.
____________

Richard Haselgrove
Send message
Joined: 30 May 15
Posts: 25
Credit: 1,979,129
RAC: 1,584
Message 2584 - Posted: 16 Sep 2015, 15:46:14 UTC - in response to Message 2581.

I checked the file signature and it's correct. So, I don't know why you can't use Vina x64...

This will be a long and complex (and still not necessarily true) attempt at an explanation. Bear with me, even if the final decision is "we'll just have to live with it - it's not a disaster".

Provided any necessary 32-bit compatibility libraries are either installed, or supplied with the application, 32-bit applications are perfectly valid alternative binaries on 64-bit operating systems, both your Linux and my Windows. The question - since Vina64 certainly can be run - becomes "Why won't BOINC choose the 64-bit version?".

I think it's because BOINC attempts to measure and record the efficiency of each available application, and then preferentially chooses the "most efficient" version for future work.

The tools available for this are pretty sparse. In the initial stages, after a new computer is attached to a project, all BOINC has available is the floating point (whetstone) benchmark, and that isn't differentiated into 32-bit and 64-bit - so it's no help here.

But once tasks are running, BOINC can measure the speed of the various applications directly. It looks at the size of each task (measured in floating point operations), and the time it takes to run (in seconds), to calculate the speed at which that application ran that particular task (in FLOPs). As computers complete hundreds or thousands of tasks, these individual task speed records are averaged to combine into a - supposedly more reliable - performance measurement of each application on each specific computer.

All of this is spelled out in more detail in the BOINC Design Documents, in particular the closely-related Job runtime estimation and Credit system as of 5/2010.

The fly in the ointment for this particular project is the measure of what I deliberately glossed over as "the size of each task". That's the vague, hand-waving version: the value actually used is the <rsc_fpops_est> assigned to each workunit on creation by the workunit generator on the server. As the name suggests, that value is an estimate before crunching even starts, and BOINC lacks the capability to refine that estimate with an accurate fpop count on completion.

There is some evidence that the <rsc_fpops_est> values for this project's WUs are, ahem, 'interesting', and not necessarily in direct proportion to the final measured runtime - as they would need to be for BOINC's runtime estimation algorithm to succeed.

The evidence is easy to find, but far harder to correct. The "performance measurement" by application version is available for every host on this project. It's known as the 'APR' (for Average Processing Rate), and is accessible on the application details page for each computer on this website.

Since Charles Dennett has asked the question, let's look at the Application details for his Computer 35108. Immediately, we can see the problem:

64-bit: Average processing rate 0.47 GFLOPS
32-bit: Average processing rate 6.97 GFLOPS

Wouldn't you choose the 32-bit app if it was really 16x faster that the 64-bit app?

But it isn't, really. Compare two of my Windows machines:

Application details for host 105080
64-bit: Average processing rate 4.15 GFLOPS
32-bit: Average processing rate 0.48 GFLOPS

Application details for host 105172
64-bit: Average processing rate 0.62 GFLOPS
32-bit: Average processing rate 9.62 GFLOPS

Two roughly similar CPUs (i5 and i7 respectively), both running Windows 7 - and completely contradictory estimates. Although I've not caught a machine in the act, I suspect those very low estimates of around half a gigaflop arise from the extended runs of FiNDAH tasks with tiny rsc_fpop_est values (translating to zero-length runtime estimates, as have been commented on here before), but which take an appreciable time to run.

If we could, first, re-normalise the rsc_fpops_est curve, and secondly reset all the runtime estimate tables, we might set off again on the right foot. But as I said at the beginning, it might be easier just to put up with the current situation.

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2585 - Posted: 16 Sep 2015, 16:18:57 UTC - in response to Message 2584.

Richard,

Thank you for that excellent analysis. It certainly make sense to me. I mentioned over in the generic BOINC forum that I had to rebuild one of my systems this past weekend and it went from using the 32 bit version back to using the 64 bit version. Here is its details:

http://findah.ucd.ie/host_app_versions.php?hostid=35111

Note the 64 bit APR is 5.53 GFLOPS as opposed to the 32 bit 5.37 GFLOPS. It will be interesting to see if the 64 bit APR drops low enough over time so that the 32 bit APR is higher than the 64 bit APR and the system flips over to it.

Meanwhile it would be nice to get a project wide reset on these values if that was possible.

I also wonder if there is a way I can make the project think I've rebuilt my other systems without actually having to do that. I've already detached and reattached from the project and that didn't help.

Again, thank you for that great explanation.

Charlie
____________

Richard Haselgrove
Send message
Joined: 30 May 15
Posts: 25
Credit: 1,979,129
RAC: 1,584
Message 2586 - Posted: 16 Sep 2015, 16:57:11 UTC - in response to Message 2585.

Charles, have you considered Ananas' first reply in this thread?

I've been periodically resetting the project here, to clear out the accumulation of data files, and thereby also deleting the downloaded application binaries. But since I have the two machines which have taken the different forks in the road, I was able to copy the files from one machine to the other, and repeat the experiment:

C:\BOINCdata\projects\findah.ucd.ie>fc /B C:\BOINCdata\projects\findah.ucd.ie\vina_1.2_windows_intelx86.exe C:\BOINCdata\projects\findah.ucd.ie\vina_1.2_windows_x86_64.exe Comparing files C:\BOINCDATA\PROJECTS\FINDAH.UCD.IE\vina_1.2_windows_intelx86.exe and C:\BOINCDATA\PROJECTS\FINDAH.UCD.IE\VINA_1.2_WINDOWS_X86_64.EXE FC: no differences encountered

(layout edited for clarity)

If that applies for Linux too, then there's absolutely nothing at all to be gained from forcing BOINC to use the copy which happens to have the 64-bit label attached.

Could I draw your attention to another of Ananas' posts: Wu last 3 hours instead of 14 min

In particular,

If this would be adjusted now, the multiplication factors for credits and fpops_est would have to be re-evaluated, requiring another test series. That's why I think it is better to leave it as it is for now, especially considering that Ben has important non-BOINC stuff to do at the moment.

There would be no benefit from doing a project-wide reset of the host_app_version table (although I believe the project administrator's operations console has that ability), unless the rsc_fpops_est calibration was corrected and re-evaluated first. We'd all end up in the same place, soon enough. And with understanding, I think we can live with what we have at the moment, at least until Ben's thesis is complete :-)

Profile Charles Dennett
Avatar
Send message
Joined: 18 Dec 14
Posts: 88
Credit: 3,342,826
RAC: 0
Message 2587 - Posted: 16 Sep 2015, 17:21:28 UTC - in response to Message 2586.

For Linux they are two different files:

file vina_1.2_x86_64-pc-linux-gnu

vina_1.2_x86_64-pc-linux-gnu: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=af60406ed08a9a9e4d56fab9aba1584f284e0d0a, not stripped

------

file vina_1.2_i686-pc-linux-gnu

vina_1.2_i686-pc-linux-gnu: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.24, BuildID[sha1]=225225c9785edfac73653cc5854cefd3a817be55, not stripped

I'm going to try one final thing and then probably give up. When my other system crashed and I rebuilt it, I obviously had to reinstall bonic. That's when it went back to using 64 bit. So, I'm letting all my tasks drain - I've stopped acepting new tasks. When it is totally empty, I will remove boinc and make sure all traces if are gone. I will then reinstall it and reattach to all the projects. We'll see what happens then.

And I agree - Ben has a lot more important things to deal with right now.

This is not an end of the world type of problem. It's just that sometimes I get working on a problem and won't let go, but that's just me.

Again, thanks for your help in this. You have a great way of explaining things.

Charlie
____________

Message boards : Number crunching : 64 bit systems now using 32 bit application for Linux


Main page · Your account · Message boards


Copyright © 2017 Dr Anthony Chubb