Message boards : News : Project restarted
Author | Message |
---|---|
Sorry for the downtime. | |
ID: 56118 | Rating: 0 | rate: / Reply Quote | |
ID: 56125 | Rating: 0 | rate: / Reply Quote | |
What happened? Sorry for the downtime. | |
ID: 56128 | Rating: 0 | rate: / Reply Quote | |
Outta disk space. | |
ID: 56129 | Rating: 0 | rate: / Reply Quote | |
Thanks Toni for dealing with this in busy time before Christmas. | |
ID: 56130 | Rating: 0 | rate: / Reply Quote | |
Many Thanks Toni for keeping this project under control. Merry Christmas! | |
ID: 56135 | Rating: 0 | rate: / Reply Quote | |
when will GPUGrid support G-Force 3000? | |
ID: 56136 | Rating: 0 | rate: / Reply Quote | |
when will GPUGrid support G-Force 3000? +1 :) ____________ | |
ID: 56139 | Rating: 0 | rate: / Reply Quote | |
Hello, Is there already a possibility to use RTX 3000 under Windows 10 (Boinc 7.16.11)? | |
ID: 56167 | Rating: 0 | rate: / Reply Quote | |
Hello, Is there already a possibility to use RTX 3000 under Windows 10 (Boinc 7.16.11)? Not yet. Keep an eye on the News forum for any updates. There will be numerous posts on this subject when it happens. From past experience it takes 6 months, or more. But we can always hope it will be sooner. | |
ID: 56168 | Rating: 0 | rate: / Reply Quote | |
Why is it taking so long to complete support for the 3000s? | |
ID: 56224 | Rating: 0 | rate: / Reply Quote | |
No one will use old Graphics cards If you check this post, GTX 10xx cards are the most common GPU http://www.gpugrid.net/forum_thread.php?id=5194&nowrap=true#55687 | |
ID: 56225 | Rating: 0 | rate: / Reply Quote | |
Why is it taking so long to complete support for the 3000s? Who knows!? Low priority I assume from the developers standpoint. I would think that only a very small code change where the CC capability of the card is probed would be needed. Just open up the variable limits to include up to CC8.5 and CC8.6 for the Ampere cards. I think that is all they did to get the Turing cards compatible with the app. | |
ID: 56226 | Rating: 0 | rate: / Reply Quote | |
With the current round of work units wrapping up in a matter of hours, it probably is easier to let them finish before updating the app. | |
ID: 56227 | Rating: 0 | rate: / Reply Quote | |
You might be onto something. Could be a great stopping point to update the app with no more current work being distributed. | |
ID: 56228 | Rating: 0 | rate: / Reply Quote | |
You might be onto something. Could be a great stopping point to update the app with no more current work being distributed. We can only hope. ____________ | |
ID: 56230 | Rating: 0 | rate: / Reply Quote | |
You might be onto something. Could be a great stopping point to update the app with no more current work being distributed. We can only hope. I would imagine any Ampere support would hit the beta apps first, and I’m honestly surprised they haven’t tried adding Ampere support there in the recent rounds of beta tasks. ____________ | |
ID: 56231 | Rating: 0 | rate: / Reply Quote | |
I'm confused. Is GPUGRID officially back up and running since Dec 22/2020? | |
ID: 56242 | Rating: 0 | rate: / Reply Quote | |
I'm confused. Is GPUGRID officially back up and running since Dec 22/2020? They fixed problem they had before. But now they are out of work units. http://www.gpugrid.net/server_status.php | |
ID: 56243 | Rating: 0 | rate: / Reply Quote | |
Thanks for the update. Now I understand. | |
ID: 56244 | Rating: 0 | rate: / Reply Quote | |
Does anyone know when the new work units will be available? | |
ID: 56247 | Rating: 0 | rate: / Reply Quote | |
Does anyone know when the new work units will be available? 169 WUs in progress at this time, and decreasing. If "0 WUs in progress" is a must condition for this, it is about to happen... | |
ID: 56248 | Rating: 0 | rate: / Reply Quote | |
Cheers for reply. Seems like those units are in progress forever. | |
ID: 56249 | Rating: 0 | rate: / Reply Quote | |
Cheers for reply. Seems like those units are in progress forever. it's inevitable with BOINC projects since some users download the tasks, then shut their system off, or have some system problem preventing timely work completion. GPUGRID is better than most in this regard with the short 5-day deadlines. so it gets re-sent rather quickly. ____________ | |
ID: 56250 | Rating: 0 | rate: / Reply Quote | |
Toni: When can we expect a new flow of work? | |
ID: 56263 | Rating: 0 | rate: / Reply Quote | |
I second the question of when will new tasks become available. | |
ID: 56275 | Rating: 0 | rate: / Reply Quote | |
Me three | |
ID: 56276 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? | |
ID: 56281 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? Nothing... Maybe Toni stuck in the snow ? | |
ID: 56289 | Rating: 0 | rate: / Reply Quote | |
No contact with Tony for 25 days! Hope he has not been struck by Covid! | |
ID: 56290 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? Hi all, Winter Break occurs around the first of the year for most colleges. This batch likely ran out just as the break was starting. The next batch would probably be delayed by that. - Hopefully we'll get a notice if this project is in the computation completed stage and no more batches are to come. In that case we will have to wait for the next project, which could be a 'good while'. Meanwhile, give GPUGRID a much higher priority than your backup projects. That way when more work is available your boinc manager will automatically download and start GPUGRID tasks, pausing the backup projects. | |
ID: 56292 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? You should be able to hurry up the next project - by donating enough that they will reach the estimated 50,000 euros necessary to hire and support an intern for one year. | |
ID: 56294 | Rating: 0 | rate: / Reply Quote | |
You should be able to hurry up the next project - by donating enough that they will reach the estimated 50,000 euros necessary to hire and support an intern for one year. Or, I can crunch for Folding@home, which is monetarily supported both technically and informationally by its host institution, and donate to the Covid Moonshot project so that third world nations will have access to a cure. Please watch==> https://www.youtube.com/watch?v=VnyaAmM1nhE I'd gladly donate, but it's a tough decision when You're on a pension similar to what an intern earns. | |
ID: 56295 | Rating: 0 | rate: / Reply Quote | |
Hi, | |
ID: 56296 | Rating: 0 | rate: / Reply Quote | |
On any BOINC project: check the server status page. | |
ID: 56297 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? Worse, stuck in grant writing... :( Sorry, I will attend later when I can. | |
ID: 56305 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? Any chance to have a CUDA 11.1/11.2 app compiled for Ampere support before we come back? ____________ | |
ID: 56306 | Rating: 0 | rate: / Reply Quote | |
No new work since Jan 2, 2021. What is going on? Your machine is hungry. It's calling out to us that it is starving. | |
ID: 56307 | Rating: 0 | rate: / Reply Quote | |
I just saw some WUs popping up. Does that mean the project is slowly starting new work generation again? | |
ID: 56308 | Rating: 0 | rate: / Reply Quote | |
I see 10 tasks in progress now. Hmmmm | |
ID: 56311 | Rating: 0 | rate: / Reply Quote | |
Well we are getting almost no work units these days and I can't tell if the WU's coming out are new or recycled from prior users after a timeout or WU error. | |
ID: 56367 | Rating: 0 | rate: / Reply Quote | |
+ 1 | |
ID: 56368 | Rating: 0 | rate: / Reply Quote | |
Well we are getting almost no work units these days and I can't tell if the WU's coming out are new or recycled from prior users after a timeout or WU error. +2 | |
ID: 56369 | Rating: 0 | rate: / Reply Quote | |
One wonders if the project has in fact been restarted or is going thru a period of hibernation. | |
ID: 56370 | Rating: 0 | rate: / Reply Quote | |
One wonders if the project has in fact been restarted or is going thru a period of hibernation. +1 ____________ | |
ID: 56371 | Rating: 0 | rate: / Reply Quote | |
One wonders if the project has in fact been restarted or is going thru a period of hibernation. The last I read, the project staff was putting most of their time into seeking a grant to pay for the next thing they will do. Whoever provides that grant will probably have a large influence on what that next thing is. | |
ID: 56372 | Rating: 0 | rate: / Reply Quote | |
I just got two new WU's for my two PC's but they seem to be huge! 5.000.000 GFLOPS, holy cow! It will take a while to get those babies done! After 1h they are at 3%! | |
ID: 56391 | Rating: 0 | rate: / Reply Quote | |
This is to thank once more all the efforts involved in bringing new tasks available for us, voracious crunchers. | |
ID: 56395 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 # Looking for node-locked license in [/opt/acellera/license.dat] # Looking for node-locked license in [/opt/acellera/.acellera/license.dat] # Looking for node-locked license in [/opt/acellera/.htmd/license.dat] # Looking for node-locked license in [/root/license.dat] # Looking for node-locked license in [/root/.acellera/license.dat] # Looking for node-locked license in [/root/.htmd/license.dat] # # ACEMD is running with a basic licence! # Contact Acellera ([email protected]) for licencing. # # WARNING: ACEMD is limited to run on the GPU device 0 only! Anyone has any suggestions? This is the first time I'm trying to crunch tasks for GPUGrid, so I'm not sure if the problem is with these new WUs or if it's my setup. | |
ID: 56399 | Rating: 0 | rate: / Reply Quote | |
2,666% after 09:29 and deadliine 15/02... | |
ID: 56400 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 All of the failed tasks in your host stats seem to indicate a problem with your drivers. It’s throwing CUDA errors. Try re-installing them. ____________ | |
ID: 56401 | Rating: 0 | rate: / Reply Quote | |
2,666% after 09:29 and deadliine 15/02... At that rate, you’ll take over 14 days to complete the task. Deadlines are 5 days. I think your GTX 650 is just too slow for these tasks. ____________ | |
ID: 56402 | Rating: 0 | rate: / Reply Quote | |
2,666% after 09:29 and deadliine 15/02... I agree. These new ADRIA tasks are highly performance-demanding. Every graphics cards below an (overclocked) GTX 750 TI GPU working 24/7, are for sure missing the 120 hours deadline. | |
ID: 56403 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 All your failed work units have failed on all other Hosts who tried the same work unit. You have been unlucky in receiving a bad batch. Keep trying, you may receive a valid Work Unit | |
ID: 56404 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 At this point it seems to me that there is a bug in the app itself. Are there any Linux/NVIDIA hosts which manage to run these ADRIA tasks successfully? | |
ID: 56406 | Rating: 0 | rate: / Reply Quote | |
At this point it seems to me that there is a bug in the app itself. Are there any Linux/NVIDIA hosts which manage to run these ADRIA tasks successfully? My host 132158 has two in progress at the moment. Linux Mint 20.1 (Ubuntu derivative), dual GTX 1660 SUPER, driver 460.32 Approaching 40% after 11 hours. Look to be running normally so far, but I'll keep an eye on them. | |
ID: 56407 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 Check my host or many other linux hosts on the leaderboard. I’ve submitted many valid results. There’s no bug in the app ____________ | |
ID: 56410 | Rating: 0 | rate: / Reply Quote | |
All WUs that I receive now are failing, I don't see any errors but I don't really know where to look. I'm running Debian 10 on a machine with Optimus, so my NVIDIA GPU has device id 1 (at id 0 I have an intel graphics card). My NVIDIA driver is version 460.39 Perhaps there's no bug in the app now, but there was when the programagor originally posted about it. This bug was that the app had a "basic" licence, thus it could run only on GPU device 0, while programagor has his/her NVidia GPU on device ID 1. | |
ID: 56411 | Rating: 0 | rate: / Reply Quote | |
you missed that he was trying to run the executable directly (outside of BOINC), which is likely why he received that error message, it’s running in basic license “mode” because it can’t find the license files listed above. He probably didn’t move them correctly to be able to run the tasks in the same way that BOINC does. All of my machines have devices on dev 1+, and even one in the same situation with an unusable card at dev0 (which has been excluded) and only runs on the card on dev1 | |
ID: 56413 | Rating: 0 | rate: / Reply Quote | |
# WARNING: ACEMD is limited to run on the GPU device 0 only! The warning was shown "When I run the acemd3 binary directly". Most BOINC GPU apps will have a default setting to use device 0 when no BOINC control file is available to specify something different. I'm seeing tasks running happily on device 1, when that is specified in init_data.xml | |
ID: 56414 | Rating: 0 | rate: / Reply Quote | |
you missed that he was trying to run the executable directly (outside of BOINC), which is likely why he received that error message. All of my machines have devices on dev 1+, and even one in the same situation with an unusable card at dev0 (which has been excluded) and only runs on the card on dev1 You're right I really missed that, but then this is the reason for that strange licensing error. It is not a good idea to run the GPUGrid app directly, as it needs a wrapper. Perhaps the wrapper contains the appropiate license, or it tells the app where to look for it. We don't know how, so we can't use this method to debug this error. Perhaps he installed the BOINC manager as a service? | |
ID: 56415 | Rating: 0 | rate: / Reply Quote | |
Perhaps he installed the BOINC manager as a service? The Manager always runs in user space, but the client can run as a service. My Linux machines do run as a service, without GPU problems. Windows machines can't run GPU apps on a service install, because of Microsoft driver security protocols. Edit: programagor's Debian install on host 576641 looks OK from the outside. I'd suspect a driver problem - something like using a nouveau driver without the extra CUDA (computation) libraries provided through a manufacturer driver install. | |
ID: 56416 | Rating: 0 | rate: / Reply Quote | |
Edit: programagor's Debian install on host 576641 looks OK from the outside. I'd suspect a driver problem - something like using a nouveau driver without the extra CUDA (computation) libraries provided through a manufacturer driver install.I've installed a fresh Ubuntu 18.04 two days ago, and it has downloaded the 460.32 driver on its own, which works with FAH and GPUGrid also. I've upgraded it to 20.04 today. EDIT: the 460.39 driver on his host should be from ppa:graphics-drivers/ppa. (It works on my other host) | |
ID: 56417 | Rating: 0 | rate: / Reply Quote | |
The new Linux Mint (v20.1) offers me a driver manager: | |
ID: 56419 | Rating: 0 | rate: / Reply Quote | |
When I ran the binary directly, I tried supplying the `--device 1` parameter, but to no avail; due to the basic license the binary always uses device id 0. Also, I don't see the `license.dat[.*]` anywhere on my system. And my drivers are straight from nvidia, no nouveau. I can compile and run CUDA programs/kernels without any issue. For completeness sake, I reinstalled my drivers, but the issue persists. wrapper: running acemd3 (--boinc input --device 0) | |
ID: 56432 | Rating: 0 | rate: / Reply Quote | |
7.333% after 24 hours. | |
ID: 56433 | Rating: 0 | rate: / Reply Quote | |
When I ran the binary directly, I tried supplying the `--device 1` parameter, but to no avail; due to the basic license the binary always uses device id 0. Also, I don't see the `license.dat[.*]` anywhere on my system. And my drivers are straight from nvidia, no nouveau. I can compile and run CUDA programs/kernels without any issue. For completeness sake, I reinstalled my drivers, but the issue persists. look in your BOINC event log at startup. Is your nvidia GPU device id 0? when you see "device [id]" in boinc, it's always the BOINC order, not the system order, which can vary due to the way BOINC decides what is the best device. ____________ | |
ID: 56435 | Rating: 0 | rate: / Reply Quote | |
7.333% after 24 hours. These WUs are too large for many GPUs to complete in the 5 day (120 hour) window before they expire. It would be best to abort them on hosts which cannot meet the deadline as running them would be time and electricity wasted. Same goes for having a spare WU waiting in your cue if your GPU takes 60 or more hours to complete one. The spare will expire before completion, yielding no credit. I recommend a longer period of time before these "extra-long runs" expire. I think it will get them back quicker in the long run. | |
ID: 56438 | Rating: 0 | rate: / Reply Quote | |
look in your BOINC event log at startup. Is your nvidia GPU device id 0? when you see "device [id]" in boinc, it's always the BOINC order, not the system order, which can vary due to the way BOINC decides what is the best device. Right, my apologies, boinc has my GPU at id 0 CUDA: NVIDIA GPU 0: GeForce GTX 1060 (driver version 460.39, CUDA version 11.2, compute capability 6.1, 4096MB, 3974MB available, 4276 GFLOPS peak) OpenCL: NVIDIA GPU 0: GeForce GTX 1060 (driver version 460.39, device version OpenCL 1.2 CUDA, 6078MB, 3974MB available, 4276 GFLOPS peak) So licensing is likely not the culprit in my case. | |
ID: 56439 | Rating: 0 | rate: / Reply Quote | |
The app has not changed. | |
ID: 56443 | Rating: 0 | rate: / Reply Quote | |
I have aborted this WU, new one much more faster. | |
ID: 56461 | Rating: 0 | rate: / Reply Quote | |
I have aborted this WU, new one much more faster. wait until it runs for a few hours. you will see that the initial percentage increase is not accurate, it is only an estimation from BOINC until it hits a real checkpoint. you'll see the % increase fast until it hits the checkpoint, then it will reset to 0.333 or 0.666% and will go very slow from that point. ____________ | |
ID: 56462 | Rating: 0 | rate: / Reply Quote | |
I have aborted this WU, new one much more faster. And... (sorry to butt in) Once you get to a checkpoint, highlight the task in the task window and click on the properties button. Check the progress rate near the bottom of the list. If it is less than 0.9% per hour the GPU is too slow to make the 120 hour window, even crunching 24/7. Best to send it on to someone else before it expires. | |
ID: 56465 | Rating: 0 | rate: / Reply Quote | |
Toni: | |
ID: 56466 | Rating: 0 | rate: / Reply Quote | |
Toni: I have a discrete GTX 1060 on my laptop, but after 2 days of crunching a single task BOINC is still showing estimates of 8 more days... I'm crunching 24x7, and GPU's temperature is >90C, so the card has to be throttled. Are all new tasks that big? If that's the case, not only will i not be able to finish tasks in 24 hours to get some bonus, but also i won't be able to complete them in the allocated timeframe. | |
ID: 56467 | Rating: 0 | rate: / Reply Quote | |
These are the largest (longest) tasks in the history of the project I believe. | |
ID: 56468 | Rating: 0 | rate: / Reply Quote | |
I agree that so long-running tasks should have their deadlines increased. Otherwise, we gradually go back to super-computers that no one can afford. And the purpose of crowd-computing is that many can participate. | |
ID: 56470 | Rating: 0 | rate: / Reply Quote | |
a normal full 1060 should be capable to process these tasks in 5 days. must be because it's a laptop version. | |
ID: 56471 | Rating: 0 | rate: / Reply Quote | |
My 1050ti in my laptop can finish a task in 66 hours. Must be something wrong. | |
ID: 56472 | Rating: 0 | rate: / Reply Quote | |
My GTX 1060 finished one work unit in 38 hours. | |
ID: 56473 | Rating: 0 | rate: / Reply Quote | |
But another GTX 1070 failed twice.The error message: ACEMD failed:
Error initializing CUDA: CUDA_ERROR_NO_DEVICE (100) at /opt/conda/conda-bld/openmm_1589507810497/work/platforms/cuda/src/CudaContext.cpp:148 looks to me like it was due to a driver update, or some other intervention made your CUDA device inaccessible. | |
ID: 56474 | Rating: 0 | rate: / Reply Quote | |
I aborted the jobs for my GT 730 as there was no way they were going to finish them in time. And I suspended that computer from taking work. My GTX 1660 seems to take about a day and a half to finish the jobs. | |
ID: 56475 | Rating: 0 | rate: / Reply Quote | |
Same here with a small GT 710. But the PC always runs 24/7 an did a few WUs per week. It would be a pity if I could not continue to use this card :/ | |
ID: 56476 | Rating: 0 | rate: / Reply Quote | |
I think my GT 730 took about 22hours per WU. I think the current ones would have taken about 10 days. | |
ID: 56477 | Rating: 0 | rate: / Reply Quote | |
Work units got stuck at 14% and were canceled after 10 hours of running overnight | |
ID: 56479 | Rating: 0 | rate: / Reply Quote | |
I doubt it was stuck. These tasks take a LONG time to run. | |
ID: 56480 | Rating: 0 | rate: / Reply Quote | |
Took me 245,275 seconds on a GTX 1050 Ti - that's a smidge under 3 days. Since these tasks update their progress 150 times over a full run, that's 1,635 seconds between updates - almost half an hour. | |
ID: 56481 | Rating: 0 | rate: / Reply Quote | |
They are all on Ubuntu 18.04/20.04.The error message: That is probably it. I think I was updating to the 460 driver (CUDA 11.2), but I don't know why the second one failed right away. Maybe the driver was not initialized yet after the reboot? | |
ID: 56482 | Rating: 0 | rate: / Reply Quote | |
Is there a way to configure BOINC to start downloading a second task only when the first one is finishing? I got 2 tasks, each 5M GFLOPS, with the same deadline. Obviously, the second wouldn't be computed on time, so I had to abort it (it was in READY status, so hopefully it will come to someone else). Or, if that's not possible, can I limit BOINC to 1 task only? Less preferrable, as time will be spent on comms and downloads, but better than expiring tasks someone else could've processed... | |
ID: 56483 | Rating: 0 | rate: / Reply Quote | |
Or, if that's not possible, can I limit BOINC to 1 task only? Less preferrable, as time will be spent on comms and downloads, but better than expiring tasks someone else could've processed... I think the problem will be solved after BOINC processes the first one and gets better time estimates. It should not then download the second one. But that begs the question of why don't they either give them better estimates to begin with, or limit them to one? They limited the earlier ones to two anyway. | |
ID: 56484 | Rating: 0 | rate: / Reply Quote | |
Is there a way to configure BOINC to start downloading a second task only when the first one is finishing?You should set your work cache to 1 day, or less. The smallest value is 0.01 days (14 minutes and 24 seconds), this is the unit for this setting. However it will take a couple of workunits to make the processing time estimate accurate. | |
ID: 56485 | Rating: 0 | rate: / Reply Quote | |
You can set the work cache to exactly zero, if you like. In that case, BOINC will nominally initiate the request for work three minutes before the final task is estimated to finish. I say 'nominally', because BOINC only performs the 'work needed?' check once per minute, so the actual request may happen any time between three minutes and two minutes before the new task is needed. | |
ID: 56486 | Rating: 0 | rate: / Reply Quote | |
You can set the work cache to exactly zero, if you like. In that case, BOINC will nominally initiate the request for work three minutes before the final task is estimated to finish. Now that you mention it, won't setting the resource share to zero accomplish the same thing? That is how I often set it anyway. | |
ID: 56487 | Rating: 0 | rate: / Reply Quote | |
Yup, that's exactly the same. Setting it through BOINC Manager activates it immediately, going via resource share means a visit to the website and a project update. | |
ID: 56489 | Rating: 0 | rate: / Reply Quote | |
Or, if that's not possible, can I limit BOINC to 1 task only? Less preferrable, as time will be spent on comms and downloads, but better than expiring tasks someone else could've processed... One reason is that always having a second task downloaded while the first one is running avoids wasting GPU time by having no task running while it is downloading the second one. I wouldn't mind if it waited for this download until the first task was approaching its finish, though. But note that the estimated time to completion is not a reliable way of deciding when it is about to finish until at least a few tasks have completed successfully. | |
ID: 56491 | Rating: 0 | rate: / Reply Quote | |
Wouldn't you be able to set the max_concurrent variable in the GPUGRID app_config file to 1? | |
ID: 56494 | Rating: 0 | rate: / Reply Quote | |
That only affects how many jobs run concurrently. Not how many get downloaded. | |
ID: 56495 | Rating: 0 | rate: / Reply Quote | |
Abort for every task, that shows 0.333%, 1,333% and so on. <core_client_version>7.16.11</core_client_version> <![CDATA[ <message> aborted by user</message> <stderr_txt> 20:41:32 (19816): wrapper (7.9.26016): starting 20:41:32 (19816): wrapper: running acemd3.exe (--boinc input --device 0) 02:44:06 (1896): wrapper (7.9.26016): starting 02:44:06 (1896): wrapper: running acemd3.exe (--boinc input --device 0) Detected memory leaks! Dumping objects -> ..\api\boinc_api.cpp(309) : {1546} normal block at 0x000001C43E1D27E0, 8 bytes long. Data: < > > 00 00 17 3E C4 01 00 00 ..\lib\diagnostics_win.cpp(417) : {205} normal block at 0x000001C43E1D68C0, 1080 bytes long. Data: <0 > 30 0B 00 00 CD CD CD CD C4 01 00 00 00 00 00 00 Object dump complete. 17:20:35 (8916): wrapper (7.9.26016): starting 17:20:35 (8916): wrapper: running acemd3.exe (--boinc input --device 0) 17:30:43 (12568): wrapper (7.9.26016): starting 17:30:43 (12568): wrapper: running acemd3.exe (--boinc input --device 0) Detected memory leaks! Dumping objects -> ..\api\boinc_api.cpp(309) : {1546} normal block at 0x0000029AAAFE2EC0, 8 bytes long. Data: < > 00 00 F9 AA 9A 02 00 00 ..\lib\diagnostics_win.cpp(417) : {205} normal block at 0x0000029AAAFE68C0, 1080 bytes long. Data: < 3 > FC 33 00 00 CD CD CD CD C8 01 00 00 00 00 00 00 Object dump complete. </stderr_txt> ]]> | |
ID: 56499 | Rating: 0 | rate: / Reply Quote | |
I wouldn't mind if it waited for this download until the first task was approaching its finish, though. But note that the estimated time to completion is not a reliable way of deciding when it is about to finish until at least a few tasks have completed successfully. Agree. If a second task is downloaded at, say, 80% of the first task, or even 90%, it should work well. E.g., short-term tasks are small, so it won't take long to download them before the first finishes. For large tasks, 10% may still take some 15-30 min at least, so also should be more than enough to complete download. And with the recent large tasks, 10% is a few hours, so definitely, BOINC will make it in time before completing the first task. | |
ID: 56500 | Rating: 0 | rate: / Reply Quote | |
clych wrote: I have aborted this WU, new one much more faster. Sorry, but what you're doing does not make any sense. By now you have 9 aborted WUs. No matter how often you abort, these new monster WUs are just too big for your quite old card to return in time. clych wrote: Abort for every task, that shows 0.333%, 1,333% and so on. No, this is wrong. See The answer from Ian&Steve: link BTW: my GTX1070 takes 94k - 95k per WU in Win 10, in line with the 26h reported before under Linux. MrS ____________ Scanning for our furry friends since Jan 2002 | |
ID: 56501 | Rating: 0 | rate: / Reply Quote | |
I now solved my issue with all WUs failing with CUDA error 999. ACEMD failed: Error initializing CUDA: CUDA_ERROR_UNKNOWN (999) at /opt/conda/conda-bld/openmm_1589507810497/work/platforms/cuda/src/CudaContext.cpp:148 After looking around, I found this thread, where the error 999 was encountered after entering the sleep mode. Simple reboot fixed my issue. 🤦 | |
ID: 56502 | Rating: 0 | rate: / Reply Quote | |
I crunch only during office hours*. It looks like my GTX 1060 will just make the 5 day limit on these biggies, but only if I hand massage it each week. :( If I start one each Monday then the weekend won't get in the way. | |
ID: 56503 | Rating: 0 | rate: / Reply Quote | |
No, normal WU shows me a % after 1 minute after star. | |
ID: 56506 | Rating: 0 | rate: / Reply Quote | |
No, normal WU shows me a % after 1 minute after start.The present workunits are exceptionally long. It`s took them about 5 minutes for 1%.It takes 4 minutes for an RTX 2080Ti to reach 0,666% with these workunits. Your GTX 650 is too slow for these workunits, you should set GPUGrid to "no new tasks" until this batch is over. | |
ID: 56511 | Rating: 0 | rate: / Reply Quote | |
Message boards : News : Project restarted