Message boards :
Xtrack/SixTrack :
Xtrack (Xboinc)
Message board moderation
Previous · 1 . . . 4 · 5 · 6 · 7 · 8 · 9 · 10 . . . 11 · Next
Author | Message |
---|---|
Send message Joined: 29 Oct 17 Posts: 5 Credit: 290,759,148 RAC: 885,390 ![]() ![]() ![]() |
Done 27,4k (completed and validated) now and have still some spare cycles left, but the queue is drained. ;( |
Send message Joined: 5 Apr 25 Posts: 49 Credit: 748,065 RAC: 18,560 ![]() ![]() ![]() |
but the queue is drained. ;( Says the guy draining the queue :)) Cheers mate! I'm at 378 validated and 399 in progress. Hopefully there will be new batches released before I finish what's left. ![]() |
Send message Joined: 10 Jul 25 Posts: 5 Credit: 140,594 RAC: 4,492 |
Apologies! You are all digesting jobs beyond my wildest expectations :D There's (way) more where it came from. Releasing some of them now! In parallel, we have just released a new executable version (0.5) on the development server, where we should have fixed the progress bar and the misprint in stderr at the end of the job! I should be able to push some hundred of sample jobs on dev 0.5 before going to sleep (but most likely I'll do a proper batch tomorrow morning). If any of you happens to take those jobs under Xtrack 0.5, please let us know if you see a reasonable progress bar! It should be slow at first (all particles still alive) and then become gradually faster towards 100% (particles are getting lost, and it is faster to do an LHC turn). Thank you for the strong enthusiasm and for crunching our jobs at this rhythm! If you have any feedback on how the project feels/works or on how you would prefer having it configured, please do let us know. Cheers, Carlo |
![]() ![]() Send message Joined: 24 Oct 04 Posts: 1234 Credit: 79,244,876 RAC: 136,130 ![]() ![]() |
Thanks for a new batch seconds after reading this Carlo |
Send message Joined: 22 Mar 17 Posts: 75 Credit: 27,106,535 RAC: 92,204 ![]() ![]() |
Users seem to be quite interested in these xtrack tasks. Nice to crunch these are. Users always come out of the woodworks for non-VB tasks at LHC. Same thing for SixTrack when it had work. |
Send message Joined: 5 Apr 25 Posts: 49 Credit: 748,065 RAC: 18,560 ![]() ![]() ![]() |
In parallel, we have just released a new executable version (0.5) on the development server, where we should have fixed the progress bar and the misprint in stderr at the end of the job! Excellent news! Standing by to snatch the new tasks when you release them. Thank you for the strong enthusiasm and for crunching our jobs at this rhythm! If you have any feedback on how the project feels/works or on how you would prefer having it configured, please do let us know. Will do. I may not contribute much computing power, but I try to compensate with feedback. See my previous post about some scans having realistic runtime estimates while most don't. Just picked up some "start of collapse flat pos oct" tasks and two that are simply "start of collapse flat". They all show 2h12m estimated runtimes before starting on this rig. Will take a while to get to them, there are still several hours worth of "start of collapse round pos oct" tasks from earlier that have 1m50s estimates but run 4-8+ hours (with one exception from scan #147 that also shows 2h12m). ![]() |
Send message Joined: 18 Dec 15 Posts: 1904 Credit: 144,073,803 RAC: 79,749 ![]() ![]() ![]() |
Apologies! You are all digesting jobs beyond my wildest expectations :D I am running LHC VB tasks on quite a number of machines; and I have one very old PC with a 2-core CPU not supporting virtualization, on which before I ran SixTrack. So I am happy now that with XTrack there is again good use for this old PC :-) |
Send message Joined: 10 Jul 25 Posts: 5 Credit: 140,594 RAC: 4,492 |
Dear volunteers, As promised, the queue of jobs for Xtrack jobs is now a bit populated, and 100 test jobs under version 0.5 have been pushed on the Dev server! If you happen to be one of the lucky volunteers who catches one of these new jobs, please do let us know if you observe a reasonable behaviour with the progress bar. Thank you for your warm and enthusiastic support and, especially, for crunching our tracking jobs :) See you soon (with even more jobs), Carlo |
![]() ![]() Send message Joined: 2 Sep 04 Posts: 468 Credit: 214,302,533 RAC: 28,275 ![]() ![]() |
I have downloaded several jobs of 0.05 on different machines. When they were downloaded the WUs showed a RemainingTime of 80 seconds A few minutes after start the RemainingTime jumps up to something between 4 and 9 hours, the progressbar ist growing slowly. As far as it can be judged after 15 minutes runtime all looks good. Yeti ![]() Supporting BOINC, a great concept ! |
Send message Joined: 10 Jul 25 Posts: 5 Credit: 140,594 RAC: 4,492 |
Dear Yeti, That's amazing news! Thank you for the immediate feedback. I did not provide a tailored time estimate for these jobs, so I imagine the BOINC server assigned a project default value. However, the client should now be able to re-evaluate the time estimate on the fly, given the fraction done. You should then observe the progress bar going faster after 5-10% (corresponding to 50k-100k turns out of 1M), because at that point you will have lost most of the particles to be tracked. If everything checks out up to job completion, feel free to cancel the remaining jobs from the dev project. Thanks again! Carlo |
Send message Joined: 16 Sep 25 Posts: 3 Credit: 379,522 RAC: 17,909 ![]() ![]() ![]() |
GPU apps were mentioned earlier in the thread (CUDA/OpeCL). ETA on that? I'm highly interested in a CUDA app for Linux. I know you mentioned trying to compile an executable, but you could also just send over the whole python environment via a compressed archive, then execute it with the BOINC wrapper + some scripts. that's how GPUGRID does it for most of their apps. if you do instead focus on trying to compile an executable, I would highly recommend you use something like CUDA 12.8 or 12.9. compile SASS code for all the supported architectures (CUDA 12.9 supports cc 5.0-12.0, which is Maxwell all the way to Blackwell) and also include PTX code so support future archs that have not been released yet. you can usually do all this with an NVCCFLAG argument like -arch=all if you dont want to define them individually. CUDA 13 is the latest, but will cut off support for devices from cc 5.0-7.0 (Maxwell/Pascal/Volta), so using CUDA 12.8 or 12.9 actually has broader support |
Send message Joined: 6 Sep 08 Posts: 119 Credit: 14,184,728 RAC: 7,769 ![]() ![]() ![]() |
After the first few 0.5 tasks, which are running exactly as expected, a minimum BOINC version appears to have been set for these. Is this so? |
Send message Joined: 5 Apr 25 Posts: 49 Credit: 748,065 RAC: 18,560 ![]() ![]() ![]() |
After the first few 0.5 tasks, which are running exactly as expected, a minimum BOINC version appears to have been set for these. Is this so? I saw this message last night, well before the actual release of tasks (of which I didn't get any). It is probably related to v0.05 either way. ![]() |
Send message Joined: 2 May 07 Posts: 2276 Credit: 177,251,865 RAC: 63,797 ![]() ![]() |
GPU apps were mentioned earlier in the thread (CUDA/OpeCL). XTrack running now a few days. Cern-IT knowing the next steps for this project. |
![]() ![]() Send message Joined: 2 Sep 04 Posts: 468 Credit: 214,302,533 RAC: 28,275 ![]() ![]() |
Carlo, please, ,could you check your work-generator ? I just got a bunch of WUs that will run with 0.41, but have an estimated runtime of 57 seconds ! With these 57 seconds the machine got hundreds of WUs it never will be able to finish before deadline. The WUs seem to got generated today in the morming Example 1: https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=235324667 Example 2: https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=235324296 By the way: The Queue-settings are 0.01 days and 0.2 days. Thanks Yeti ![]() Supporting BOINC, a great concept ! |
Send message Joined: 2 May 07 Posts: 2276 Credit: 177,251,865 RAC: 63,797 ![]() ![]() |
With unlimited and one CPU without days parameter, get a max. of 50 Tasks for XTrack. |
![]() ![]() Send message Joined: 2 Sep 04 Posts: 468 Credit: 214,302,533 RAC: 28,275 ![]() ![]() |
With unlimited and one CPU without days parameter,This would even be way to much. The Box needs up to 4 hours per WU, 4 h a 50 WUs = 200 hours = 8,3 days. Too much for a 7 day deadline And I don't like having so much in the queue if we don't have a race ![]() Supporting BOINC, a great concept ! |
![]() ![]() Send message Joined: 2 Sep 04 Posts: 468 Credit: 214,302,533 RAC: 28,275 ![]() ![]() |
You should then observe the progress bar going faster after 5-10% (corresponding to 50k-100k turns out of 1M), because at that point you will have lost most of the particles to be tracked.HM, my 7900X has already finished the WUs in round about 3 hours and 15 minutes My 5900X need something with 7 hours for these Test-WUs, the load of all boxes should be nearly equal (1 CPDN-MultiCoreWU, 4x XTrack LHC, 4x XTrack DEV-LHC) Is this dramatic Time-Difference something you would expect ? Yeti ![]() Supporting BOINC, a great concept ! |
Send message Joined: 2 May 07 Posts: 2276 Credit: 177,251,865 RAC: 63,797 ![]() ![]() |
And I don't like having so much in the queue if we don't have a race Won't also doing a race. This 50 Tasks running on a 64-Core Threadripper (4-6 hours for one Task). |
![]() Send message Joined: 7 Aug 11 Posts: 118 Credit: 28,644,324 RAC: 40,615 ![]() ![]() ![]() |
Something I just noticed, might be something, might be nothing. I'm running these on three machines. All three have the <no_alt_platform> flag set and should ONLY get x86_64 work. All three report they are running 64bit OSs and get x86_64 work from other projects. All three are running 64bit Linux, one Mint Desktop (Boinc client 8.1.0 x64), the other two Ubuntu Server (Boinc client 8.1.0 x64). The Mint desktop gets x86_64 units. The others only get i686 Xtrack units. The two that are set up to run Atlas both get x86_64 Atlas Native units. I shut down the boinc client, copied the x86_64 application from the desktop to the two server machines, removed the i686 application, and restarted the systems. It errored all of the cached work. This was not unexpected. What WAS unexpected was those systems, ignoring the x86_64 directive and application, re-downloading the i686 application, and only getting i686 work. Is there something in particular these are looking for to determine the system arch? |
©2025 CERN