Posts by danwat1234

1) Message boards : News : Project status: December 2023 (Message 2163) Posted 2 Jan 2024 by danwat1234 Post: Thank you for the update and having super reliable servers and infrastructure
2) Message boards : News : Changes in task scheduling and monitoring mechanism (Message 2142) Posted 19 Nov 2023 by danwat1234 Post: Ah so that's why my ratio of compute for SiDock has been diverting compute from WCG. It used to be perhaps 33% going to Sidock, now maybe 45%, all points being equal.
3) Message boards : News : Target # 22: corona_RdRp_v2 (Message 2106) Posted 8 Aug 2023 by danwat1234 Post: I imagine if SiDock could inspire Russian University and College IT departments to crunch for the cause we can see acceleration!
4) Message boards : News : Target # 22: corona_RdRp_v2 (Message 2104) Posted 7 Aug 2023 by danwat1234 Post: Target 22: corona_RdRp_v2 (%) 33.33% complete congrats! Done by Christmas?
5) Message boards : News : СmDock "long" and "short" tasks applications (Message 1984) Posted 7 Feb 2023 by danwat1234 Post: Can confirm "2.00" jobs were often/always using CPU cycles indefinitely, no problem with 2.02 I deleted all 2.00 jobs from all my queues that seems to be the solution to all trouble.
6) Message boards : News : Merry Christmas! (Message 1780) Posted 4 Jan 2023 by danwat1234 Post: Will the the RAM requirement for the new version of cmdock be much higher? BOINC should automatically update the executable?
7) Message boards : News : Temporarily work unavailabilities (Message 1759) Posted 16 Nov 2022 by danwat1234 Post: It seems to me that this is not, or more than a network bandwidth issue step. I don't think work unit throughput comes close to equaling previous network utilization.
8) Message boards : News : Temporarily work unavailabilities (Message 1744) Posted 28 Oct 2022 by danwat1234 Post: zip is an old school format! .7z or other modern algorithms would probably provide far better compression ratio. You already use it, for instance on CmDock_v0.1.4_2.1_windows_x86_64.zip , 4.85MB in size. If i extract and place contents in a .7z with max compression, it is 3MB and database-type files should see an improvement too. Software solution is probably a lot easier than dealing with network hardware woes
9) Message boards : News : Temporarily work unavailabilities (Message 1740) Posted 27 Oct 2022 by danwat1234 Post: Is compression maximized already or would packing the outgoing work unit and incoming result in a 7z archive in max compression mode result in noticeable smaller transfer size? I have no idea if it's feasible without a lot coding to automate reliably but it may be worth a look
10) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1711) Posted 20 Aug 2022 by danwat1234 Post: I should note that even though you have a server side limit of work units sent for a given estimate computational power of a computer, that does not mean you will have a same-day turnaround. If the user has multiple projects going they could have a significant queue to crunch through before resuming SiDock, depending on BOINC % resource allocation settings and luck. But the proof is in the pudding, err Project Status work unit group completions.
11) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1710) Posted 20 Aug 2022 by danwat1234 Post: Thank you i see what you mean. Many of the work unit groups can be crunched by the community in a week or so I have noticed and you run a tight ship. One group gets to about 98% and then the next group begins to have results sent in and within a few days later the first group is completed no gaps in completion. Enabling larger queues would increase server load by computers not using as large % of the work units given to them 4 whatever reason and more needing to reissued. Is it possible to get a list of future groups to be crunched on the site? Is there an 'end' to this stage of research where the community has completed all work 4 Covid?
12) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1707) Posted 18 Aug 2022 by danwat1234 Post: Thanks, could you say why that severe limit is in place when the deadline shown in the client is multiple days? The file does not seem to exist anywhere so I gather I create the file with only that tag within the SiDock directory. Correct format? I need because i am waiting on some WIFI sticks and would like to lessen the frequency of walking to the internet-less machines with a WIFI stick. cc_config.xml <cc_config> <options> <ncpus>15</ncpus> </options> </cc_config>
13) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1706) Posted 18 Aug 2022 by danwat1234 Post: Thank you, I will try to find that file. Could you say why that limit is in place when the deadline for work units is multiple days out?
14) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1703) Posted 17 Aug 2022 by danwat1234 Post: Seriously in all my 50+ machines, if i unplug a WIFI stick, it stops crunching within 3 hours despite 10 days 10 days set locally and also server side.
15) Questions and Answers : Windows : Project fills CPU use to 100% although "Use at most xx% of CPU time" is set (Message 1702) Posted 16 Aug 2022 by danwat1234 Post: The project processes should be running in low priority so i don't know why it would cause your Intel Alder lake system to bog down. You indicated temperature is not a problem that it is not throttling so i stumped. Could be new architecture issues still needing to be patched. I have this project running on 2nd gen thru 8th gen Intels using all cores 100% of the time and they all stay very responsive.
16) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1701) Posted 15 Aug 2022 by danwat1234 Post: Thank you. 1. SiDock does consistently have work "Tasks ready to send 22058" right now on server status page. 2. Deadline for SiDock work unit is at least 3 days after receiving so that's not the issue since the work units don't take long to compute. My settings BOINC settings are maxxed out and my machines do nothing but BOINC 24/7. Also the settings on my online SiDock profile is maxxed out Store at least 10 days of work Store up to an additional 10 days of work Switch between tasks every 120 minutes Request tasks to checkpoint at most every 60 second Hmmm.
17) Questions and Answers : Windows : Will not queue more than about 4 work units per core despite set for 10 days of work (Message 1699) Posted 14 Aug 2022 by danwat1234 Post: i have noticed that for say an 8th gen Intel box, 6 core, it won't queue more than about 24 work units at a time despite having my queue settings maxxed out in BOINC at 10 days in both fields. Each work unit usually takes less than 2 hours some less than 1 hour. Is this a bug or perhaps my BOINC clients are confused by Rosetta occasionally sending a few work units out so it is holding off on queuing up SiDock?
18) Message boards : Number crunching : corona_NSP16_v1, why does this require more units than the others? (Message 1660) Posted 8 Jul 2022 by danwat1234 Post: Thank you that confirms more iterations. I hadn't noticed longer compute times but that's probably because I'm used to Rosetta. Do you know if the client is optimized for SIMD instruction sets or is it computing with straight x86? You could get a lot more throughput/energy efficiency if you run a check to see what instruction sets are supported by the computer and run the appropriate executable that could be developed.
19) Message boards : Number crunching : corona_NSP16_v1, why does this require more units than the others? (Message 1658) Posted 6 Jul 2022 by danwat1234 Post: corona_NSP16_v1, why does this require more units than the others? I have noticed the earlier Covid iterations were crunched within 1 week. This has been crunching for over 1 month. I am curious why that is, is it a more complex database file it is comparing the work unit key against or is it the same. More keys? Forgive me, my terminology is wrong but I think you know what I mean.