Posts by xii5ku

21) Message boards : Number crunching : Threadripper 3990x stingy scheduler (Message 419) Posted 17 Jan 2021 by xii5ku Post: For us donors who need to plan and maintain our donations, there are generally three methods to approach this: 1) Ask the project admins for a general increase of these host limits. Of course this is what this thread is for. Lately, this project became better in keeping small/slow computers fed with work overnight. Large/fast computers are still prone to run out of work, and as mentioned, more than 128 logical CPUs are not being fed even with 1-deep workqueue. 88- and 96-threaded computers have been a common sight in Distributed Computing for years now, 128-threaded computers are quite common now too, and 256-threaded computers are making more appearances too. Particularly, what the SiDock@home server is perceiving currently is listed here: cpu_list.php So the question is, to which degree are the admins ready to cater to the convenience of donors with larger/faster-than-average hosts? 2) As an individual donor of large/fast hosts, get in personal contact with an admin and ask for the server to have extra limits configured for selected host IDs. I don't know if this is acceptable here at SiDock. I never tried this approach at any project myself; I merely saw that some project admins do this. 3) Partition your single large/fast computer into several small/slow computers. This gives very good control into your own hands, and it works with almost all projects. Therefore, this is what I routinely do at projects with low limits of work in progress per host, if I am having trouble to maintain a reasonable work buffer at such projects. This method needs to be implemented responsibly though. I am not going into detail how to implement it.
22) Questions and Answers : Unix/Linux : GLIBC_2.27 Req (Message 418) Posted 17 Jan 2021 by xii5ku Post: Gunnar Hjern wrote: Will such a thing be possible with Ubuntu/Debian too? While I have some computers with Debian based OS too (Mint), I have very little experience using these. I treat these computers as appliances and rely a lot on advice from team mates in matters of administration of this OS. According to a web search, the contents of a .deb package can be extracted (not installed) with: dpkg --extract file.deb temporarydirectory/
23) Message boards : News : New application: CurieMarieDock (Message 387) Posted 6 Jan 2021 by xii5ku Post: Ritschie wrote: hoarfrost wrote: Hi folks! Update: New application (CurieMarieDock) need a glibc version 2.27 or higher! As we see, most Linux computers meet these requirements. Bad news for me. My machines are all running openSUSE Leap 15.2 and this currently only offers glibc 2.26. So I can only run RxDock. Are there any considerations to change the dependency from glibc 2.27? I am using openSUSE Leap 15.2 too. But I can run CurieMarieDock just fine, due to a hack which I implemented earlier for a Universe@home speedup. I posted the hack in "Questions and Answers : Unix/Linux : GLIBC_2.27 Req". Ritschie wrote: Is there an benefit of glibc 2.27? As far as I can tell from the 2.27 release plan, there is nothing interesting in it; no major feature, and no fix which a distributor wouldn't backport if strictly needed as a hotfix.
24) Questions and Answers : Unix/Linux : GLIBC_2.27 Req (Message 386) Posted 6 Jan 2021 by xii5ku Post: Here is a workaround for openSUSE Leap (glibc 2.26) users: When it became known that Universe@home benefits substantially from glibc 2.29 and later, I copied libm and libmvec version 2.31 from openSUSE Tumbleweed onto my openSUSE Leap computers. I am receiving CurieMarieDock tasks and they complete fine. This is what I did: download glibc-2.??-.x86_64.rpm from https://download.opensuse.org/tumbleweed/repo/oss/x86_64/ in a temporary directory, extract the rpm file: rpm2cpio glibc.rpm \| cpio -idmv copy libm and libmvec into the library load path, e.g.: sudo cp -p libm-2.??.so libmvec-2.??.so /lib64/ stop boinc: sudo service boinc-client stop register the new library versions: sudo ldconfig restart boinc: sudo service boinc-client start * * * * W A R N I N G * * * * Mixing library versions in this way is dangerous and completely unsupported. It can make your system unusable. Don't do it unless you know how to detect whether or not possibly occurring problems are caused by this workaround, and unless you know how to restore your system to the distributor's glibc version. I chose this nasty hack because it appeared a lot easier to perform than a proper glibc version update. Some time after I performed this workaround, Tumbleweed advanced from glibc 2.31 to 2.32. I have not tried if my workaround works with 2.32 too.

Previous 20