Here is the real 7.0.23 change log. The one above was really 7.0.22


7.0.23 change log

- client: small changes to make client compile on Android, and to report the platform as "arm-android". From Carl Christensen.

- client: job scheduling policy tweak: if CPUs are fully committed (e.g. with EDF jobs) allow GPU jobs but only up to CPU usage of ncpus+1

- client: Don't include VBox executive processes as non-BOINC CPU time. On some systems they use significant CPU time while VMs are running. TODO: do this only if we're actually running a VBox app

- client: if an app process exits because of a signal, don't show the "no finish file" message; not sure why this was there in the first place.

- client: if an app process exits because of a signal, show the signal correctly

- client: report completed results if a time-of-day network suspend is scheduled within the next 30 minutes

- client: Initialize buffer which is used to hold the temporary exit reason. If somebody didn't populate the reason when calling boinc_temporary_exit the buffer contained junk.

- client: set file ownership and permissions after an async verify. This was presumably the cause of the recent Einstein@home problem.

- client: set file ownership and permissions after an async copy.

- client: set file ownership and permissions after a regular (non-async) copy. The latter 2 bugs would affect a VM app that copies its executable to slot/x/shared

- client: change timeout for job quit/abort from 60 back to 15 (time between sending app a quit/abort message and, if not exited yet, killing it)

- client: if app has reported an "other PID" (e.g., vboxwrapper reports the VBoxHeadless PID) then include it (along with descendants) in the list of processes we kill when killing the job.

7.0.24 change log

- client/server: add optional <dont_use_dcf/> to schedule reply. If set, client won't use DCF for this project. Make this the default in server code; we now do runtime estimation entirely on the server side, and the client-side mechanism is counterproductive.

- client: if a job calls boinc_temporary_exit() 100 times, abort it. Otherwise it could keep doing it forever (e.g. if there's not ever enough available GPU RAM)

- client/server: estimate FLOPS for NVIDIA GPUs with compute capability 3.x. Not sure if the parameters are right (128 cores/proc, 2 flops/clock) but they're better than nothing.

- compile fix for redhat, from Steffen Moller

- client: report results if CPU suspend pending in next 30 min

- client: set PROJECT::last_upload_start whenever an upload starts, not just when a result becomes ready to upload. Fix bug where a scheduler RPC to report results is done even though uploads are active.

- client: cpu_sched_debug enables messages about not scheduling jobs because of insufficient RAM

- client/server: set cores/proc for NVIDIA compute capability 3.0 to 192 Why can't NVIDIA provide an API for this?????

- client: fix typo that prevented GPU jobs from running if CPUs were filled with EDF jobs

- client: fix bug where if we sent app a <quit> message, and it timed out and we killed it, we'd treat it as a job error. (This was a major bug).

- API: remove BOINC_STATUS::suspend_request. I meant to do this before.

- client: fix bug in reading reason for temporary exit

- lib: fix a valgrind warning

- client/scheduler: fix error in NVIDIA peak flops calculation

- Mac installer: When checking for duplicate group membership entries, count only whole words (preceded and followed by white space) so that if we have both 'jon' and 'jones' we don't count 'jon' twice.

- Mac uninstaller: Use Directory Services to find the user names of all human users instead of stepping through the entries in the /Users directory.

- client: Fix idle detection during fast user switching. See comments in HOST_INFO::users_idle() for details.

- client/server: add optional <dont_use_dcf/> to schedule reply. If set, client won't use DCF for this project. Make this the default in server code; we now do runtime estimation entirely on the server side, and the client-side mechanism is counterproductive.

Is this the begining of the the end for the DCF problem? Will we once again be able to build up a cache of work to do?

---

Grant
Darwin NT

Is this the begining of the the end for the DCF problem? Will we once again be able to build up a cache of work to do?

CreditNew doesn't use DCF.
It does use something similar, but it's not called DCF and the DCF the client sends to the project is ignored.

---

- client/server: set cores/proc for NVIDIA compute capability 3.0 to 192 Why can't NVIDIA provide an API for this?????

They do the function is called NvAPI_GPU_GetGpuCoreCount()

David Anderson made that comment in the Trac timeline on the 26th of March, in [trac]changeset:25496[/trac]. The conversation you're pointing to, dated the 28th of March, which is a copy of the original development list, is one between Richard and that same David. And as said, the API is only available for Windows, not for Linux or Macintosh.

---

I just tried 7.0.24. OS Win XP 32. Upgrade from 6.12.34 to 7.0.24.

1) After upgrade, 7.0.24 reports that it can't find my GPU, even after a reboot. Downgraded back to 6.12.34 and it couldn't find my GPU either. Uninstalled BOINC, and reinstalled without Protected Execution checked, and now 7.0.24 can find my GPU.

