Jack.HarrisVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 24 Apr 07
Posts: 499
Credit: 636,587
RAC: 564
- best crunching day posted in MM history: boincstats
- almost 3 TFlops of crunching power
- almost 1k users and 3k+ computers with recent credit
- zombie67, laurenu2 and Ralfy all join the 1M total credit club
- L'Alliance Francophone crunching strong and in the lead with 163k RAC.
- WOW -- Jack
____________
MindModeling@Home is fun
/ 
Reply
Quote
Thanks for your update !
But let's try to bring even more computing power than 3Tflops.
Go go go !!
/ Reply
Quote
Yes !!!!!!!! Gooooooooooooo ^^
/ Reply
Quote
I see that the number of queed jobs per core has been increased to 4 today ... great idea :)
/ Reply
Quote
Jack.HarrisVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 24 Apr 07
Posts: 499
Credit: 636,587
RAC: 564
Can't take the credit -- tempo suggested it to me in a PM
:)
Cheers,
Jack
____________
MindModeling@Home is fun
/ Reply
Quote
I think the progress bar for the Native Python 2.7 WUs is a bit messed up : is rises to 66% within a few seconds, then it sits there for 30 minutes until the WU ends.
Remaing time estimate is also crazy because of this. :(
/ Reply
Quote
Jack.HarrisVolunteer moderator
Project administrator
Project developer
Project scientist
Send message
Joined: 24 Apr 07
Posts: 499
Credit: 636,587
RAC: 564
We are running n simulations per WU. Therefore after each simulation the percent moves up 1/n%. Unfortunately, this is only a good heuristic when each simulation has nearly equal runtime.
The particular model that is using python right now has a lot of time variability between different simulations. This will not be for all jobs using the Python 2.7 app.
Sorry for the lack of fidelity in the percent done estimation.
Jack
____________
MindModeling@Home is fun
/ Reply
Quote
It does not matter, Jack. Everything may not be perfect. You and your team are doing a remarkable job on MM, thank you for your availability, your quick and helpful responses.
Members of the Alliance hope the current action will allow you to accommodate more users in the future.
Ousermaatre
/ Reply
Quote
TomVolunteer moderator
Project administrator
Project developer
Send message
Joined: 23 Jun 08
Posts: 311
Credit: 105,388
RAC: 0
Our BOINC wrapper and Python application communicate progress via a common file, mm_fraction_done.txt. Upon closer inspection this morning, we discovered that the Python application had a typo and was writing progress to the wrong file (mm_fractiondone.txt).
Furthermore, the BOINC wrapper has three main processes it runs: (1) unzip python, (2) unzip model files, and (3) run simulations. The reason you've noticed it jump from 0 to 33% to 66% is because the application completed the first two tasks, but didn't progress from there due to the bug I mentioned above. This is now fixed for all future workunits we create, but not the ones already queued up. When you get the fix, you will see progress jump from 0% to 33% to 66% and then back to 0% fairly quickly. From that point on you will see progress move steadily and predictably at a rate of 1/(# of simulations), as Jack mentioned.
At some point, we'll update the BOINC wrapper so the initial unzipping tasks don't interfere with the progress bar so drastically. For CCL (Lisp) applications, on the other hand, the unzipping occurs within the Lisp code instead of the BOINC wrapper, so the zipping updates don't affect progress. Also, the CCL app had the correct filename for progress communication, so that is why that application was behaving correctly and the Python one wasn't.
/ Reply
Quote