| log in |
|
21)
Message boards :
Number crunching :
OUT of tasks
(Message 3204)
Posted 23 May 2023 by Retvari Zoltan In this case, please double the number of chunks, and halve the maximum allowed tasks per cores.> Another solution to this problem is to double workunit lenght The latter is the key to resolve the "out of tasks" problem, the 1st part is needed to keep the hosts busy for the same amount of time. The choice of the right number is a compromise between a lot of things. A very fast workunit will overuse the network connection, a very long one will not be good for people with slow computers or intermittent dedicated time and increases the chance of wasting resources due to computational errors. The deadline should also be adjusted accordingly.Doubling the workunit processing time is a safe bet, as their processing time is the half of the previous project, which were just fine. A sidenote: On hyperthreaded hosts everyone should set in BOINC preferences -> computing preferences -> "Use at most 50% of the processors", the (TN-Grid) performance of the host wouldn't decrease, as it would make the CPU "do the math" twice as fast. |
|
22)
Message boards :
Science :
The new Vitis vinifera project is underway
(Message 3199)
Posted 23 May 2023 by Retvari Zoltan A single gene expansion is made up by 77 workunits, each one contains 800 small computational chunks (PCs), the last one (#77) contains just 400 of them.So a single gene expansion is 76*800+400 chunks, that is 61200 chunks in total. 61200 | 2
30600 | 2
15300 | 2
7650 | 2
3825 | 3
1275 | 3
425 | 5
85 | 5
17 | 17
1 | There are a few numbers around 800 that can divide 61200 to equal sized workunits: 816*75 (17*3*2*2*2*2)*(5*5*3)
850*72 (17*5*5*2)*(3*3*2*2*2)
900*68 (5*5*3*3*2*2)*(17*2*2) But it is desirable to make longer workunits (to be able to generate enough work for all hosts), if it does not take longer for the workunit generator(you should reduce the maximum allowed workunits at the same time to prevent hoarding): 1020*60 (17*5*3*2*2)*(5*3*2*2)
1200*51 (5*5*3*2*2*2*2)*(17*3)
1224*50 (17*3*3*2*2*2)*(5*5*2)
1275*48 (17*5*5*3)*(3*2*2*2*2)
1360*45 (17*5*2*2*2*2)*(5*3*3)
1530*40 (17*5*3*3*2)*(5*2*2*2)
1700*36 (17*5*5*2*2)*(3*3*2*2)
1800*34 (5*5*3*3*2*2*2)*(17*2) So I would change the workunit size according to the end of this list.
|
|
23)
Message boards :
Science :
Homo Sapiens (OneGenE - FANTOM-1) - End
(Message 3196)
Posted 23 May 2023 by Retvari Zoltan You may see some Hs (FANTOM) workunits floating around again. After a preliminary check of the results we figured out the need to expand another dozen of genes.We may reach 109% at the last final ending of this project :) |
|
24)
Message boards :
Number crunching :
OUT of tasks
(Message 3195)
Posted 23 May 2023 by Retvari Zoltan We have completed 5% of the project in only 8 days, that's Great !One 5% unit is already done, so there are 19 units left, that would take 152 days. But we can do even better, if we don't starve our work servers (nodes) and generate data in parallel. Currently there are ZERO owrk units available.Another solution to this problem is to double workunit lenght and halve the maximum number of cached workunits per core. This solution does not involve rewriting the work generator. |
|
25)
Message boards :
Number crunching :
Shortest processing time ever
(Message 3169)
Posted 15 May 2023 by Retvari Zoltan Vitis vinifera workunits: ~2110 sec (~35m 10s) See here. |
|
26)
Message boards :
Number crunching :
Curious
(Message 3131)
Posted 6 Apr 2023 by Retvari Zoltan Looks like we will finish up this group of work in the next 12 to 24 hours. I hope Denis has a group to distribute while waiting on new work here.I think we have 8 days' work left. (710 genes/isoforms left, the present rate is 87/day) |
|
27)
Message boards :
Number crunching :
Curious
(Message 3123)
Posted 30 Mar 2023 by Retvari Zoltan The number of queued is rising (it's 88856 now), so we may reach 102% in the end :) |
|
28)
Message boards :
Number crunching :
Curious
(Message 3120)
Posted 30 Mar 2023 by Retvari Zoltan It is looking like the original count of genes/isoforms was/is wrong. I believe we still have at least 5 days if not 7 more days of work left to crunch. The queued number seems to be the more accurate count.Provided that this is right, there are 888 genes left ("queued"-"executed"=88374-87486). At the present rate of 90.40/day it will take 9.823 days (9 days, 19 hours, 45 minutes and 8 seconds) to complete. It will take much longer than that, given that the timeout is 5 days, and there will be some workunits stuck on inactive hosts. The work availability will be sporadic after 10 days from now. The status page will show over 100% (probably 101% to 102%) by the time all the genes have been completed.The percentage is the fraction of the "executed" and the "# genes / isoforms". Now it's 87486 / 87554 = 0.999223336... = 99.92% Provided that the "executed" will go over the "# genes / isoforms" to reach the "queued" it will be: 88374 / 87554 = 1.0093656486... = 100.94% |
|
29)
Message boards :
Number crunching :
Completed work not uploading
(Message 3082)
Posted 18 Feb 2023 by Retvari Zoltan This issue hit my hosts again... Is it still the filesystem to blame? |
|
30)
Message boards :
Number crunching :
SSE2 AVX FMA ?
(Message 3076)
Posted 6 Feb 2023 by Retvari Zoltan You can try to set "use at most 50% of the CPUs" in BOINC manager (options -> Computing preferences) to halve your runtimes. Furthermore I suggest you to put another 8GB RAM in your laptop. |
|
31)
Message boards :
Number crunching :
Shortest processing time ever
(Message 3062)
Posted 15 Jan 2023 by Retvari Zoltan I've tested a PC with an i5-13600K CPU at 5.1GHz (RAM is dual chanel DDR4 at 3600MHz) under Linux. This CPU has 6 P-cores and 8 E-cores (20 threads total). First I run 7 TN-Grid task by mistake, later 5 TN-Grid tasks plus one folding@home GPU task (which uses a full CPU thread to feed the GPU). The processing times has gone as low as 3800 seconds (1 hour and 3-4 minutes) for the FMA app. You can check the results here. The processing times got lower as much as the clock speed got higher. I've concluded that the 13th generation Intel CPUs have the same P-Cores as the 12th gen CPUs had, though the clock speeds got slightly higher (just as the power limits). If there's any new feature in the 13th gen P-Cores, the TN-Grid client does not benefit from it. |
|
32)
Message boards :
Number crunching :
Server problem with the filesystem
(Message 3027)
Posted 30 Nov 2022 by Retvari Zoltan I have some ghost tasks (tasks that appear only on the webpage) on my hosts. |
|
33)
Message boards :
News :
Storage problem
(Message 3019)
Posted 23 Nov 2022 by Retvari Zoltan There are 18502 tasks ready to send. I haven't seen that many in the last month. Has the storage problem been solved? |
|
34)
Message boards :
Number crunching :
Server problem with the filesystem
(Message 3014)
Posted 16 Nov 2022 by Retvari Zoltan I can't upload this result for almost 5 days: 220809_Hs_T197131-ARHGAP36_wu-71_1668181757175_0 |
|
35)
Message boards :
Number crunching :
OUT of tasks
(Message 2991)
Posted 10 Nov 2022 by Retvari Zoltan The work generator is not working. My uploads are stuck. |
|
36)
Message boards :
Number crunching :
Shortest processing time ever
(Message 2981)
Posted 6 Nov 2022 by Retvari Zoltan If you don't turn off hyperthreading in the BIOS how do you guarantee only one thread per physical CPU core.I wrote a little batch program (for Windows) to set process affinities in order to assign tn-grid tasks to different CPU cores, but it made a very little difference. The OS doesn't know the difference and will schedule threads on whatever is available.Every recent OS knows the difference between CPU cores and threads. (On Windows you can check it in task manager, on the CPU tab you'll see how many cores and how many threads your CPU has). The recent OSes even know the difference between the "performance-cores" (p-cores) and the "efficiency-cores" (e-cores) of the recent Intel CPUs (the latter doesn't have HT, or FPU). The Ubuntu Linux 22.04 I use scedules tasks for each CPU core (and leaves it running on that core), until it runs out of cores. Windows use a different approach (spreading a high CPU load process evenly between cores to make the cores heat up evenly - probably that makes tasks run slower on Windows), but it won't use the same core for two high CPU load process until it runs out of cores. If you truly want to only run one thread on a core you have to turn off hyperthreading.That'll surely force the OS not to schedule tasks on the same core, but it's necessary only for old OSes. |
|
37)
Message boards :
Number crunching :
Shortest processing time ever
(Message 2979)
Posted 6 Nov 2022 by Retvari Zoltan If you don't want to reduce the number of tasks queued on your host by limiting the number of CPU cores generally in BOINC, you can use the app_config.xml file to limit the number of simultaneous tasks for each project.A little correction: this method (just like setting a global limit on the usable CPU cores in BOINC) limits the number of tasks queued. (I've set up my host like that to verify it). The main message of this experiment is that one should not crunch (single-threaded apps) on the "virtual" (hyper-threaded) cores to achieve short runtimes. (Running too many of these tasks makes them wait for each other's FP operations, it could also easily fill up the last level cache of the CPU, resulting in increased cache misses and much slower memory transfers.) |
|
38)
Message boards :
Number crunching :
Shortest processing time ever
(Message 2978)
Posted 5 Nov 2022 by Retvari Zoltan it was just an outlier with a limited parameter set that lead to a shorter cruching time. The major factor that made this task that fast is there was nothing else running on that host at that time, so the single core turbo could kick in. Previously I had some random restarts when the folding@home was running on that host. After a week I've figured out that it's PSU-related: there are not enough power cables for the CPU and the GPU, so I've swapped the PSU. Since then it seems to be running fine at 4.7GHz on all p-cores. The processing time is around 4.100-4.300 seconds (7 TN-Grid tasks + 1 Folding@home task). (The e-cores are not that great for crunching) |
|
39)
Message boards :
Number crunching :
Shortest processing time ever
(Message 2977)
Posted 5 Nov 2022 by Retvari Zoltan It could just be a smaller task. It was a "normal" task. |
|
40)
Message boards :
Number crunching :
Shortest processing time ever
(Message 2968)
Posted 2 Nov 2022 by Retvari Zoltan 3.817,81 seconds (1 hour 3 minutes 37,81 seconds). This was done on my i9-12900F - no CPU overclocking (beside the built-in "turbo mode") - the RAM is DDR5 @ 5200MHz 40-40-40-80 in dual channel - no other tasks were running (hence the single core turbo mode) - processing is done by the FMA app - the OS is Linux Ubuntu 20.04.5 LTS (5.15.0-52) When there are 7 TN-Grid tasks + 1 Folding@home GPU task running on this host, the TN-Grid processing times are around 5.100 seconds. This is ~33,6% increase, that reflects the CPU clock difference between the turbo mode, and the non-turbo mode (5.1GHz vs 3.8GHz, this CPU has a 65W TDP). To achieve optimal processing times, I suggest to limit the number of usable CPU cores in BOINC to 50% on hyper-threaded (or SMT, in AMD terminology) hosts, especially on Linux (Or even lower on 12th gen (or newer) Intel CPUs with efficiency cores (i5-12600k, i7, i9)). Depending on the CPU architecture and the RAM bandwith, this may even slightly increase the RAC of a given host. If you don't want to reduce the number of tasks queued on your host by limiting the number of CPU cores generally in BOINC, you can use the app_config.xml file to limit the number of simultaneous tasks for each project. For example put an app_config.xml file to the C:\ProgramData\BOINC\projects\gene.disi.unitn.it_test folder (/var/lib/boinc-client/projects/gene.disi.unitn.it_test on Linux) With the following content: (you should set your own number of CPU cores, I used 8 in this example) <app_config>
<project_max_concurrent>8</project_max_concurrent>
</app_config> (repeat this process for all single-threaded CPU projects) |