2) 7.0.24 BOINC manager screen auto-raises when I move my mouse over the window. This is a no-no. Only raise the window if you receive a mouse click or keyboard input in the window, not for just mouse movement.

---

Is this the begining of the the end for the DCF problem? Will we once again be able to build up a cache of work to do?

CreditNew doesn't use DCF.
It does use something similar, but it's not called DCF and the DCF the client sends to the project is ignored.

Jord, Credit new might not use DCF but DCF dictates when the computer will or will not request work.

Uninstalled BOINC, and reinstalled without Protected Execution checked, and now 7.0.24 can find my GPU.

That has been the case since Vista & Win7 was released. Installing as a Service or Protected Execution mode makes GPU crunching not possible.

---

Grant
Darwin NT

Uninstalled BOINC, and reinstalled without Protected Execution checked, and now 7.0.24 can find my GPU.

That has been the case since Vista & Win7 was released. Installing as a Service or Protected Execution mode makes GPU crunching not possible.

But as stated in my original post, I'm running XP where it is supposed to work, and indeed was working fine, before I installed 7.0.24. The install of 7.0.24 did something that borked it up in such a way that even rolling back to 6.12.34 didn't help.

---

Uninstalled BOINC, and reinstalled without Protected Execution checked, and now 7.0.24 can find my GPU.

That has been the case since Vista & Win7 was released. Installing as a Service or Protected Execution mode makes GPU crunching not possible.

But as stated in my original post, I'm running XP where it is supposed to work

Doh!

---

Grant
Darwin NT

But as stated in my original post, I'm running XP where it is supposed to work

Not since 6.12.38;
Since that version, even on XP, BOINC will disable the GPU detection when installed as a service. This was done, because something in the newer GPU drivers for both ATI and nVidia broke the detection of the card, which would crash BOINC.

As such, GPU detection when BOINC was installed as a service, was disabled for all Windows.

---

But as stated in my original post, I'm running XP where it is supposed to work

Not since 6.12.38;
Since that version, even on XP, BOINC will disable the GPU detection when installed as a service. This was done, because something in the newer GPU drivers for both ATI and nVidia broke the detection of the card, which would crash BOINC.

As such, GPU detection when BOINC was installed as a service, was disabled for all Windows.

Is David monitoring the 'even newer' ATI drivers to find out when he can go back to the status quo ante? I have three NVidia machines stuck at v6.12.34 because of this.

David Anderson made that comment in the Trac timeline on the 26th of March, in [trac]changeset:25496[/trac]. The conversation you're pointing to, dated the 28th of March, which is a copy of the original development list, is one between Richard and that same David. And as said, the API is only available for Windows, not for Linux or Macintosh.

OK, but given BOINC already contains NVAPI code I assumed calling another NVAPI function would not be an issue.

BTW NvAPI_GetDisplayDriverVersion() is deprecated and replaced by NvAPI_SYS_GetDriverAndBranchVersion().

    NvAPI_Status nvapiStatus;
    NV_DISPLAY_DRIVER_VERSION Version;
    memset(&Version, 0, sizeof(Version));
    Version.version = NV_DISPLAY_DRIVER_VERSION_VER;

    NvAPI_Initialize();
    nvapiStatus = NvAPI_GetDisplayDriverVersion(NULL, &Version);

