Posts by Juha

1) Message boards : Number crunching : Rosetta 4.0+ (Message 90524) Posted 15 Mar 2019 by Juha Post: @David E Kim I'll look into this. Could you also take a look at Linux 4.08 x86_64 version? I don't think I'm exaggerating much if I say it's crashing two thirds of the tasks on my machine. I have an older Linux machine and the previous 4.07 x86_64 version ran just fine. Failed tasks were rare with it. What's curious is that if a task that failed with 4.08 gets a second try on Windows machine it always succeeds. That suggests a bug in the app instead of tasks.
2) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 90523) Posted 15 Mar 2019 by Juha Post: 19gb swap space used is concerning. 19 GB would indeed be a lot of swap in use but haven't you got the unit wrong? It looks like 19 MB to me.
3) Message boards : Number crunching : Rosetta 4.0+ (Message 88958) Posted 20 May 2018 by Juha Post: I added the above to the "/lib/systemd/system/boinc-client.service" file under the [Service] section. That's ok. Should I make a new "[pre][Service]" section instead? I don't really know what systemd says if you have more than one section with the same name in the same file.
4) Message boards : Number crunching : Rosetta 4.0+ (Message 88951) Posted 19 May 2018 by Juha Post: /etc/locale.conf Instead of changing language options globally I would suggest limiting changes to only what is needed, in this case BOINC client. For those using repository BOINC package and systemd distro, you can edit boinc-client.service file or add an override to the service. The override would look something like this: [Service] Environment=LC_ALL=C LC_ALL overrides all the other language settings. Put the override file in /etc/systemd/system/boinc-client.service.d/locale.override.conf and restart the client with sudo systemctl restart boinc-client. If changing the distro supplied service file then find boinc-client.service and add the Environment line in Service section. Changes to the file will be overwritten any time the package is updated. For those not using distro package or not using systemd make similar change to whatever startup script you use for the client.
5) Message boards : Number crunching : Rosetta 4.0+ (Message 88210) Posted 1 Feb 2018 by Juha Post: Windows XP. Issue with v4.06 Looks like 4.06 was compiled with Visual Studio 2015 which by default doesn't create XP compatible program files. I don't know if the project decided to drop XP support or if it happened accidentally.
6) Message boards : Number crunching : [error] Can't create HTTP response output file (Message 87686) Posted 13 Nov 2017 by Juha Post: Since those are executable files you have problems with, it could be antivirus program that blocks BOINC from creating the files. Or it could be that the files already exists (partially downloaded) but BOINC can't open them for writing (to continue downloading). You could check C:ProgramDataBOINCboinc.bakerlab.org_rosetta to see if the files exist and if they do, remove them.
7) Message boards : Number crunching : Errors? (Message 87404) Posted 28 Sep 2017 by Juha Post: There is a bug in BOINC 7.8.2 and the current version of Rosetta doesn't handle it well and the tasks crash. You need to downgrade back to 7.6.33 until a new BOINC version is available.
8) Message boards : Number crunching : Larger Memory Models (Message 86948) Posted 2 Aug 2017 by Juha Post: There is no need to introduce a button for tasks with high memory usage. BOINC server already handles this out of the box. The server sends only such tasks to a host that have rsc_memory_bound less than the memory limit set in host's/user's computing preferences. If user doesn't want memory filled with tasks all he or she needs to do is lower the memory limit in computing preferences. That does mean that the project needs to fill rsc_memory_bound accurately. The few tasks that I sampled had rsc_memory_bound=1e8 bytes but actual memory usage was 300-400 MB. Naughty.
9) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 86875) Posted 28 Jul 2017 by Juha Post: But why do I get WUs sent that are currently crunched by other hosts? The task I linked above has been sent to me while another host was working on it. After he finished successfully the server aborted my copy, that can't be correct. If you look at the first copy carefully you'll see that it had missed its deadline: Created 19 Jul 2017, 10:21:00 UTC Sent 19 Jul 2017, 11:42:16 UTC Report deadline 27 Jul 2017, 11:42:16 UTC Received 27 Jul 2017, 14:04:30 UTC When the server noticed that the first copy had missed its deadline the server created another copy which was sent to you. This was done on the assumption that the first copy would never be completed. Then the first copy was returned and the server could abort your copy because it wasn't needed any more.
10) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 81079) Posted 23 Jan 2017 by Juha Post: The info. I saw was just that it was deprecated in v7. I also saw some info. about a new server-side figure that replaces debts. So, I'm really uncertain. I had thought debts were stored in the client_state.xml but I don't see them there anymore. I believe the other way to zero one project's debt would be to mark it for no new work, let it work through it's tasks and report them back, then detach and reattach. I believe as a "new" project is attached, it starts with zero debt. The client doesn't use debts any more. Debt based scheduling was replaced by Recent Estimated Credit based scheduling. See Client scheduling policies and its design document Client scheduling changes (note that when the design document speaks of current it means the previous debt based scheduling). REC can be controlled with <rec_half_life_days>, shorter half life -> client has shorter memory. But none of that matters here. When the client asks for more work it asks enough to fill the cache but not more than that.
11) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 80887) Posted 5 Dec 2016 by Juha Post: process got signal 11 My system is: 4.8.0-1-amd64 #1 SMP Debian 4.8.7-1 (2016-11-13) x86_64 GNU/Linux Check system log if you have messages about vsyscall similar to these. If you have then Rosetta app is not compatible with your kernel. See this message for workaround.
12) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 80789) Posted 26 Oct 2016 by Juha Post: The deadlines were longer before. I have a copy of client_state.xml from summer and the one Rosetta task contained in it has 14 day deadline. The deadlines were probably shortened to limit the size of database and thus limit the load on the database server. edit: With that I mean: If a host goes missing after being assigned a task, the task waits until the deadline before it is sent to another host. Shorter deadline -> shorter wait time -> task get out of the system faster -> smaller and faster database. It also reduces the amount of work people can cache which is again better for the database. Your host didn't receive less than 10 days of work because BOINC assumed that the next time your host would be online would be 10 days from the moment your host requested work. Since the deadlines for all tasks were less than that your host would not have been able to complete and report the tasks in time. That setting is a tricky one. I think you are not the first one to get bitten by it.
13) Message boards : Number crunching : Problems and Technical Issues with Rosetta@home (Message 80780) Posted 25 Oct 2016 by Juha Post: My preferences have been the same for years - 10 days of work plus an additional 10. The "Store at least" preference not only tells BOINC what cache size you prefer but also tells BOINC how often BOINC can expect your computer to be online. Setting it to 10 days tells BOINC there's an Internet connection available every 10 days. Because of that BOINC will try to finish all tasks at least 10 days before their deadline. Right now Rosetta has tasks with 2, 5 and 7 day deadlines. Since there is less than 10 days available to get the work done BOINC client will be constantly in panic mode trying to finish the work before deadline. When the client is in panic mode it may decide to not to try to get more work from the project in question. More work would just make a bad situation even worse. The scheduler checks as well if you can meet the deadline before giving you work. There's fallback code that gives work regardless of deadlines if you have an idle CPU. That explains why you have any work at all. Earlier you had full cache from Seti because they have much longer deadlines. The fix is simple. Just decrease your cache size to something more reasonable, like two days.