Message boards :
Xtrack/SixTrack :
Xtrack (Xboinc)
Message board moderation
Previous · 1 . . . 3 · 4 · 5 · 6 · 7 · 8 · 9 . . . 12 · Next
| Author | Message |
|---|---|
|
Send message Joined: 22 Mar 17 Posts: 76 Credit: 27,457,258 RAC: 110,147  
|
At least in BOINCTssks it can only go 2 digits to the right of the decimal so 0.01 days is lowest it will accept. Attempting 0.001 will round off to 0.00 |
|
Send message Joined: 23 Nov 05 Posts: 13 Credit: 1,889,109 RAC: 5,644 
|
At least in BOINCTssks it can only go 2 digits to the right of the decimal so 0.01 days is lowest it will accept. Attempting 0.001 will round off to 0.00 At a setting of 0.1, my 9950X downloads WUs even though there are still just under 300 in the cache. I will change the setting to 0.01 because the machine does not run 24 hours a day. |
|
Send message Joined: 14 Jan 10 Posts: 1460 Credit: 9,841,157 RAC: 3,562 |
At least in BOINCTssks it can only go 2 digits to the right of the decimal so 0.01 days is lowest it will accept. Attempting 0.001 will round off to 0.00 For BOINC you can define up to six decimal places, but it's different whether you use BOINC Manager or BoincTasks as user-interface. BOINC Manager is ignoring the 3rd to 6th decimal, but with BoincTasks the 3rd up to the 6th decimal is maybe not visible in the interface, (because of rounded down to 0.00 (or up - 0.005001 is shown as 0.01, but stored as 0.005001) the value you put in, is stored correctly in your preferences file global_prefs_override.xml. |
|
Send message Joined: 5 Apr 25 Posts: 51 Credit: 824,170 RAC: 22,683   
|
Interestingly, on one single computer that is running Xtrack (on Win11) is apparently showing realistic time estimates. I have two tasks between 30-40% after 50-60 minutes, two at 89% after approx. 5 hours, two at 94.5% after 6h20m. All other computers are still doing to 99% in 5 minutes. It's not even because of a possibly updated task version, as they were all sent out yesterday. Edit: These semmingly correct estimates are for scan #169 that show over 2 hours of estimated runtime before starting (as opposed to 1-2 minutes for other batches) 
|
|
Send message Joined: 2 May 07 Posts: 2276 Credit: 177,520,691 RAC: 78,673 
|
In Boincmanager is a Benchmark function. You can testing, maybe this help with time estimates. |
|
Send message Joined: 5 Apr 25 Posts: 51 Credit: 824,170 RAC: 22,683
|
In Boincmanager is a Benchmark function. That benchmark runs automatically from time to time, I don't think it could affect estimates for similar tasks that (from our side) only differ in batch number and are sent out together.
|
|
Send message Joined: 22 Mar 17 Posts: 76 Credit: 27,457,258 RAC: 110,147
|
Just like at LHC-dev, its the task setup that causes so many to download. Not the queue buffer or the benchmark. This is up to the project, not the user. On top of the poor flops estimate, the tasks very in run time but there is no variation in the task setup. This type of task runs for 30-35 min camontan__tune_scan_end_of_levelling_scan_134__ScanShort_17_3__jR1XCEh0dIuY_0 While this type runs for 3.5-4 hours camontan__tune_scan_start_of_collapse_round_scan_135__ScanShort_40_2__7pq3Q73qWe7d_0 Yet both have the same estimate in between at 53 min |
|
Send message Joined: 12 Jul 11 Posts: 117 Credit: 1,378,540 RAC: 6,731
|
Thans for the information Carlo. On a linux AMD EPYC Milan host I got 100 tasks ended successfully from few minutes to 3h30 max. Now they behave like a normal boinc app, you are making quick progress with the team :) bon courage ! |
|
Send message Joined: 18 Dec 15 Posts: 1906 Credit: 144,143,639 RAC: 73,952 
|
I keep reading about downloads of hundreds of tasks - I guess this happens only when "unlimited number of tasks" is set, correct? So, if one sets say 5 tasks, only 5 are being downloaded - true? Further - are these tasks multi-core - so they work with any number of cores between 1 and 8 ? (Sorry for bothering you guys with these questions - I so far did not manage to get Xtrack tasks downloaded). |
|
Send message Joined: 5 Apr 25 Posts: 51 Credit: 824,170 RAC: 22,683
|
Yes, limiting to 1-8 works, but on computers with 16-32-64 etc. threads you have to go unlimited. Xtrack is single-thread for now. There are no new tasks being released right now and resends probably get snatched very quickly because of the abovementioned issues.
|
|
Send message Joined: 18 Dec 15 Posts: 1906 Credit: 144,143,639 RAC: 73,952
|
Yes, limiting to 1-8 works, but on computers with 16-32-64 etc. threads you have to go unlimited. Xtrack is single-thread for now.thanks for the information. Final question: is Xtrack a VM project, or not (like Sixtrack before)? |
 Yeti Send message Joined: 2 Sep 04 Posts: 468 Credit: 214,499,743 RAC: 41,899 |
