Hal, do you know which clinfo executable you use, and where you got it from?
There's a variety of clinfo executables out there, but not all show the "Board name". I've got at least 3 clinfo versions on my system, two of which don't show it, one does. I'm doing a search for this third one that can.

Have done a search for clinfo's source code as well, have found various versions but none do "Board name".

Edit: seems I have found it.
{ CLINFO_BOTH, DINFO(CL_DEVICE_BOARD_NAME_AMD, "Device Board Name (AMD)", str), dev_has_amd },

You already found it, but It looks like the clinfo I'm using is from the Radeon driver.

On my R9 390x I get
Board name: AMD Radeon (TM) R9 390 Series
Name: Hawaii

If this value is consistent enough it could same the time and effort in manually hard coding names in the future.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

Hal, do you know which clinfo executable you use, and where you got it from?
There's a variety of clinfo executables out there, but not all show the "Board name". I've got at least 3 clinfo versions on my system, two of which don't show it, one does. I'm doing a search for this third one that can.

Have done a search for clinfo's source code as well, have found various versions but none do "Board name".

Edit: seems I have found it.
{ CLINFO_BOTH, DINFO(CL_DEVICE_BOARD_NAME_AMD, "Device Board Name (AMD)", str), dev_has_amd },

---

Do Nvidia GPUs provide a value for Board name as well? Perhaps that could be used as a fall back instead of Name?

As I understand it, Nvidia has all their GPU names in the drivers and so when BOINC queries the CUDA and OpenCL status, the drivers tell what GPU is installed.

I'll ask why we can't use the clinfo info, although it may be that when one runs clinfo on the Fiji GPU, that they just see the same string.

---

Okay, appears I have been mistaken.
The case numbers in the code are for CAL detection, but since the newer AMD GPUs no longer support CAL, they won't use these strings in the client for the detection of their name. Then OpenCL takes over and the short name is the only thing you see because OpenCL doesn't do these long name strings.

I always thought that OpenCL did given that one the strings returned from clinfo returns the long name for the device.
Board name: AMD Radeon HD 6300M Series
vs
Name: Cedar

Do Nvidia GPUs provide a value for Board name as well? Perhaps that could be used as a fall back instead of Name?

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the BP6/VP6 User Group today!

Okay, appears I have been mistaken.
The case numbers in the code are for CAL detection, but since the newer AMD GPUs no longer support CAL, they won't use these strings in the client for the detection of their name. Then OpenCL takes over and the short name is the only thing you see because OpenCL doesn't do these long name strings.

---

BTW. With the newer BOINC versions (>v7.6.9) the new AMD VGA cards will be shown like the older ones (incl. driver version)?

My FuryX's:
AMD Fiji (4096MB) OpenCL: 2.0

AMD Fiji (4096MB) OpenCL: 2.0 is the name given by OpenCL. The old name was given by CAL, but since AMD stopped developing for CAL, we can no longer detect the name from that.
The longer name is hardcoded in the client. So yours will be, with a newer client, an AMD Radeon R9 Fury/R9 Nano/R9 Fury X/R9 Fury X2 (Fiji).

See gpu_amd.cpp lines 241 and further for the hardcoded names of the AMD GPUs. I have added all the new ones not too long ago.

Until AMD comes around to adding the full name of their GPUs to OpenCL or another library, there isn't anything we can do about it, but keep adding their names to the client once every so many revisions.

---

You can forget my concern about single or double dashes. From the current code:

// Parse the command line arguments passed to the client
//
// Check for both -X (deprecated) and --X

BTW. With the newer BOINC versions (>v7.6.9) the new AMD VGA cards will be shown like the older ones (incl. driver version)?

Example:
AMD AMD Radeon HD 7870/7950/7970/R9 280X series (Tahiti) (3072MB) driver: 1.4.1720 OpenCL: 1.2

My FuryX's:
AMD Fiji (4096MB) OpenCL: 2.0

---

I've just been exploring this.

When BOINC is started by the BOINC Manager (the 'official' way, except for service installations), the command line set by the Manager is

"D:\BOINC\boinc.exe" --redirectio --launched_by_manager

(the root path is specific to the local machine - depends on installation choices)

--redirectio is supposedly to redirect the log - i.e. stdoutdae.txt - from the console to a file.

When BoincTasks is used to start the client, the command line is

"D:\BOINC\boinc.exe" -detach_phase_two

That's a very old formulation, but we persuaded Rom Walton to keep it in the code, for compatibility. I use the same command line for restarting the client when the Lunatics Installer has finished its work - except my line is

"D:\BOINC\boinc.exe" --detach_phase_two

