Posts by rsNeutrino

1) Message boards : Number crunching : Faulty reported task runtime and credits (Message 1816) Posted 28 Dec 2024 by rsNeutrino Post: The tasks are like quests and the credits are like surprise crates 😅 It's a real lottery how much you get. Maybe because of some statistical chaos with the new app, this takes the cake: https://yafu.myfirewall.org/yafu/result.php?resultid=9214108 Run time 11 sec CPU time 14 sec Credit 119.84 https://yafu.myfirewall.org/yafu/result.php?resultid=9214333 Run time 3 hours 10 min 28 sec CPU time 1 days 16 hours 58 min 47 sec Credit 127,774.34 https://yafu.myfirewall.org/yafu/result.php?resultid=9215529 Run time 3 hours 59 min 5 sec CPU time 2 days 5 hours 7 min 57 sec Credit 156,519.73 An inverse case, double the work, 100 times less credits: https://yafu.myfirewall.org/yafu/result.php?resultid=9213247 Run time 8 hours 48 min 27 sec CPU time 4 days 20 hours 39 min 26 sec Credit 1,796.24 All with Application version YAFU-16t v212.01 (16t) The now active pattern seems to be a consistent factor of around 11 credits per run time second starting between 7:00 and 18:00 yesterday (2024-12-27). Like 100 times more credits than before, at least for the 16t variant. I'm not complaining 😁
2) Message boards : News : YAFU version 212 for Linux (Message 1813) Posted 27 Dec 2024 by rsNeutrino Post: Ahh, is this why the factor.log has gotten some new quality of life details? Just noticed with the new (integer) app version 21201 of a yafu-16t task the number field sieve phase got a nice ETA! 12/26/24 23:50:57, scheduler: switching to sieve method 12/26/24 23:50:57, nfs: commencing nfs on c138: 445525792978052307957710865594505270771638897906252169607013305672299703753336652805371263946508498806183619081051863386373921373413417541 12/26/24 23:50:57, nfs: commencing poly selection with 16 threads 12/26/24 23:50:57, nfs: setting deadline of 11011 seconds 12/26/24 23:50:57, nfs: expecting degree 5 poly E from 2.36e-11 to > 2.72e-11 12/26/24 23:50:57, nfs: searching for avg quality poly E > 2.45e-11 12/27/24 00:33:02, nfs: completed 16 ranges of size 250 in 2525.1053 seconds 12/27/24 00:33:02, nfs: best poly = # norm 3.581515e-13 alpha -7.797175 e 3.102e-11 rroots 5 12/27/24 00:33:02, nfs: commencing lattice sieving with 16 threads 12/27/24 00:40:33, nfs: found 388914 relations, need at least 21023254 (filtering ETA: 6h 38m), continuing with sieving ... 12/27/24 00:40:33, nfs: commencing lattice sieving with 16 threads 12/27/24 00:47:58, nfs: found 776914 relations, need at least 21023254 (filtering ETA: 6h 27m), continuing with sieving ... 12/27/24 00:47:58, nfs: commencing lattice sieving with 16 threads 12/27/24 00:55:35, nfs: found 1163355 relations, need at least 21023254 (filtering ETA: 6h 30m), continuing with sieving ... 12/27/24 00:55:35, nfs: commencing lattice sieving with 16 threads 12/27/24 01:03:02, nfs: found 1547320 relations, need at least 21023254 (filtering ETA: 6h 18m), continuing with sieving ... 12/27/24 01:03:02, nfs: commencing lattice sieving with 16 threads 12/27/24 01:10:35, nfs: found 1943126 relations, need at least 21023254 (filtering ETA: 6h 3m), continuing with sieving ... 12/27/24 01:10:35, nfs: commencing lattice sieving with 16 threads 12/27/24 01:18:24, nfs: found 2332972 relations, need at least 21023254 (filtering ETA: 6h 14m), continuing with sieving ... 12/27/24 01:18:24, nfs: commencing lattice sieving with 16 threads
3) Message boards : Number crunching : Running 128t, 64t, & 32t, on 16 thread cpu (Message 1808) Posted 20 Dec 2024 by rsNeutrino Post: This should be the solution: https://boinc.berkeley.edu/wiki/Client_configuration file: cc_config.xml section: <options> field: <ncpus>N</ncpus> default: -1 description: Act as if there were N CPUs; e.g. to simulate 2 CPUs on a machine that has only 1. Zero means use the actual number of CPUs. Don't use this to limit CPU usage; use computing preferences instead. It doesn't seem to be possible to raise the simulated core count just for specific projects, only for the whole client. As long as only yafu is running and all the individual threads are able to run without other hard bottlenecks like RAM this shoudn't be a problem. I suspect that they will fight a little for the real cpu cores with additional context switching, but in general I just expect a scaling of the runtime. Eg. 128t tasks could take a bit over 8 times as long as 16t tasks. More detailled, the unknown factor will be the context switch frequency, the CPU cache reloading time and the amount of CPU cycles this will steal, to cram 128 threads one after another into the 12 real cores of your CPU, while 16 threads can run simultaneously and 112 are suspended at every moment... should be interesting! https://www.youtube.com/watch?v=LDhoD4IVElk
4) Message boards : Number crunching : Faulty reported task runtime and credits (Message 1806) Posted 20 Dec 2024 by rsNeutrino Post: Hello! I just started crunching this project a few days ago and drilled a bit through the logic and plausibility of the whole infrastructure. It's great! Today, I found what seems to be a reporting error concerning the overall task run time (et) (not CPU time, ct): $ grep yafu_ali_3019266_L144_C134_1734494706_18_1 /var/lib/boinc-client/job_log_yafu.myfirewall.org_yafu.txt 1734702315 ue 4070.213696 ct 48933.680000 fe 1349591422494400 nm yafu_ali_3019266_L144_C134_1734494706_18_1 et 3804.080444 es 0 $ journalctl -u boinc-client.service \| grep yafu_ali_3019266_L144_C134_1734494706_18_1 Dez 20 13:41:49 hyperv-ryzen boinc[1259]: 20-Dec-2024 13:41:49 [yafu] Starting task yafu_ali_3019266_L144_C134_1734494706_18_1 Dez 20 13:41:49 hyperv-ryzen boinc[1259]: 20-Dec-2024 13:41:49 [yafu] [cpu_sched] Starting task yafu_ali_3019266_L144_C134_1734494706_18_1 using yafu-8t version 13401 (8t) in slot 0 Dez 20 14:45:14 hyperv-ryzen boinc[1259]: 20-Dec-2024 14:45:14 [yafu] Computation for task yafu_ali_3019266_L144_C134_1734494706_18_1 finished Task: https://yafu.myfirewall.org/yafu/result.php?resultid=9192117 Created 19 Dec 2024, 21:39:37 UTC Sent 20 Dec 2024, 0:53:30 UTC Report deadline 2 Jan 2025, 10:07:14 UTC Received 20 Dec 2024, 13:45:22 UTC Run time 12 hours 51 min 52 sec CPU time 13 hours 35 min 33 sec WU: https://yafu.myfirewall.org/yafu/workunit.php?wuid=7848379 46,312.00 (Run time (sec) = et) 48,933.68 (CPU time (sec) = ct) So the client job log has logged a task run time of 3,804.080444 seconds, confirmed by the start and finish times in the systemd journal, but the server has logged 46,312.00 seconds instead. Sadly I didn't catch the factor.log to see if the wrong time was buried there. Edit: It seems to match the server side delta of the send and receive times: [2024-12-20 13:45:22] - [2024-12-20 00:53:30] = 46312 sec That's new. Why in this instance, and why not for many other tasks?