RoseTTAFold All-Atom 0.03 (nvidia_alpha)
Message boards : RALPH@home bug list : RoseTTAFold All-Atom 0.03 (nvidia_alpha)
| Author | Message |
|---|---|
 rilian Send message Joined: 7 Sep 07 Posts: 35 Credit: 107,666 RAC: 725 |
new task https://ralph.bakerlab.org/result.php?resultid=5469367 failed after few mins <core_client_version>8.0.2</core_client_version>
<![CDATA[
<message>
The access code is invalid.
(0xc) - exit code 12 (0xc)</message>
<stderr_txt>
C:ProgramDataBOINCprojectsralph.bakerlab.orgcv2rf2aautil.py:450: UserWarning: Using torch.cross without specifying the dim arg is deprecated.
Please either pass the dim explicitly or simply use torch.linalg.cross.
The default value of dim will change to agree with that of linalg.cross in a future release. (Triggered internally at C:cbpytorch_1000000000000workatensrcATennativeCross.cpp:66.)
Z = torch.cross(Xn,Yn)
usage: predict.py [-h] [-checkpoint CHECKPOINT] [-pdb PDB] [-silent SILENT] [-tmpl_chain TMPL_CHAIN]
[-tmpl_conf TMPL_CONF] [-movescale MOVESCALE] [-n_pred N_PRED] [-n_cycle N_CYCLE] [-no_extra_l1]
[-no_atom_frames] [-outcsv OUTCSV]
predict.py: error: unrecognized arguments: -z .venv_j_pred_alpha_92.zip
</stderr_txt>
]]>-- I crunch for Ukraine  
|
|
[VENETO] boboviz Send message Joined: 9 Apr 08 Posts: 909 Credit: 1,892,541 RAC: 294 |
I've tried and "old" Quadro K4200, but it has only 4 gb of ram, so boinc manager said "no wus for you" :-( |
|
rilian Send message Joined: 7 Sep 07 Posts: 35 Credit: 107,666 RAC: 725 |
|
|
Grant (SSSF) Send message Joined: 13 Jun 24 Posts: 113 Credit: 193,939 RAC: 2,635 
|
All 25 allowed for the day tasks failed with the same error for me ...Try doing as i did in the official thread. Reset project, and then when your limit expires, see if it is then able to process work again. Grant Darwin NT |
|
rilian Send message Joined: 7 Sep 07 Posts: 35 Credit: 107,666 RAC: 725 |
|
|
Henk Haneveld Send message Joined: 13 Apr 21 Posts: 8 Credit: 88 RAC: 0 |
They lowered the memory demands but they did not fix the CPU work request problems. 03/07/2024 16:48:32 | ralph@home | Requesting new tasks for CPU 03/07/2024 16:48:33 | ralph@home | Scheduler request completed: got 0 new tasks 03/07/2024 16:48:33 | ralph@home | A minimum of 5120 MB (preferably 5120 MB) of video RAM is needed to process tasks using your computer's NVIDIA GPU 03/07/2024 16:48:33 | ralph@home | No tasks sent 03/07/2024 16:48:33 | ralph@home | Tasks for NVIDIA GPU are available, but your preferences are set to not accept them |
|
rilian Send message Joined: 7 Sep 07 Posts: 35 Credit: 107,666 RAC: 725 |
This time task worked fine! on RTX 3060 with Folding@home in parallel, Completed and validated runtime 2,246.30 cpu time 166.20 credits 185.19 -- I crunch for Ukraine
|
Yeti Send message Joined: 19 Feb 06 Posts: 32 Credit: 316,371 RAC: 853 
|
They lowered the memory demands but they did not fix the CPU work request problems. If you would correct your Project-Settings your client wouldn't ask for CPU-Work, look here: ------------------------------------------------------------------ 34094 ralph@home 03-07-2024 19:55 update requested by user 34095 ralph@home 03-07-2024 19:55 Sending scheduler request: Requested by user. 34096 ralph@home 03-07-2024 19:55 Reporting 4 completed tasks 34097 ralph@home 03-07-2024 19:55 Requesting new tasks for NVIDIA GPU 34098 ralph@home 03-07-2024 19:55 Scheduler request completed: got 4 new tasks 34099 ralph@home 03-07-2024 19:55 Project requested delay of 31 seconds 34100 ralph@home 03-07-2024 19:55 Started download of venv_k_pred_alpha_48.zip 34101 ralph@home 03-07-2024 19:55 Started download of venv_k_pred_alpha_79.zip 34102 ralph@home 03-07-2024 19:55 Started download of venv_k_pred_alpha_47.zip 34103 ralph@home 03-07-2024 19:55 Started download of venv_k_pred_alpha_113.zip 34104 ralph@home 03-07-2024 19:55 Finished download of venv_k_pred_alpha_48.zip (1924822 bytes) 34105 ralph@home 03-07-2024 19:55 Finished download of venv_k_pred_alpha_79.zip (1921317 bytes) 34106 ralph@home 03-07-2024 19:55 Finished download of venv_k_pred_alpha_47.zip (1920944 bytes) 34107 ralph@home 03-07-2024 19:55 Finished download of venv_k_pred_alpha_113.zip (1924219 bytes) ------------------------------------------------------------------ For me, all works as it should do and is fully comparable with other BOINC-Projects that run GPU-WUs  Supporting BOINC, a great concept ! |
|
Henk Haneveld Send message Joined: 13 Apr 21 Posts: 8 Credit: 88 RAC: 0 |
They lowered the memory demands but they did not fix the CPU work request problems. My settings are just fine. I don't want GPU work because I have a old card with limited memory. I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work. and the message about the needed amount of RAM for GPU is plain stupid because I did not ask for that kind of work. This is still the same problem from before caused by them mixing CPU and GPU settings in the app. |
|
[VENETO] boboviz Send message Joined: 9 Apr 08 Posts: 909 Credit: 1,892,541 RAC: 294 |
I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work. Me too. |
|
Grant (SSSF) Send message Joined: 13 Jun 24 Posts: 113 Credit: 193,939 RAC: 2,635
|
I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work.And then if there is CPU work, you won't get it because your system has been set not to. Things are as they should be- If there are multiple types of work available, and the option exists to choose between them, then it is entirely up to the account holder to choose what types of work they want to do. Not the project. and the message about the needed amount of RAM for GPU is plain stupid because I did not ask for that kind of work.Your reaction to the message is what's silly. It is pointing out that GPU work is available, but you have set your preferences to not accept them. And it's also pointing out that your system couldn't handle them anyway. Yes, a "No CPU work is available" message should be the response to no CPU work being available when requested, but the message that GPU work is available, and the minimum amount of VRAM required to do so is a good thing & should not be changed. Yes, it should include the amount of VRAM on your GPU in that message, but the message should be there. But both of those GPU messages should be there when requesting CPU work. Remove them, and then we'll get people complaining they didn't know that GPU was available at the time... Grant Darwin NT |
|
Henk Haneveld Send message Joined: 13 Apr 21 Posts: 8 Credit: 88 RAC: 0 |
I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work.And then if there is CPU work, you won't get it because your system has been set not to. You are very wrong. What gives you the idea that I have set my preferences to NO CPU. Its is set to NO GPU If you don't know the difference between these 2 settings then you should not pretend to know how this should work. I have been doing this sinds early SETI Classic that started about 25 years ago. I know what I am doing. If I ask for CPU work I should get it or a message that there is no work available or a message that there is no CPU app that sets the client to not asking. The mention that there is GPU work is correct but the VRAM message should not be given because its not relevant for a CPU work request. The VRAM message should only be given on a GPU work request to a host with not enough VRAM. |
|
Grant (SSSF) Send message Joined: 13 Jun 24 Posts: 113 Credit: 193,939 RAC: 2,635
|
You are very wrong.Nothing at all. Why on earth would you ask that? Did you actually red what i posted? Did you even read what you posted? Please- read what is actually posted and not what you think was posted. Remember- you specifically said this, I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work.That is the exact copy (italics mine), of what you posted. You want the system to change your preferences to not doing CPU work, if there is none available. And so i pointed out the ramifications of that- if some work CPU does become available, you still won't get any because you specifically stated that you want the project to stop your system from asking for CPU work if there is none available. I do want CPU work. If the project does not have CPU work it should give a different message that sets the client to no longer asking for CPU work. Now how on earth would you come to the absurd conclusion that i would think you have set your preferences to No CPU work based on that?????? If I ask for CPU work I should get it or a message that there is no work availableWhich is what is happening. or a message that there is no CPU app that sets the client to not asking.Which i answered above as to why that should not occur, but i'll repeat myself yet again- if some CPU work does become available, you still won't get any because you specifically stated that you want the project to stop your system from asking for CPU work if there is none available. And if your system doesn't request it, you'll never get it even if does become available, until you personally go back in to your project settings to re-enable it. The mention that there is GPU work is correct but the VRAM message should not be given because its not relevant for a CPU work request.And i pointed out why it was an appropriate response to a request for CPU work. Grant Darwin NT |
|
Henk Haneveld Send message Joined: 13 Apr 21 Posts: 8 Credit: 88 RAC: 0 |
You are very wrong.Nothing at all. If my remark about no longer asking for CPU work is wrong explain this one for me. It is taken from the properties on the client for a project that does not even has the option of choosing CPU, GPU of both. Don't request tasks for NVIDIA GPU -- Project has no apps for NVIDIA GPU This would mean that this project would not ask for GPU work even if it became available. If the client does this for no GPU apps it should do the same for no CPU apps. The action that will be needed by the users is to manualy perform a Update request to the server to reset and remove the block when a app becomes available. |
|
Grant (SSSF) Send message Joined: 13 Jun 24 Posts: 113 Credit: 193,939 RAC: 2,635
|
If my remark about no longer asking for CPU work is wrong explain this one for me. It is taken from the properties on the client for a project that does not even has the option of choosing CPU, GPU of both.I'm not entirely sure what you're getting at, so i'm very much guessing here with my response (and there has been exactly zero feed-back from the developers here so i'm making some massive guesses as to what's been going on here and why). For a project that has only a CPU application, in it's "Preferences for that project" it will have a "Use CPU" option that will be selected. In the BOINC Manager, if you select that project, then if you look at the project's Properties, you will see under Scheduling "Don't request tasks for NVIDIA GPU -- Project has no apps for NVIDIA GPU" (or AMD, or Intel if that is what you have). What happened here at Ralph was they released an application that could run on both the CPU & the GPU. There was still only the "Use CPU" option in the project preferences. This caused all sorts of problems (and if you were with Seti when GPU applications first came out you'd know what they were- wild Credit variations, issues with initial Estimated completion times, issues with work Scheduling due to the huge difference in processing times, issues with caches over/under filling). And this was all amplified with the behaviour of the application on the CPU (each Task trying to use 8 threads). So they went with what every other project has done and have different applications for CPU & GPU work. And so they added the "Use NVIDIA GPU" option in the Ralph preferences. Because this was added to the project options, and the default is enabled, systems that had a Nvidia GPU would now start requesting for the GPU. Once those options are there, if you change them to not use that processor (CPU or GPU or whatever), then your system(s) using those preferences will never request work for that processor (CPU or GPU or whatever). The only way that will happen, is if you go in there & re-enable it. If you do as you want it to- allow the project to change those settings just because there isn't any work available for that compute device, then even if work does become available, your systems(s) won't request any because they have been configured not to. They would only get that work again if you went in an changed the settings back. And if there aren't any messages in your log telling you that type of work is available, how would you know? This would mean that this project would not ask for GPU work even if it became available.This is where you are confused- the client does not do this for no GPU apps. If is a function of the project's scheduler configuration, as shown in the "Preferences for this project." If there is no GPU application for that project, you get that message. If there is no CPU application, you would get a "Don't request Tasks for CPU - Project has no apps for CPU" type message. But because of the way the application here was developed (it can run on both the CPU & the GPU), and was initially rolled out and the later changes to support that, the project server has not been configured to report no CPU application is available- which is why the "Use CPU" option is still there on your "Preferences for this project" Ralph account page. The action that will be needed by the users is to manualy perform a Update request to the server to reset and remove the block when a app becomes available.And if they aren't looking in their event log, or there aren't any messages there, how would they know? If you don't want it to request work, then set it not to. But there is no way it makes any sense for the project to change that preference for you. Grant Darwin NT |
|
Henk Haneveld Send message Joined: 13 Apr 21 Posts: 8 Credit: 88 RAC: 0 |
Ik think we are getting on the same page. The server and the client are designed to run separate CPU and GPU apps, either by server settings or user preferences We are looking at it from different angles at how thinks should work and that is OK. The attempt from the admins to combine both CPU and GPU in one app has the server and the client confused and without action from the admins to either drop his attempt or find a new way to do this it is probably beter to suspend this discussion. |
|
rilian Send message Joined: 7 Sep 07 Posts: 35 Credit: 107,666 RAC: 725 |
because this is a alpha/beta project i think it is useful if it reports all the time tech details of what work is available -- I crunch for Ukraine
|
|
Sabroe_SMC Send message Joined: 10 Sep 10 Posts: 6 Credit: 1,067,564 RAC: 77 
|
Hello guys Are you foolish or what? Last Wus are around 640 sec long (with 2 at the same time on my card) and now 50% longer and all for the same credits?!?!?! 5472493 4856710 6 Jul 2024, 18:03:47 UTC 6 Jul 2024, 18:20:17 UTC Fertig und Bestätigt 949.83 0.22 185.19 Generalized biomolecular modeling and design with RoseTTAFold All-Atom v0.03 (nvidia_alpha) windows_x86_64 5472501 4856718 6 Jul 2024, 18:03:47 UTC 6 Jul 2024, 18:20:17 UTC Fertig und Bestätigt 947.87 0.28 185.19 Generalized biomolecular modeling and design with RoseTTAFold All-Atom v0.03 (nvidia_alpha) windows_x86_64 5471202 4855760 3 Jul 2024, 18:11:11 UTC 4 Jul 2024, 10:04:13 UTC Fertig und Bestätigt 637.05 0.23 185.19 Generalized biomolecular modeling and design with RoseTTAFold All-Atom v0.03 (nvidia_alpha) windows_x86_64 5471237 4855816 3 Jul 2024, 18:10:37 UTC 4 Jul 2024, 10:04:13 UTC Fertig und Bestätigt 637.05 0.22 185.19 Generalized biomolecular modeling and design with RoseTTAFold All-Atom v0.03 (nvidia_alpha) windows_x86_64 |
|
Grant (SSSF) Send message Joined: 13 Jun 24 Posts: 113 Credit: 193,939 RAC: 2,635
|
Hello guysNot as foolish as you for running two at time. Per Task runtime doesn't matter- the number per hour is what matters. On my RTX 2060 & RTX 2060 Super the GPU load is around 75% to 80% for these Tasks. Given that the GPU load is over 50%, and it requires about 1.3 CPU cores to support one Task, even if you give them 3 CPU cores to support 2 GPU Tasks when running two at a time, and the fact that the application has not been optimised much (if at all) as shown by the frequent dips in the GPU load & less frequent but very regular large dips in GPU load, it doesn't make much sense to run 2 at a time. Run one at a time & see how it goes. As for the Credit per Task- it's Alpha work, things will change as they progress. At least for the last batch the Credit per Task was much more consistent than the earlier batches & applications. And as for their Runtime- while they take longer than the last batch, they are still taking less time than the first batch i was able to process on the GPU. Grant Darwin NT |
|
Drago75 Send message Joined: 29 Jul 22 Posts: 3 Credit: 70,604 RAC: 227
|
I got 6 units of the latest batch and all errored out after 4 seconds because of an access code violation. Same fate for my wingmen. Windows 10, RTX 4080, 32 GB RAM. Anybody who managed to finish off a bunch of them care to share your system details? |
Message boards :
RALPH@home bug list :
RoseTTAFold All-Atom 0.03 (nvidia_alpha)
©2024 University of Washington
http://www.bakerlab.org