Thread 'NVIDIA GPU beta — volunteers wanted'
Message boards : Solver development and optimisation : NVIDIA GPU beta — volunteers wanted
Message board moderation
Previous · 1 . . . 4 · 5 · 6 · 7 · 8 · Next
| Author | Message |
|---|---|
 Michael H.W. WeberNew member  Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274   
|
The second task is running now. 25% completion after approx. 5 Min already with apparently permanent full GPU- (79°C) and CPU-load (both cores). Looks much better, this time... Michael. President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559  |
In reply to Michael H.W. Weber's message of 31 Oct 2026: The second task is running now. Thanks for testing the second task, Michael, and for the clear feedback. Full GPU and CPU load is exactly what we hoped to see on your card. Great news! You're right about the credit. Four and a half hours for 1,200 credits is low, and I'm sorry your first task landed on the slower version. GPU credit is fixed per task, so it can't reflect long runs. I've added your remark to my list for after the sprint. I'd be very interested in the total runtime of this second task when it finishes. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
Unexpectedly, this task has been running for 3:55 (hrs:min) now without finishing - currently at around 98% completion and the GPU is idle again most of the time while the two CPU cores work under full load. That card is superior in most GPU DC projects compared to any other model - so, unfortunately, I suspect something is still wrong with this app. One curious question: GPU app version used for the FIRST (completed) task: Eternity II NVIDIA GPU 272 (65536v tickets) v2.80 (cuda_e2_ckpt280handoff_h4) windows_x86_64 GPU app version used for the CURRENT (UNcompleted) task: Eternity II NVIDIA GPU 272 (65536v tickets) v2.72 (cuda_e2_pubv_s2_ada_win_65536v_57be346b) windows_x86_64 --> So, the current app has an earlier (!) version number than the former? Michael. P.S.: Regarding the credits one needs to take 2x CPU cores plus the GPU work into account. And of course the GPUs require much more energy compared to CPU computations... President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
In reply to Michael H.W. Weber's message of 31 Oct 2026: Unexpectedly, this task has been running for 3:55 (hrs:min) now without finishing - currently at around 98% completion and the GPU is idle again most of the time while the two CPU cores work under full load. Thanks Michael, and you're right: something isn't good here, and it's in our app, not in your card. I was also too optimistic. I told you the normal version should behave much better, but your report shows that the older test version wasn't the whole story. Here is what we measure. Our GPU tasks end with a phase that runs on the CPU, and the GPU sits nearly idle during it. That's what you are seeing at 98%. On your batch size, about 40 to 45% of the GPU hours go to the last 5% of the work. So a very fast card can't shorten that phase. On Windows, over the last 3 days and on all cards, tasks of this size took a bit over 2 hours on average, and about 7% took more than 4 hours. Even RTX 5090 cards, which average about 1 hour, sometimes reach 4 hours. We haven't found the cause yet. Fixing it needs a new app version, which I won't release during the sprint, but it's at the top of my list right after it. Your report makes it even clearer that it must be fixed. About your version question: it does look odd! 2.80 was an experimental build made after 2.72. It turned out slower, so it was withdrawn, and 2.72 remains the normal version. The higher number doesn't mean it's better. You're also right about credit: the two CPU cores, the GPU and the energy all count. I've added that to my list. Your task is still useful, so please let it finish if you can: an aborted task gets no credit. One thing you could try, as your card sits idle during those endings: running two tasks at once, so the second one keeps the GPU busy. It isn't officially validated yet, but machines doing this have failed no more often than the others. I gave the steps here; for your card, the app name is eternity_gpu_272_65536v. If you do, please tell us how it goes. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
If possible at all (of course I don't understand the internal code workings), maybe the CPU and GPU part should be separated in different tasks for better GPU ressource usage. Michael. President of Rechenkraft.net e.V. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
Unfortunately, that task does not appear to finish. Will abort. Michael. President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
In reply to Michael H.W. Weber's message of 31 Oct 2026: Unfortunately, that task does not appear to finish. Michael, I'm really sorry: you lost nearly 8 hours on that task, and you were right to abort it. Thanks to your report and to a log from another volunteer, I think I now understand what happened. At the end of a task, the last tickets need a long CPU search. When only a few remain, the app is supposed to stop and hand them back, so that the CPU tasks finish them. But that only happens below a limit, and your task stopped with about 870 tickets left, just above it. Those tickets also have no time limit, so one of them can run for hours. This is very likely a flaw in our rules, not your card or your PC. Your idea is close to what the app already does: separate the end of the work into CPU tasks. The limit is simply too strict. I'm reviewing this now, and I'll tell you what we decide. Most tasks don't end this way: over the last 3 days, about 93% of tasks of your size on Windows finished in under 4 hours. If it happens again, and the progress hasn't moved for over an hour near 98%, please feel free to abort. I understand if you prefer to wait for the fix before trying again. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
Well, I could have completed two Einstein@home GPU gravitation wave tasks on that card per hour, so aborting it after 27,596.00 sec of total runtime while a similar task completed successfully on that same card with another GPU app in approx. 16000 sec is reasonable, I think. Just let me know once you have solved the problem. I also have an AMD Radeon AI PRO R9700 in that same machine which could be tested later on, once you start to look at the OpenCL code. Michael. P.S.: What I meant by separating is: separating into non-bound CPU and GPU-tasks because your app will block usage of that GPU without utilizing it for a very long time. President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
In reply to Michael H.W. Weber's message of 31 Oct 2026: Well, I could have completed two Einstein@home GPU gravitation wave tasks on that card per hour, so aborting it after 27,596.00 sec of total runtime while a similar task completed successfully on that same card with another GPU app in approx. 16000 sec is reasonable, I think. Hi Michael, you're completely right: aborting it after 27,596 seconds was the reasonable choice, especially when that card could have been doing useful work for Einstein@home during that time. I also understand your P.S. better now: the problem is that the task keeps the GPU reserved for a long time while barely using it. That's a fair point, and I've added it to my list as you describe it. I'll post in this thread once the problem is solved. I can't give you a date yet, and there's no need to run more tasks here until then. And thank you for offering the AMD Radeon AI PRO R9700: I've added you to the list of OpenCL testers. The OpenCL version is planned, but it has no date yet. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
@Michael H.W. Weber: a correction, and my apologies. I told you that 1,200 credits was low because GPU credit is fixed per task. That was incomplete. Your first task was a test task from a new version we're still developing, and it shouldn't have reached you. I'm sorry you got it by mistake, with so little credit. A normal task of your size pays about 88,000 credits, so you were right to find it far too low. I can't make changes during the sprint, but I'll post in this thread once the long endings are solved. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
In reply to benjamin's message of 31 Oct 2026: @Michael H.W. Weber: a correction, and my apologies. I told you that 1,200 credits was low because GPU credit is fixed per task. That was incomplete. Your first task was a test task from a new version we're still developing, and it shouldn't have reached you. I'm sorry you got it by mistake, with so little credit. A normal task of your size pays about 88,000 credits, so you were right to find it far too low. That is really a pity for my team during the challenge. Could you maybe re-assign the former (working) app to my GPU type, this time with correct credits? This way, I could complete at least 1-2 tasks during the sprint challenge. Also, here ist the log of the task which I had to abort. As you can see, it reaches almost completion very quickly and after that it just hogs my GPU: <core_client_version>7.24.1</core_client_version>
<![CDATA[
<message>
aborted by user</message>
<stderr_txt>
2026-10-31 11:25:51 (22524): wrapper: running ../../projects/boinc.eternityathome.org_eternity/bw_runner_nvidia_common_0.17.exe (--force-interleave --shard-index 383 --shard-count 4096 --force-jitter-start 1822771328 --force-jitters 1823435904 --threads 4 --gpu-slots 0 --node-cap 2000000000 --seconds 0 --exact-endgame 244:50000000 --endgame-probe 4 --endgame-ladder 4:236:1000000000,3:230:6000000000,2:224:64000000000,1:216:80000000000 --ring-breaks 236 --sigma-tail --no-sigma-main --ncon2-direct 1 --mrv-dem-inc 1 --main-fast 1 --min-save 463 --breaks 192,197,201,206,211,216,221,225,229,233,237,241,246,250 --root-allow exploration_allow.txt --seed 6152026 --epoch cloudflare-boinc-explore --tourney tour --ticket-cpu-seconds 0 --runner-tail-fraction 0.005 --runner-idle-handoff 90 --runner-underfill-handoff 90)
2026-10-31 11:25:51 (22524): wrapper: created child process 12280
NVIDIA beta: assigned device 0, automatic single resident wave, current-free-memory budget
pipeline: selected scientific engine e2_bw_nvidia_avx2_cuda12_0.4.exe
bw_runner: progress 0/65549 (0%), restored runtime 0 s
NVIDIA_RESOURCE_ADMISSION block=640 exit=0
[2026-10-31 11:25:52] heuristic colors: {13,16,10}, total edges 122 (ramp scale x1.000)
[2026-10-31 11:25:52] clue mode: FULL-CLUES (5 hints) -> corner-first fill order, heurScale 0.970 (mode default)
[2026-10-31 11:25:52] breaks (14 total, target completion score 466): 192,197,201,206,211,216,221,225,229,233,237,241,246,250
[2026-10-31 11:25:52] P13 SHARD 383/4096 jitterStart=1822771328 : ce worker traite les tickets globaux J0*nroots + 383 + 4096*local (sous-ensemble disjoint)
[2026-10-31 11:25:52] bw starting: 1 threads, seed 6152026, nodeCap 2.0B, heurScale 0.970, minSave 463, resume best 0, seconds 0
[2026-10-31 11:25:52] clue: piece 255 td(2,2) rot 2 -> bu cell (13,2) fill idx 188
[2026-10-31 11:25:52] clue: piece 249 td(2,13) rot 3 -> bu cell (13,13) fill idx 247
[2026-10-31 11:25:52] clue: piece 139 td(8,8) rot 1 -> bu cell (7,8) fill idx 120
[2026-10-31 11:25:52] clue: piece 208 td(13,2) rot 2 -> bu cell (2,2) fill idx 8
[2026-10-31 11:25:52] clue: piece 181 td(13,13) rot 2 -> bu cell (2,13) fill idx 45
[2026-10-31 11:25:52] FORCE_ROOT chargé: 3084 racines, 1823435904 jitters/racine, 1 threads
[2026-10-31 11:25:52] ROOT_ALLOW : 101 cidx autorisés / 3084 racines (65549 lignes lues, 0 hors-bornes ignorées) -> les autres cidx sont sautés (ticket/seed d'origine préservés)
[2026-10-31 11:25:52] TICKET_LOG ARME run_id=d959fcab999b481f cfg_hash=343c739dfb897fb9 dir=startup_probe/640/ticketlog (segment immuable v2)
[2026-10-31 11:25:52] HARVEST463 dir=startup_probe/640/harvest (board vérifié score>=463, identité SHA256)
[2026-10-31 11:25:52] table sizes: corners 16 leftSides 56 bottomSides 56 topSides 1288 rightNoBrk 56 rightBrk 1288 midNoBrk 764 midBrk 34380
[2026-10-31 11:25:52] ring-break tables (from fill depth 236, 8 border cells): corners 720 leftSides 2520 bottomSides 2520 topSides 2520 rightBrk 2520
[2026-10-31 11:25:52] special[0] (cell of clue 255): 1 entries
[2026-10-31 11:25:52] special[1] (west-nb of clue 255): 45 entries
[2026-10-31 11:25:52] special[2] (south-nb of clue 255): 44 entries
[2026-10-31 11:25:52] special[3] (cell of clue 249): 1 entries
[2026-10-31 11:25:52] special[4] (west-nb of clue 249): 2025 entries
[2026-10-31 11:25:52] special[5] (south-nb of clue 249): 2115 entries
[2026-10-31 11:25:52] special[6] (cell of clue 139): 1 entries
[2026-10-31 11:25:52] special[7] (west-nb of clue 139): 44 entries
[2026-10-31 11:25:52] special[8] (south-nb of clue 139): 45 entries
[2026-10-31 11:25:52] special[9] (cell of clue 208): 1 entries
[2026-10-31 11:25:52] special[10] (west-nb of clue 208): 45 entries
[2026-10-31 11:25:52] special[11] (south-nb of clue 208): 46 entries
[2026-10-31 11:25:52] special[12] (cell of clue 181): 1 entries
[2026-10-31 11:25:52] special[13] (west-nb of clue 181): 44 entries
[2026-10-31 11:25:52] special[14] (south-nb of clue 181): 45 entries
[2026-10-31 11:25:52] GPU: tables in left-major slice order: 3,7,11,17 (the others bottom-major)
[2026-10-31 11:25:52] GPU: table 6 (23 deep cells): 234 of 267 slices' no-break groups described
[2026-10-31 11:25:52] GPU: table 7 (41 deep cells): 234 of 493 slices' no-break groups described
bwgpu: frontier of 22 entries (6 groups)
bwgpu: offsets overlay of 4 words (room 228): depths 45 120 188; 98416 bytes of shared memory a block
bwgpu: break test off (no candidate of a scan's range can have too many breaks)
bwgpu: deep region from depth 192; not described (the other region's tables): 196
NVIDIA_BETA slots=640 resident=120320 free_bytes=99916709888 total_bytes=102641500160 per_slot=107788 shared_bytes=98416 single_wave=1
bwgpu: 524 coded slices (tables 0, 4, 6, 7,), 369 + 352 code bits a ticket
NVIDIA_RESOURCE_PROBE_OK resident=120320
NVIDIA_RESOURCE_SELECTED block=640 engine=e2_bw_nvidia_avx2_cuda12_0.4.exe
bw_runner: progress 3/65549 (0%), restored runtime 0 s
bw_runner: progress 7/65549 (0%), restored runtime 748 s
bw_runner: progress 36/65549 (0%), restored runtime 805 s
bw_runner: progress 49/65549 (0%), restored runtime 861 s
bw_runner: progress 512/65549 (0%), restored runtime 917 s
bw_runner: progress 8824/65549 (13%), restored runtime 969 s
bw_runner: progress 11178/65549 (17%), restored runtime 1025 s
bw_runner: progress 13075/65549 (19%), restored runtime 1080 s
bw_runner: progress 15192/65549 (23%), restored runtime 1139 s
bw_runner: progress 17935/65549 (27%), restored runtime 1199 s
bw_runner: progress 22112/65549 (33%), restored runtime 1258 s
bw_runner: progress 28909/65549 (44%), restored runtime 1312 s
bw_runner: progress 39123/65549 (59%), restored runtime 1371 s
bw_runner: progress 50297/65549 (76%), restored runtime 1423 s
bw_runner: progress 57958/65549 (88%), restored runtime 1483 s
bw_runner: progress 61818/65549 (94%), restored runtime 1541 s
bw_runner: progress 63294/65549 (96%), restored runtime 1592 s
bw_runner: progress 63874/65549 (97%), restored runtime 1637 s
bw_runner: progress 64103/65549 (97%), restored runtime 1696 s
bw_runner: progress 64227/65549 (97%), restored runtime 1755 s
bw_runner: progress 64280/65549 (98%), restored runtime 1813 s
bw_runner: progress 64321/65549 (98%), restored runtime 1873 s
bw_runner: progress 64359/65549 (98%), restored runtime 1928 s
bw_runner: progress 64522/65549 (98%), restored runtime 1976 s
bw_runner: progress 64568/65549 (98%), restored runtime 2014 s
bw_runner: progress 64583/65549 (98%), restored runtime 2052 s
bw_runner: progress 64590/65549 (98%), restored runtime 2112 s
bw_runner: progress 64595/65549 (98%), restored runtime 2164 s
bw_runner: progress 64606/65549 (98%), restored runtime 2219 s
bw_runner: progress 64610/65549 (98%), restored runtime 2258 s
bw_runner: progress 64619/65549 (98%), restored runtime 2299 s
bw_runner: progress 64626/65549 (98%), restored runtime 2332 s
bw_runner: progress 64636/65549 (98%), restored runtime 2368 s
bw_runner: progress 64642/65549 (98%), restored runtime 2406 s
bw_runner: progress 64648/65549 (98%), restored runtime 2460 s
bw_runner: progress 64651/65549 (98%), restored runtime 2500 s
bw_runner: progress 64654/65549 (98%), restored runtime 2538 s
bw_runner: progress 64655/65549 (98%), restored runtime 2621 s
bw_runner: warning: unable to publish durable progress
bw_runner: progress 64656/65549 (98%), restored runtime 2751 s
bw_runner: progress 64657/65549 (98%), restored runtime 2867 s
bw_runner: progress 64658/65549 (98%), restored runtime 3020 s
bw_runner: progress 64660/65549 (98%), restored runtime 3140 s
bw_runner: progress 64663/65549 (98%), restored runtime 3272 s
bw_runner: progress 64664/65549 (98%), restored runtime 3304 s
bw_runner: progress 64665/65549 (98%), restored runtime 3688 s
bw_runner: progress 64666/65549 (98%), restored runtime 3856 s
bw_runner: progress 64667/65549 (98%), restored runtime 4003 s
bw_runner: progress 64668/65549 (98%), restored runtime 4365 s
bw_runner: progress 64669/65549 (98%), restored runtime 4409 s
bw_runner: progress 64670/65549 (98%), restored runtime 4526 s
bw_runner: progress 64671/65549 (98%), restored runtime 4700 s
bw_runner: progress 64675/65549 (98%), restored runtime 6352 s
bw_runner: warning: unable to publish durable progress
bw_runner: progress 64677/65549 (98%), restored runtime 6407 s
bw_runner: warning: unable to publish durable progress
bw_runner: warning: unable to publish durable progress
bw_runner: warning: unable to publish durable progress
bw_runner: warning: unable to publish durable progress
bw_runner: progress 64678/65549 (98%), restored runtime 9940 s
bw_runner: progress 64679/65549 (98%), restored runtime 14144 s
</stderr_txt>
]]>Hope this helps. Michael. P.S.: Not sure what is going on, but that machine doesn't receive CPU tasks anymore since 02:25:40 (UTC) while my other machines (assigned to the same project venue) do still get tasks: 01.11.2026 02:25:40 | Eternity II | Reporting 1 completed tasks 01.11.2026 02:25:40 | Eternity II | Requesting new tasks for CPU 01.11.2026 02:25:42 | Eternity II | Scheduler request completed: got 0 new tasks 01.11.2026 02:25:42 | Eternity II | No tasks sent 01.11.2026 02:25:42 | Eternity II | Tasks for NVIDIA GPU are available, but your preferences are set to not accept them 01.11.2026 02:25:42 | Eternity II | Project requested delay of 61 seconds 01.11.2026 02:40:04 | Eternity II | Sending scheduler request: To fetch work. 01.11.2026 02:40:04 | Eternity II | Requesting new tasks for CPU 01.11.2026 02:40:06 | Eternity II | Scheduler request completed: got 0 new tasks Resetting the project does not change the situation and the server status shows enough work is available. 01.11.2026 14:18:45 | Eternity II | Resetting project 01.11.2026 14:18:50 | Eternity II | Master file download succeeded 01.11.2026 14:18:55 | Eternity II | Sending scheduler request: To fetch work. 01.11.2026 14:18:55 | Eternity II | Requesting new tasks for CPU 01.11.2026 14:18:56 | Eternity II | Scheduler request completed: got 0 new tasks 01.11.2026 14:18:56 | Eternity II | No tasks sent I will wait a little and see - maybe it recovers after a while... President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
In reply to Michael H.W. Weber's message of 1 Nov 2026: In reply to benjamin's message of 31 Oct 2026: Hi Michael, I understand, and I'm sorry for you and your team. I can't give you the earlier app back. It was a test version that we've closed, it runs about four times slower than the normal one, and I can't change this during the sprint. You can still get normal GPU tasks, though. Your log shows they're available, and they're only blocked by your preferences. A task of your size pays about 88,000 credits, and most finish in one to two hours. I can't promise yours will, because your last one didn't, so it's your choice. Your log really does help, thank you. The task reached 64,655 tickets out of 65,549 in about 44 minutes, then did only 24 more in over 3 hours. That's exactly the long ending you described. The task hadn't reached the point where it hands the rest over, so it stayed stuck on the GPU. About your CPU tasks: I checked, and that machine got 32 CPU tasks after your reset, starting at 13:21 UTC, so it's working again. I haven't found out why it got none before. If it happens again, please let me know. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
Interesting. I gave it another GPU try and this time that task completed in 34 minutes (PowerTarget is set to 80% using MSI Afterburner to save electricity). Here is the log: <core_client_version>7.24.1</core_client_version>
<![CDATA[
<stderr_txt>
2026-11-01 16:35:21 (5944): wrapper: running ../../projects/boinc.eternityathome.org_eternity/bw_runner_nvidia_common_0.17.exe (--force-interleave --shard-index 392 --shard-count 4096 --force-jitter-start 1748360320 --force-jitters 1749267584 --threads 4 --gpu-slots 0 --node-cap 2000000000 --seconds 0 --exact-endgame 244:50000000 --endgame-probe 4 --endgame-ladder 4:236:1000000000,3:230:6000000000,2:224:64000000000,1:216:80000000000 --ring-breaks 236 --sigma-tail --no-sigma-main --ncon2-direct 1 --mrv-dem-inc 1 --main-fast 1 --min-save 463 --breaks 192,197,201,206,211,216,221,225,229,233,237,241,246,250 --root-allow exploration_allow.txt --seed 6152026 --epoch cloudflare-boinc-explore --tourney tour --ticket-cpu-seconds 0 --runner-tail-fraction 0.005 --runner-idle-handoff 90 --runner-underfill-handoff 90)
2026-11-01 16:35:22 (5944): wrapper: created child process 15140
NVIDIA beta: assigned device 0, automatic single resident wave, current-free-memory budget
pipeline: selected scientific engine e2_bw_nvidia_avx2_cuda12_0.4.exe
bw_runner: progress 0/65564 (0%), restored runtime 0 s
NVIDIA_RESOURCE_ADMISSION block=640 exit=0
[2026-11-01 16:35:22] heuristic colors: {13,16,10}, total edges 122 (ramp scale x1.000)
[2026-11-01 16:35:22] clue mode: FULL-CLUES (5 hints) -> corner-first fill order, heurScale 0.970 (mode default)
[2026-11-01 16:35:22] breaks (14 total, target completion score 466): 192,197,201,206,211,216,221,225,229,233,237,241,246,250
[2026-11-01 16:35:22] P13 SHARD 392/4096 jitterStart=1748360320 : ce worker traite les tickets globaux J0*nroots + 392 + 4096*local (sous-ensemble disjoint)
[2026-11-01 16:35:22] bw starting: 1 threads, seed 6152026, nodeCap 2.0B, heurScale 0.970, minSave 463, resume best 0, seconds 0
[2026-11-01 16:35:22] clue: piece 255 td(2,2) rot 2 -> bu cell (13,2) fill idx 188
[2026-11-01 16:35:22] clue: piece 249 td(2,13) rot 3 -> bu cell (13,13) fill idx 247
[2026-11-01 16:35:22] clue: piece 139 td(8,8) rot 1 -> bu cell (7,8) fill idx 120
[2026-11-01 16:35:22] clue: piece 208 td(13,2) rot 2 -> bu cell (2,2) fill idx 8
[2026-11-01 16:35:22] clue: piece 181 td(13,13) rot 2 -> bu cell (2,13) fill idx 45
[2026-11-01 16:35:22] FORCE_ROOT chargé: 3084 racines, 1749267584 jitters/racine, 1 threads
[2026-11-01 16:35:22] ROOT_ALLOW : 74 cidx autorisés / 3084 racines (65564 lignes lues, 0 hors-bornes ignorées) -> les autres cidx sont sautés (ticket/seed d'origine préservés)
[2026-11-01 16:35:22] TICKET_LOG ARME run_id=172eec78c56c7b91 cfg_hash=cd89cfe0c072798a dir=startup_probe/640/ticketlog (segment immuable v2)
[2026-11-01 16:35:22] HARVEST463 dir=startup_probe/640/harvest (board vérifié score>=463, identité SHA256)
[2026-11-01 16:35:22] table sizes: corners 16 leftSides 56 bottomSides 56 topSides 1288 rightNoBrk 56 rightBrk 1288 midNoBrk 764 midBrk 34380
[2026-11-01 16:35:22] ring-break tables (from fill depth 236, 8 border cells): corners 720 leftSides 2520 bottomSides 2520 topSides 2520 rightBrk 2520
[2026-11-01 16:35:22] special[0] (cell of clue 255): 1 entries
[2026-11-01 16:35:22] special[1] (west-nb of clue 255): 45 entries
[2026-11-01 16:35:22] special[2] (south-nb of clue 255): 44 entries
[2026-11-01 16:35:22] special[3] (cell of clue 249): 1 entries
[2026-11-01 16:35:22] special[4] (west-nb of clue 249): 2025 entries
[2026-11-01 16:35:22] special[5] (south-nb of clue 249): 2115 entries
[2026-11-01 16:35:22] special[6] (cell of clue 139): 1 entries
[2026-11-01 16:35:22] special[7] (west-nb of clue 139): 44 entries
[2026-11-01 16:35:22] special[8] (south-nb of clue 139): 45 entries
[2026-11-01 16:35:22] special[9] (cell of clue 208): 1 entries
[2026-11-01 16:35:22] special[10] (west-nb of clue 208): 45 entries
[2026-11-01 16:35:22] special[11] (south-nb of clue 208): 46 entries
[2026-11-01 16:35:22] special[12] (cell of clue 181): 1 entries
[2026-11-01 16:35:22] special[13] (west-nb of clue 181): 44 entries
[2026-11-01 16:35:22] special[14] (south-nb of clue 181): 45 entries
[2026-11-01 16:35:22] GPU: tables in left-major slice order: 3,7,11,17 (the others bottom-major)
[2026-11-01 16:35:22] GPU: table 6 (23 deep cells): 234 of 267 slices' no-break groups described
[2026-11-01 16:35:22] GPU: table 7 (41 deep cells): 234 of 493 slices' no-break groups described
bwgpu: frontier of 22 entries (6 groups)
bwgpu: offsets overlay of 4 words (room 228): depths 45 120 188; 98416 bytes of shared memory a block
bwgpu: break test off (no candidate of a scan's range can have too many breaks)
bwgpu: deep region from depth 192; not described (the other region's tables): 196
NVIDIA_BETA slots=640 resident=120320 free_bytes=99916709888 total_bytes=102641500160 per_slot=107788 shared_bytes=98416 single_wave=1
bwgpu: 524 coded slices (tables 0, 4, 6, 7,), 369 + 352 code bits a ticket
NVIDIA_RESOURCE_PROBE_OK resident=120320
NVIDIA_RESOURCE_SELECTED block=640 engine=e2_bw_nvidia_avx2_cuda12_0.4.exe
bw_runner: progress 10/65564 (0%), restored runtime 0 s
bw_runner: progress 40/65564 (0%), restored runtime 810 s
bw_runner: progress 59/65564 (0%), restored runtime 862 s
bw_runner: progress 744/65564 (1%), restored runtime 920 s
bw_runner: progress 9539/65564 (14%), restored runtime 976 s
bw_runner: progress 11547/65564 (17%), restored runtime 1030 s
bw_runner: progress 13268/65564 (20%), restored runtime 1087 s
bw_runner: progress 15208/65564 (23%), restored runtime 1143 s
bw_runner: progress 17693/65564 (26%), restored runtime 1203 s
bw_runner: progress 21732/65564 (33%), restored runtime 1262 s
bw_runner: progress 28591/65564 (43%), restored runtime 1319 s
bw_runner: progress 39173/65564 (59%), restored runtime 1378 s
bw_runner: progress 50375/65564 (76%), restored runtime 1437 s
bw_runner: progress 58507/65564 (89%), restored runtime 1496 s
bw_runner: progress 62427/65564 (95%), restored runtime 1552 s
bw_runner: progress 64127/65564 (97%), restored runtime 1611 s
bw_runner: progress 64741/65564 (98%), restored runtime 1670 s
bw_runner: progress 65032/65564 (99%), restored runtime 1730 s
bw_runner: progress 65167/65564 (99%), restored runtime 1787 s
pipeline: handoff at 65238/65564, remaining limit 327
NVIDIA_HANDOFF stopped=1 win_error=0 wait=0
bw_runner: progress 65238/65564 (99%), restored runtime 1846 s
2026-11-01 17:08:16 (5944): bw_runner exited; CPU time 3236.765625
2026-11-01 17:08:16 (5944): called boinc_finish(0)
</stderr_txt>
]]>Credits are also better now with 87000 per this task. So, the interesting question is, why the previous WU did not complete - note that both employed the same client. Some non-deterministic feature present in that code? Or did I just cancel it too early? Maybe a fail-check could be implemented that the task aborts when encountering unusual messages or a long GPU idleing duration? The worst thing that can happen is a "zombied GPU" (at least in this case it did not continue to uselessly burn significant electricity)... Will try more GPU tasks... Michael. President of Rechenkraft.net e.V. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
Unfortunately, there is another example of mis-crediting with the GPU tasks. Just check out this task: https://boinc.eternityathome.org/eternity/workunit.php?wuid=4824644 runtime: 1,555.94 sec credits: 5,209.08 I also noticed that the project might have a scheduling problem with the GPU tasks: In my case there is a 30 min. delay between submmission of a completed task and the retrieval of the next one. My suspicion is that because the GPU tasks require two CPU cores, no GPU task is retrieved until two CPU cores are truely idle. Note that my machine picks up both, CPU and GPU tasks, so there are rarely two CPU cores idle simultaneously. Maybe there are some type of GPU-priority settings possible? Just an idea. Michael. President of Rechenkraft.net e.V. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
@Michael H.W. Weber: I'm glad it's working now: your card has completed four valid tasks in a row, in about 30 minutes each. Thanks for the logs, they answer several of your questions. Why did the earlier task stall? Did you cancel too early? You didn't cancel too early. The app is the same, but each task has different tickets, and there is also some variation: two runs of the same task don't stop at exactly the same ticket. Your good task reached the point where it hands over the rest, with 326 tickets left and a limit of 327. The stuck task still had about 870 left, and those were very slow, so it most likely never reached that point. Your idea of stopping a task when the GPU sits idle for too long is a good one, and it's on my list. The 5,209 credits I have to correct myself again, sorry. I told you GPU credit was fixed per task. It's actually paid per ticket, about 1.34 credits per ticket for every task size. This task had only 3,888 tickets, so 5,209 is what the current rule gives. But you're right that it isn't fair: it took 26 minutes, against 33 minutes for your 87,841-credit task, because a task needs about 13 minutes to get up to speed whatever its size. These small tasks are what's left at the end of a batch. I've added this to my list too. The 30-minute delay I can see it as well: about 30 minutes, three times in a row, while GPU tasks are in stock. Most other machines wait less, typically about 7 minutes. Our server logs don't show whether your client asked for GPU work during that time, so I can't confirm your idea yet. Another possibility is that the client pauses its GPU requests after a reply with no GPU task. I can't say yet whether a priority setting would help. If you have time, could you turn on work_fetch_debug in Options > Event Log Options in BOINC Manager, and post the lines from one of those gaps? That should show what the client is waiting for. |
|
Michael H.W. Weber New member Send message Joined: 30 Oct 26 Posts: 12 Credit: 3,406,392 RAC: 179,274
|
In reply to benjamin's message of 1 Nov 2026: If you have time, could you turn on work_fetch_debug in Options > Event Log Options in BOINC Manager... ...done. Michael. President of Rechenkraft.net e.V. |
|
Send message Joined: 28 Sep 26 Posts: 17 Credit: 15,948,746 RAC: 429,435 
|
Likely the same issue with stalled gpu task. Stderr.txt file was not updated for more than an hour already with little or no gpu activity but somehow cpu still show some activity. Seem to stuck at : 64651/65559 (98%), restored runtime 7706s. This task was aborted earlier by another volunteer and resent to me. I'll let it run for another hour and see what happens. P.S. I would suggest you put a timestamp next to the "bw_runner: progress", like what you have now during the task initialization phase. Edit: after an hour later, stderr.txt file has not been updated nor any progress was made on the "bw_runner" status. I'm the second volunteer to abort this task, handing over to the third volunteer, perhaps third time it will be lucky :) https://boinc.eternityathome.org/eternity/workunit.php?wuid=4632274 2026-11-02 14:25:42 (959423): wrapper (8.3.26019): starting
2026-11-02 14:25:42 (959423): wrapper: running ../../projects/boinc.eternityathome.org_eternity/bw_runner_nvidia_common_0.17_linux (--force-interleave --shard-index 385 --shard-count 4096 --force-jitter-start 1972820096 --force-jitters 1973365888 --threads 4 --gpu-slots 0 --node-cap 2000000000 --seconds 0 --exact-endgame 244:50000000 --endgame-probe 4 --endgame-ladder 4:236:1000000000,3:230:6000000000,2:224:64000000000,1:216:80000000000 --ring-breaks 236 --sigma-tail --no-sigma-main --ncon2-direct 1 --mrv-dem-inc 1 --main-fast 1 --min-save 463 --breaks 192,197,201,206,211,216,221,225,229,233,237,241,246,250 --root-allow exploration_allow.txt --seed 6152026 --epoch cloudflare-boinc-explore --tourney tour --ticket-cpu-seconds 0 --runner-tail-fraction 0.005 --runner-idle-handoff 90 --runner-underfill-handoff 90)
2026-11-02 14:25:42 (959423): wrapper: created child process 959425
NVIDIA beta: assigned device 0, automatic single resident wave, current-free-memory budget
pipeline: selected scientific engine e2_bw_nvidia_avx2_0.4
bw_runner: progress 0/65559 (0%), restored runtime 0 s
NVIDIA_RESOURCE_ADMISSION block=640 exit=0
NVIDIA_BETA_PRIORITY inherited_nice=19
[2026-11-02 14:25:42] heuristic colors: {13,16,10}, total edges 122 (ramp scale x1.000)
[2026-11-02 14:25:42] clue mode: FULL-CLUES (5 hints) -> corner-first fill order, heurScale 0.970 (mode default)
[2026-11-02 14:25:42] breaks (14 total, target completion score 466): 192,197,201,206,211,216,221,225,229,233,237,241,246,250
[2026-11-02 14:25:42] P13 SHARD 385/4096 jitterStart=1972820096 : ce worker traite les tickets globaux J0*nroots + 385 + 4096*local (sous-ensemble disjoint)
[2026-11-02 14:25:42] bw starting: 1 threads, seed 6152026, nodeCap 2.0B, heurScale 0.970, minSave 463, resume best 0, seconds 0
[2026-11-02 14:25:42] clue: piece 255 td(2,2) rot 2 -> bu cell (13,2) fill idx 188
[2026-11-02 14:25:42] clue: piece 249 td(2,13) rot 3 -> bu cell (13,13) fill idx 247
[2026-11-02 14:25:42] clue: piece 139 td(8,8) rot 1 -> bu cell (7,8) fill idx 120
[2026-11-02 14:25:42] clue: piece 208 td(13,2) rot 2 -> bu cell (2,2) fill idx 8
[2026-11-02 14:25:42] clue: piece 181 td(13,13) rot 2 -> bu cell (2,13) fill idx 45
[2026-11-02 14:25:42] FORCE_ROOT chargé: 3084 racines, 1973365888 jitters/racine, 1 threads
[2026-11-02 14:25:42] ROOT_ALLOW : 123 cidx autorisés / 3084 racines (65559 lignes lues, 0 hors-bornes ignorées) -> les autres cidx sont sautés (ticket/seed d'origine préservés)
[2026-11-02 14:25:42] TICKET_LOG ARME run_id=543072d6fe11e0cb cfg_hash=6737d24403767806 dir=startup_probe/640/ticketlog (segment immuable v2)
[2026-11-02 14:25:42] HARVEST463 dir=startup_probe/640/harvest (board vérifié score>=463, identité SHA256)
[2026-11-02 14:25:42] table sizes: corners 16 leftSides 56 bottomSides 56 topSides 1288 rightNoBrk 56 rightBrk 1288 midNoBrk 764 midBrk 34380
[2026-11-02 14:25:42] ring-break tables (from fill depth 236, 8 border cells): corners 720 leftSides 2520 bottomSides 2520 topSides 2520 rightBrk 2520
[2026-11-02 14:25:42] special[0] (cell of clue 255): 1 entries
[2026-11-02 14:25:42] special[1] (west-nb of clue 255): 45 entries
[2026-11-02 14:25:42] special[2] (south-nb of clue 255): 44 entries
[2026-11-02 14:25:42] special[3] (cell of clue 249): 1 entries
[2026-11-02 14:25:42] special[4] (west-nb of clue 249): 2025 entries
[2026-11-02 14:25:42] special[5] (south-nb of clue 249): 2115 entries
[2026-11-02 14:25:42] special[6] (cell of clue 139): 1 entries
[2026-11-02 14:25:42] special[7] (west-nb of clue 139): 44 entries
[2026-11-02 14:25:42] special[8] (south-nb of clue 139): 45 entries
[2026-11-02 14:25:42] special[9] (cell of clue 208): 1 entries
[2026-11-02 14:25:42] special[10] (west-nb of clue 208): 45 entries
[2026-11-02 14:25:42] special[11] (south-nb of clue 208): 46 entries
[2026-11-02 14:25:42] special[12] (cell of clue 181): 1 entries
[2026-11-02 14:25:42] special[13] (west-nb of clue 181): 44 entries
[2026-11-02 14:25:42] special[14] (south-nb of clue 181): 45 entries
[2026-11-02 14:25:42] GPU: tables in left-major slice order: 3,7,11,17 (the others bottom-major)
[2026-11-02 14:25:42] GPU: table 6 (23 deep cells): 234 of 267 slices' no-break groups described
[2026-11-02 14:25:42] GPU: table 7 (41 deep cells): 234 of 493 slices' no-break groups described
bwgpu: frontier of 22 entries (6 groups)
bwgpu: offsets overlay of 4 words (room 228): depths 45 120 188; 98416 bytes of shared memory a block
bwgpu: break test off (no candidate of a scan's range can have too many breaks)
bwgpu: deep region from depth 192; not described (the other region's tables): 196
NVIDIA_BETA slots=640 resident=30720 free_bytes=11890982912 total_bytes=12344164352 per_slot=107788 shared_bytes=98416 single_wave=1
bwgpu: 524 coded slices (tables 0, 4, 6, 7,), 369 + 352 code bits a ticket
NVIDIA_RESOURCE_PROBE_OK resident=30720
NVIDIA_RESOURCE_SELECTED block=640 engine=e2_bw_nvidia_avx2_0.4
bw_runner: progress 6/65559 (0%), restored runtime 0 s
bw_runner: progress 3057/65559 (4%), restored runtime 972 s
bw_runner: progress 5288/65559 (8%), restored runtime 1033 s
bw_runner: progress 6123/65559 (9%), restored runtime 1094 s
bw_runner: progress 6946/65559 (10%), restored runtime 1154 s
bw_runner: progress 7996/65559 (12%), restored runtime 1215 s
bw_runner: progress 9302/65559 (14%), restored runtime 1276 s
bw_runner: progress 11342/65559 (17%), restored runtime 1336 s
bw_runner: progress 14374/65559 (21%), restored runtime 1397 s
bw_runner: progress 18402/65559 (28%), restored runtime 1458 s
bw_runner: progress 22697/65559 (34%), restored runtime 1519 s
bw_runner: progress 26158/65559 (39%), restored runtime 1579 s
bw_runner: progress 28158/65559 (42%), restored runtime 1640 s
bw_runner: progress 29189/65559 (44%), restored runtime 1701 s
bw_runner: progress 29725/65559 (45%), restored runtime 1761 s
bw_runner: progress 30000/65559 (45%), restored runtime 1822 s
bw_runner: progress 30145/65559 (45%), restored runtime 1883 s
bw_runner: progress 30253/65559 (46%), restored runtime 1943 s
bw_runner: progress 30377/65559 (46%), restored runtime 2004 s
bw_runner: progress 30930/65559 (47%), restored runtime 2065 s
bw_runner: progress 31304/65559 (47%), restored runtime 2126 s
bw_runner: progress 31620/65559 (48%), restored runtime 2186 s
bw_runner: progress 31958/65559 (48%), restored runtime 2247 s
bw_runner: progress 32416/65559 (49%), restored runtime 2308 s
bw_runner: progress 33054/65559 (50%), restored runtime 2368 s
bw_runner: progress 34059/65559 (51%), restored runtime 2429 s
bw_runner: progress 35425/65559 (54%), restored runtime 2490 s
bw_runner: progress 37224/65559 (56%), restored runtime 2550 s
bw_runner: progress 39114/65559 (59%), restored runtime 2611 s
bw_runner: progress 40934/65559 (62%), restored runtime 2672 s
bw_runner: progress 42663/65559 (65%), restored runtime 2732 s
bw_runner: progress 44402/65559 (67%), restored runtime 2793 s
bw_runner: progress 46452/65559 (70%), restored runtime 2854 s
bw_runner: progress 48823/65559 (74%), restored runtime 2915 s
bw_runner: progress 51567/65559 (78%), restored runtime 2975 s
bw_runner: progress 54293/65559 (82%), restored runtime 3036 s
bw_runner: progress 56738/65559 (86%), restored runtime 3097 s
bw_runner: progress 58439/65559 (89%), restored runtime 3158 s
bw_runner: progress 59510/65559 (90%), restored runtime 3218 s
bw_runner: progress 60254/65559 (91%), restored runtime 3279 s
bw_runner: progress 60952/65559 (92%), restored runtime 3340 s
bw_runner: progress 61503/65559 (93%), restored runtime 3400 s
bw_runner: progress 62073/65559 (94%), restored runtime 3461 s
bw_runner: progress 62679/65559 (95%), restored runtime 3522 s
bw_runner: progress 63409/65559 (96%), restored runtime 3582 s
bw_runner: progress 64081/65559 (97%), restored runtime 3643 s
bw_runner: progress 64461/65559 (98%), restored runtime 3703 s
bw_runner: progress 64559/65559 (98%), restored runtime 3764 s
bw_runner: progress 64587/65559 (98%), restored runtime 3825 s
bw_runner: progress 64601/65559 (98%), restored runtime 3886 s
bw_runner: progress 64610/65559 (98%), restored runtime 3946 s
bw_runner: progress 64616/65559 (98%), restored runtime 4007 s
bw_runner: progress 64622/65559 (98%), restored runtime 4068 s
bw_runner: progress 64625/65559 (98%), restored runtime 4128 s
bw_runner: progress 64626/65559 (98%), restored runtime 4189 s
bw_runner: progress 64627/65559 (98%), restored runtime 4250 s
bw_runner: progress 64629/65559 (98%), restored runtime 4310 s
bw_runner: progress 64630/65559 (98%), restored runtime 4371 s
bw_runner: progress 64631/65559 (98%), restored runtime 4492 s
bw_runner: progress 64633/65559 (98%), restored runtime 4553 s
bw_runner: progress 64635/65559 (98%), restored runtime 4614 s
bw_runner: progress 64636/65559 (98%), restored runtime 4674 s
bw_runner: progress 64637/65559 (98%), restored runtime 4735 s
bw_runner: progress 64638/65559 (98%), restored runtime 4795 s
bw_runner: progress 64639/65559 (98%), restored runtime 4856 s
bw_runner: progress 64640/65559 (98%), restored runtime 5099 s
bw_runner: progress 64641/65559 (98%), restored runtime 5160 s
bw_runner: progress 64642/65559 (98%), restored runtime 5402 s
bw_runner: progress 64643/65559 (98%), restored runtime 5826 s
bw_runner: progress 64644/65559 (98%), restored runtime 6069 s
bw_runner: progress 64645/65559 (98%), restored runtime 6129 s
bw_runner: progress 64646/65559 (98%), restored runtime 6190 s
bw_runner: progress 64647/65559 (98%), restored runtime 6251 s
bw_runner: progress 64648/65559 (98%), restored runtime 6736 s
bw_runner: progress 64649/65559 (98%), restored runtime 6978 s
bw_runner: progress 64650/65559 (98%), restored runtime 7282 s
bw_runner: progress 64651/65559 (98%), restored runtime 7706 s |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
In reply to pututu's message of 3 Nov 2026: Likely the same issue with stalled gpu task. Stderr.txt file was not updated for more than an hour already with little or no gpu activity but somehow cpu still show some activity. Seem to stuck at : 64651/65559 (98%), restored runtime 7706s. This task was aborted earlier by another volunteer and resent to me. I'll let it run for another hour and see what happens. @pututu: thanks for giving it another hour and for the detailed log, it helped a lot. And you were right about luck: a later volunteer finished this exact task in 75 minutes. Comparing the two logs showed us the real cause. Near the end of a task, the GPU app is supposed to hand the last hard tickets over to CPU tasks and finish. That exit only opens when less than 1% of the tickets are left. On your run, 908 tickets were left (about 1.4%), so it never opened and the task kept grinding. On the successful run, 482 were left: the exit opened and it finished normally. So the problem isn't the tickets themselves, it's that threshold, and fixing it is one of the things I'll try to do this week. Good idea about the timestamps on the progress lines, it's noted. |
|
Send message Joined: 23 Sep 26 Posts: 228 Credit: 44,185,220 RAC: 1,478,559 |
Update on the issues reported in this thread during the marathon @Freewill: about two tasks per card: it's now officially fine. We measured the same failure rate with two tasks per card as with one, and the limit is now 8 GPU tasks per card, so you can run two and keep a buffer. Details in News. @Michael H.W. Weber: three answers. • The ~30 minutes between two GPU tasks: it wasn't the two CPU cores (the BOINC client starts GPU tasks first). It was our limit of 2 GPU tasks per card: a finished task still counts as "in progress" until it is reported, so the server refused to send the next one, and your client then waited longer and longer before asking again. With 8 tasks per card, your client can now keep the next task ready. • The 12 hours without CPU tasks on 1 Nov: same server problem as the "doesn't support computers of type" message (thread 55). Your host was put on a 24-hour delay by mistake, which is why resetting the project helped. Fixed on 1 Nov at 14:12 UTC, no new case since. • Credit: I wrote earlier that GPU credit is fixed per task. That was wrong, sorry: it is paid per ticket (about 1.34 credit per ticket), so a 65,536-ticket task pays about 88,000 whatever its duration. Your test-version task paid 1,200 was corrected to 88,000 on 1 Nov, and the other test-version results got the same correction today. • The GPU looking idle on your big card: we found a big part of it. The GPU app runs as many tickets at once as the card has compute units × 640. Your RTX PRO 6000 can run far more than a 65,536-ticket task contains, so part of the card had nothing to do. The RTX 4090/5090 now get bigger tasks (see News), and the RTX PRO 6000 is next on that list. • Tasks stuck near 98%: see below. @pututu, @Werinbert and @Michael H.W. Weber: tasks stuck near 98%: the last ~1.5% of tickets sat just above the point where the task hands the rest back to CPU tasks, so the card kept grinding on a handful of very slow tickets. Since today, version 2.81 of the GPU application is rolling out for these tasks. It hands back earlier, and it stops waiting when progress stalls: if progress almost stops for 15 minutes, or if the final part takes more than an hour, the remaining tickets go to CPU tasks and the GPU task ends normally. All 2.81 results so far are valid. It replaces 2.72 as the old queue empties, in about a day. pututu's idea of a timestamp on each "bw_runner: progress" line is not in this version yet; it's noted for the next one. @BorgProcessor: as promised, the Tesla V100 is in the list of accepted cards. |
dskagcommunity Send message Joined: 28 Sep 26 Posts: 30 Credit: 7,166,208 RAC: 383,761
|
In reply to benjamin's message of 5 Nov 2026: Update on the issues reported in this thread during the marathon hmm i have such a task now with 15 hours runtim on 98,xx% stucks since a minimum of 1 hours (im just awake since then so dont know how long it really idles there at the moment) on a 5070ti. So im not that good in english (text above) i dont know if i have to let it run for...10? hours more or so? Have gpugrid units waiting for its turn on GPU. ---------- 24/7 Crunching since 2011 ----------- DSKAG Austria: http://www.dskag.at 
|