// FUNCTION NAME: NvAPI_GetDisplayDriverVersion
//! \fn NvAPI_GetDisplayDriverVersion(NvDisplayHandle hNvDisplay, NV_DISPLAY_DRIVER_VERSION *pVersion)
//! This function returns a struct that describes aspects of the display driver
//!                build.
//!
//! \deprecated  Do not use this function - it is deprecated in release 290. Instead, use NvAPI_SYS_GetDriverAndBranchVersion.
//! SUPPORTED OS:  Windows XP and higher,  Mac OS X

seems to be some minor issues on Mac so expect a .25 version soon.
Also still issues on Windows 8 CP 64-bit with the install.
The same can't add users to group boinc_amdins.

---

Mike Bader
BOINC V7.16.5
http://setiathome.berkeley.edu/team_join_form.php?id=5 - Join Our International Team
[img]http://boinc.mundayweb.com/one/stats.php?

.25 is out for Mac

---

Mike Bader
BOINC V7.16.5
http://setiathome.berkeley.edu/team_join_form.php?id=5 - Join Our International Team
[img]http://boinc.mundayweb.com/one/stats.php?

NvAPI_GetDisplayDriverVersion() is deprecated and replaced by NvAPI_SYS_GetDriverAndBranchVersion()

Do I understand correctly that Driver Versions before 290 have only NvAPI_GetDisplayDriverVersion()
and Driver Versions after 290+ have only NvAPI_SYS_GetDriverAndBranchVersion()

If that's the case how a program can choose which function to call to get the Driver Version
before it knows the Driver Version which determines which function to call?

Catch-22 ;)

---

 


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

Новите драйвери имат и двете функции.
Ако не може да извика едната функция програмата, вика другата(въпреки че всеки нормален човек ще се запита за чий вика старата, а не направо новата :) ). Проблем ще се появи когато стара програма, в пълно неведение за новата функция, се опита да получи драйверна версия от драйвери, в които вече е премахната. Но това ще се случи след години, премахването. Майкрософт имат функции в Уиндоус, отбелязани като остарели още преди 10 години, но все още работят. Примерно ползването на ini файлове не се толерира още откакто 95 е излязъл, но всичко работи дори в Седем. Същото е и при Java. AWT е обявено за остаряло още преди 10 години, но все още работи.

---

Новите драйвери имат и двете функции.
Ако не може да извика едната функция програмата, вика другата(въпреки че всеки нормален човек ще се запита за чий вика старата, а не направо новата :) ). Проблем ще се появи когато стара програма, в пълно неведение за новата функция, се опита да получи драйверна версия от драйвери, в които вече е премахната. Но това ще се случи след години, премахването. Майкрософт имат функции в Уиндоус, отбелязани като остарели още преди 10 години, но все още работят. Примерно ползването на ini файлове не се толерира още откакто 95 е излязъл, но всичко работи дори в Седем. Същото е и при Java. AWT е обявено за остаряло още преди 10 години, но все още работи.

New drivers have both functions.
If you can not call a function the program calls the other (though any normal person would ask for the old whos calling, not a new right :)). Problems will occur when the old program, completely unaware of the new feature, try to get driver version of drivers have already been removed. But what will happen after years removal. Microsoft Windows functions are marked as obsolete 10 years ago but still work. For example, using ini files not be tolerated ever since 95 was released, but it works even in Seven. Same with Java. AWT has been declared obsolete 10 years ago but still works.

---

BOINC 7 is about to be released to the public. Mothers hide your children, daddies storm the BOINC forums en-mass to complain about the changes. Any minute now.

And the documentation and help links and all aren't up-to-date or working. Still busy with it. Feels like a job.

---