| log in |
|
41)
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) |
|
42)
Message boards :
Number crunching :
OUT of tasks
(Message 2954)
Posted 26 Oct 2022 by Retvari Zoltan Thank you. Sorry for putting the blame on you, I didn't know about the SQL server anomaly. |
|
43)
Message boards :
Number crunching :
OUT of tasks
(Message 2951)
Posted 26 Oct 2022 by Retvari Zoltan As you can see on the left side of the server status page, the gene_work_generator is not running, hence no new work is generated. The other components are running, so the completed workunits can be uploaded and validated. Probably the project administrator intentionally stopped the work generator process, to reduce the workload on the (problematic) storage servers. It would have been nice to announce it in the news feed before we notice the effect on our hosts. |