Wed 08 Jul 2020 06:29:11 PM CDT | | [work_fetch] target work buffer: 8640.00 + 604800.00 sec

Wed 08 Jul 2020 06:29:11 PM CDT | | [work_fetch] shortfall 4562751.58 nidle 0.00 saturated 22834.00 busy 0.00

I saw that QMC had new work, so reenabled it on two machines, (hyperthreaded quads), one machine downloaded 6 tasks the other seven. All had expected runtimes of 2-3 days, no problems with that, due date was a couple of weeks away.

The runtimes are optimistic, they crawl along on both of my 4GHz i7's, but looked to be possible anyway, so I left them going.

Today, the machine with six jobs is back to showing 1.000% complete, the estimated run times have changed one is 3d 16:06 and counting, two of the others show 370+ days, two more 390+ days and the last 422+ days. This machine has now used upwards of 21 days on these jobs. All aborted - 21 days of crunching wasted.

The other machine has all seven tasks still running, showing from 64.626% complete, (2d 23:37:30 elapsed), down to 39.556% complete, (1d 30:02:25 elapsed). However tempting, I am not aborting them - YET.

I have, obviously, set no new tasks on both systems.

@Juha, you are correct: The idle detection in that version appears to be broken and it seems to think that the machine is always in use. Hopefully the package maintainers can see their way clear to an update soon!

Does this not indicate anything?

OK, as I suspected, curiosity got the better of me. I created the two batch files BobCat13 suggested in the message I'm replying to.

And it failed. Watching the changes in the second data directory, I saw a file stderrdae.txt being created, with the contents

05-May-2016 15:50:59 Another instance of BOINC is running.
GLE: Cannot create a file when that file already exists.

 (0xb7)

Armed with that information, I edited the cc_config.xml file for the first (originally running) instance, with the

<allow_multiple_clients>1</allow_multiple_clients>

option, and restarted the first client. After that, everything worked as advertised. Two different clients running (two instances of boinc.exe in Task Manager), two different instances of boincmgr.exe in Task Manager as well, two different displays on screen with different project lists, etc. etc.

@Bobcat, Thinking about the BOINC Manager trouble, do you have any specific exceptions set in the firewall - and if so, which firewall do you use?

You can try to use boinccmd, but it may also like the first BOINC only. I don't think there is a way to tell boinccmd to point to a second running client.

C:\Program Files\BOINC>boinccmd --host 127.0.0.1:31418 --passwd xxxxxxxxxx --get_cc_status
network connection status: don't need connection
CPU status
    not suspended
    current mode: according to prefs
    perm mode: according to prefs
    perm becomes current in 0 sec
GPU status
    not suspended
    current mode: according to prefs
    perm mode: according to prefs
    perm becomes current in 0 sec
Network status
    not suspended
    current mode: according to prefs
    perm mode: according to prefs
    perm becomes current in 0 sec

C:\Program Files\BOINC>boinccmd --host 127.0.0.1:31418 --passwd xxxxxxxxxx --set_network_mode never

C:\Program Files\BOINC>boinccmd --host 127.0.0.1:31418 --passwd xxxxxxxxxx --get_cc_status
network connection status: don't need connection
CPU status
    not suspended
    current mode: according to prefs
    perm mode: according to prefs
    perm becomes current in 0 sec
GPU status
    not suspended
    current mode: according to prefs
    perm mode: according to prefs
    perm becomes current in 0 sec
Network status
    suspended: user request
    current mode: never
    perm mode: never
    perm becomes current in 0 sec

C:\Program Files\BOINC>

And now, in contrast to as it acted before, the second one does NOT say "wrong password" right after trying to connect once, but I can see in the lower right corner of the Manager window "connecting to 127.0.0.1" and "disconnected" - in about 2-3 seconds intervals, all time long, until I close the Manager.

all_projects_list.xml
client_state.xml
client_state_prev.xml
coproc_info.xml
daily_xfer_history.xml
global_prefs_override.xml
gui_rpc_auth.cfg
stderrdae.txt
stderrgpudetect.txt
stdoutdae.txt
stdoutgpudetect.txt
time_stats_log

There should also be one folder named Notices. If only the gui_rpc_auth.cfg is present, then the second client has not started properly.

Create a shortcut to BOINC Manager on the Desktop and change it's properties to read:
"c:\Program Files\BOINC\boincmgr.exe" /m /n 127.0.0.1 /g 31418 /p xxxxxxxxxxxxxx

after following all the steps as described, I could get the second BOINC manager to open, but right thereafter the message "the password you have provided is incorrect - please try again" shows up :-(

I had replaced the many xxx with exactly what was contained in the original gui_rpc_auth.cfg. So - no idea why this password is not being accepted.

So, unfortunately, the second BOINC manager does not work here :-(

Hence, my plan would have been to install a second BOINC not on the RAMDisk, but on the SSD, just for GPUGRID, and leave ATLAS plus WCG on the RAMDisk.
Okay, this obviously is not that easy.

1. Jord has localhost set in his command for the second Manager, but I cannot get that to work and only 127.0.0.1 works for me.
2. If you don't plan on using the GPU on the first client, you could uninstall boinc and reinstall as a service to disable the GPU and only attach to GPU projects on the second client.
3. On the client/Managers, you may need to change the "Suspend when non-Boinc CPU usage is above" to 100 as the clients see each others usage as non-Boinc.
4. If you don't want to use 2 Managers, you could use BoincTasks and set it up to control both clients from the same GUI.