(with the double-dash typical of *nix command line switches in verbose mode - that's how "boinc /?" shows them.)

I've not had any complaints about stdoutdae.txt being blank after a Lunatics restart, though that's not something many people would look for.

And anyway, I've just done several trial restarts using BoincTasks (hence with -detach_phase_two), and they were properly logged to the end of my existing stdoutdae.txt file.

Since you're a regular BoincTasks user, and I'm not, I suggest you discuss this with Fred.

Since I use BoincTasks (a few years on all PCs) the stdoutdae.txt files were 'empty' (or better, not used).

AFAIK, in past with stock BOINC there was also a stdoutdae.old file... - if stdoutdae.txt reached 2 MB size.
I don't know if this is up-to-date. At least now, there is no stdoutdae.old file in the BOINC/data folder.

I looked and the last modification date is Oct/08 of the stdoutdae.txt file.
In it just a few messages from the Oct/08 (34 lines).
BOINC start and exit (this was a test after installation of BOINC v7.6.9).

Maybe Fred did this for to reduce CPU time usage?

---

I let run the BoincTasks v1.69 Manager.
BOINCs stdoutdae.txt file is empty.

I have no idea where I could look instead.

stdoutdae.txt is written by the BOINC Client, so it shouldn't matter which Manager you use - BOINC's own, BoincView, BoincTasks, or any other.

I've never known the file be empty - I don't think logging can be turned off completely (though I'll check). Are you sure you're looking in the correct (currently active) BOINC Data directory? Did the file you looked at have a current timestamp?

Richard Haselgrove wrote:

It's possible that you shut down BOINC (or restarted the computer, which amounts to the same thing) just as a task was finishing: SETI may have written the 'finish file', but BOINC didn't have time to process it before shutting down.

In that case, the finish file would still have been present after your maintenance was completed, the system rebooted, and your manual start of BOINC. That's certainly longer than BOINC expects.

You can confirm that by looking in stdoutdae.txt, and finding out what was written to the message log just before the shutdown, and just after the restart. Search the log for the task name.

With one occurrence in 1,600 valid tasks, I'd call it an accident of timing, and nothing to worry about. Next time you do maintenance, use BOINC Manager to "Shut down connected client...", and do so when no task is about to complete.

I let run the BoincTasks v1.69 Manager.
BOINCs stdoutdae.txt file is empty.

I have no idea where I could look instead.


Richard Haselgrove wrote:

http://setiathome.berkeley.edu/forum_thread.php?id=78498

And with regard to my message 1742351 in that thread, I think it's now safe to try running alpha test version 7.6.20 - but the extended time limits still won't allow long enough for a full reboot cycle between a task finishing and BOINC processing the housekeeping.

It would be possible to add a longer 'extended time limit' to BOINC, so that the above mentioned will not happen?


BTW. BOINC v7.6.21 is a RC (release candidate)?


Thanks.

---

Thanks a lot Richard and Ageless! :)

[edit]
Meanwhile running 7.6.21 without problems on my oldest "main" rig.

---

Aloha, Uli

The 7.6.21 changelog is available.

---

The v7.6.20 change log is here.

Jord hasn't had time to update it yet (the new version was only released three hours ago), but Rom's notes are

* Updated localizations
* Fixed crash analysis code in the manager (Windows Only)
* Fixed GPU detection issues
* Fixed minimum password text in attach wizard

The one machine I've updated so far hasn't crashed yet. :-)

I already wanted to ask for version 7.6.20, now there is already 7.6.21.
I can't find the change log for it, is it good to go? :?

---

Aloha, Uli

Since this morning, the test version has moved on to v7.6.21 (Windows only - other versions, particularly Mac, may follow)

Note: if you, before starting BOINC, go to BOINC-Data\slots\ and delete all found there boinc_finish_called files - the tasks will restart at ~99% and finish OK

---

 


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

http://setiathome.berkeley.edu/forum_thread.php?id=78498

And with regard to my message 1742351 in that thread, I think it's now safe to try running alpha test version 7.6.20 - but the extended time limits still won't allow long enough for a full reboot cycle between a task finishing and BOINC processing the housekeeping.

It's possible that you shut down BOINC (or restarted the computer, which amounts to the same thing) just as a task was finishing: SETI may have written the 'finish file', but BOINC didn't have time to process it before shutting down.

In that case, the finish file would still have been present after your maintenance was completed, the system rebooted, and your manual start of BOINC. That's certainly longer than BOINC expects.

You can confirm that by looking in stdoutdae.txt, and finding out what was written to the message log just before the shutdown, and just after the restart. Search the log for the task name.

With one occurrence in 1,600 valid tasks, I'd call it an accident of timing, and nothing to worry about. Next time you do maintenance, use BOINC Manager to "Shut down connected client...", and do so when no task is about to complete.