No VM, No Docker, No Podman, just like Sixtrack before  Supporting BOINC, a great concept ! |
|
Send message Joined: 12 Oct 17 Posts: 2 Credit: 280,959 RAC: 1,734 
|
Yes, limiting to 1-8 works, but on computers with 16-32-64 etc. threads you have to go unlimited. Xtrack is single-thread for now. Yes en NO The unlimited setting is correct for the higher thread numbers but number of downloads is also a factor of the buffer size settings. The people that get hunderds of downloads must have the buffer setting very high witch I think is a bit selfish |
|
Send message Joined: 23 Nov 05 Posts: 13 Credit: 1,889,109 RAC: 5,644
|
Yes, limiting to 1-8 works, but on computers with 16-32-64 etc. threads you have to go unlimited. Xtrack is single-thread for now. I don't think it was intentional or ego-driven on the part of individual volunteers. For example, my 9950X has a floating point performance of 11.23 GFlOPS. For all WUs delivered so far, the estimated computing effort is 500 GFLOPS. 500/11.23 = 44.5 sec each WUs. Now consider the machine's threats and setting of only one day for the buffer. With 32 threats, for example, you get 61,400 WUs that a computer could crunch in a single day. That is why some have ended up with such a high number of Wus on their machines. |
|
Send message Joined: 5 Apr 25 Posts: 51 Credit: 824,170 RAC: 22,683
|
Yes, limiting to 1-8 works, but on computers with 16-32-64 etc. threads you have to go unlimited. Xtrack is single-thread for now. Actually, we're getting hundreds of tasks with a buffer of 0,05 days (is this considered very high?) because BOINC estimates 1-2 minutes of runtime. It's pretty difficult to set your buffer when actual runtimes are 2 orders of magnitude higher that what BOINC estimates...
|
|
Send message Joined: 29 Oct 17 Posts: 5 Credit: 293,835,272 RAC: 1,038,445 
|
What happens if "<fetch_minimal_work>1</fetch_minimal_work>" is set in cc_config.xml? |
|
Send message Joined: 2 May 07 Posts: 2276 Credit: 177,520,691 RAC: 78,673
|
Win11pro - max work is 50 when setting unlimited on 64-Core Threadripper pro. |
|
jay Send message Joined: 10 Aug 07 Posts: 60 Credit: 835,538 RAC: 172
|
Greetings!! with an old laptop (1.9 GHz Intel), I got my first Xtrack WU , (Yay) So far, 3 have completed A) 2 hours 18 minutes B) 2 hours 54 minutes and C) 2 hours 54 minutes and a bit. These times are faster than the estimated 15 hour remaining time.time. 5 other WU are still processing and 1 has not started yet. So, I am content. jay |
|
Send message Joined: 26 Oct 18 Posts: 109 Credit: 5,035,218 RAC: 41,430
|
Users seem to be quite interested in these xtrack tasks. Nice to crunch these are. Computers : Registered in past 24 hours : 1457 https://lhcathome.cern.ch/lhcathome/server_status.php |
|
Send message Joined: 27 Sep 08 Posts: 877 Credit: 743,597,893 RAC: 274,926  |
I have 0.1 day queue and unlimited: 1. 23 2. 68 3. 442 4. 316 5. 249 6. 719 So my 9950X has the bigst queue I think the job que is based on the expected run time, FLOPS estimate and the buffer/queue settings. I did about 2000 tasks since we started |
©2025 CERN