Request - Proposal to report progress in BOINC

[Jacob Klein]

RNA World devs:

I understand that the CMSearch model is not deterministic, and I understand (from reading other posts) that the forecast it yields is highly inaccurate. But seeing tasks at 100% constantly, or at 98.765% constantly, leads people to believe it is stuck. Also a proposal to have it flicker between 2 values could be confused with the user thinking the task is stuck, constantly restarting.

I'd like to make a new proposal:

The "%" can be set to any number within a 0.000% to 100.000% scale. That's 100,000 data points.
Let's say the average long monster is 1,500 hours (I looked at the Monster Hunter list to get a feel for that value).
1,500 hours is 5,400,000 seconds.
So, let's "increase the % value" by 0.001%, every (5,400,000 / 100,000) seconds. That's every 54 seconds.
To make it even more "rounded", you could increase it every minute instead.

I understand you think this is trivial, but users are used to having a sense of "progress being made" when running tasks from various projects, and your tasks should follow suit, that way the user doesn't cancel/abort/giveup in confusion. I think it could help the project, since the users will have a sense of "wow this is taking a long time, but it's still going, I can see it progressing, so I'll cheer it on!"

What do you think about increasing the % exactly 0.001% every 60 seconds?
Also maybe cap it at 99.999%, just in case the user gets a super-monster.

Thanks for your consideration,
Jacob Klein

[ChristianB]

Hi Jacob,

the current goal of the progress bar was to show the most accurate progress (based on the forecast). For the majority of tasks the forecast works great and runtimes are around 4 hours. Only the XXL ones have this problem. At the moment we only have XXL left so we could easily implement your proposal (which is a great Idea) but in the future when new tasks are generated and we can't really say what are XXL and what not, this would mean that for shorter tasks the indicator would jump from 0.240% to 100%

What do you think users would say to this?

The current batch of VM tasks has a bug that lets them jump to 98.765% right from the beginning but I already fixed it so it gets more accurate. I may also add a safety margin to the forecast value that would "smooth" the progress indicator and would be generic (for short and longer ones).

What`s your opinion about this?

Regards
Christian

[Michael H.W. Weber]

First let's check out the results of the fix.

Michael.

[Jacob Klein]

I like the idea of using the forecast as a baseline (I thought it was completely worthless, guess I'm wrong)... and I especially like the idea of a safety margin too.
Basically, the % needs to increase periodically, and should never get stagnant, especially at 100%. In fact, it should never say 100%, unless the task is completely done.

I look forward to seeing the next batch of VMs where the "immediate 98.765%" bug is fixed.
But I'm trying to complete my first RNA World VM, and am taking care not to mess it up (It's at 130 hours, and VM snapshot resuming is working well.), so it may be a while until I can see your fix.

Off-topic note:
You may be interested in the VirtualBox troubles we are seeing with Test4Theory.
Have a look here:
http://lhcathome2.cern.ch/test4theory/f ... 5560#15560
Basically, due to various VirtualBox bugs, the T4T recommendation is to stick with 4.2.16, and avoid 4.2.18, 4.3.0, 4.3.2. I have not tested the bugs against RNA World VMs. And, as the post after that indicates, I have a 4.3.2 RNA World snapshot that cannot be loaded into 4.2.16, so... I have now set T4T for No New Tasks until Oracle can figure out Ticket 12291. Fun.
Luckily, in all my testing, I didn't (yet) kill the RNA World task

Regards,
Jacob

[ChristianB]

We also saw the problems with 4.2.18 during the first beta test. I than put a "restraining order" on the server that rejects VirtualBox newer than 4.2.16 (for sending out new work). I don't know what VirtualBox settings are used by T4T but we only use the shared directory and 4GB memory option. Everything else (like the vboxwrapper) should be the same. The first succesfull result is in now and I'm going to look at the result files and see if they are useful.

[Jacob Klein]

I've done additional research in that T4T thread, to conclude that the VirtualBox 4.3.2 PATM VERR_SSM_LOADED_TOO_MUCH error occurs when the VM is set to NOT use "Enable VT-x/AMD-V", and a snapshot is taken, and an attempt is made to restore that snapshot. But, because RNA World VM tasks DO have that option checked, then I believe RNA World is immune from that particular VirtualBox 4.3.2 error.

I'm supplied additional information in the following places:
http://lhcathome2.cern.ch/test4theory/f ... 5567#15567
https://www.virtualbox.org/ticket/12291#comment:4

Thanks,
Jacob

[ChristianB]

I've gone ahead and implemented your proposal into the latest control script and for now adding 25% safety margin if the estimated runtime is above 250h. This still leads to the Client going into high priority mode because it tries to reach the deadline. This is a BOINC feature/bug that we have to live with at the moment.

[Jacob Klein]

That's great news! Could you please elaborate further (in more detail) on how progress will be displayed using your new control script?

I'm still processing that task from before, I'm now at 210 hours (~9 days), and the estimated runtime on a reference system is 8w 4d (61 days) [Is that accurate at all?]
So... It might be a good while before I can get a new task :/