Bug #1218
closedqueue time estimation does not include focusing time
0%
Description
reported by Yen-Chywan Liaw
Updated by Anchi Cheng about 13 years ago
- Status changed from Assigned to In Code Review
- Assignee changed from Anchi Cheng to Eric Hou
fix this with r15476 that also fixes #1219
The estimate still does not include the time it takes to adjust the target at the beginning so it is still likely to be an under-estimate.
Testing:
1. Running Leginon using queuing option.
2. After it becomes automated, compare the time it takes to complete a few targets to the estimate. It should be closer to reality now than before especially if acquisition/focus target ratio is low.
Updated by Eric Hou about 13 years ago
- Status changed from In Code Review to In Test
- Assignee changed from Eric Hou to Amber Herold
looks good to me. The only thing I would recommend is in queuecount.php, function printResult passing in an array variable $qresult. And if $qresult's elements name using 'word' instead of number, it would be better.
Thanks.
Eric
Updated by Amber Herold about 13 years ago
- Assignee changed from Amber Herold to Jim Pulokas
Better tested by someone who runs Leginon...Jim?
Updated by Erica Jacovetty about 13 years ago
- Assignee changed from Jim Pulokas to Erica Jacovetty
I can test this next time I queue data for collection.
Updated by Erica Jacovetty about 13 years ago
I looked at this today. For Mandy's session (11may05a) she had very regular pattern of 3 targets per hole, 1 focus per hole. I checked a couple and it was consistently very close to 2 min for the focus and 3 targets, but the queue was still estimating 23 seconds per target in the queue count and not including the focus time which would put the estimate more at ~40sec per target.
Updated by Anchi Cheng about 13 years ago
- Status changed from In Test to Closed
It is actually o.k. 36 second per target makes 3 targets per hole to be 108 sec, just 12 sec off since I didn't include target adjustment.
Updated by Anchi Cheng about 13 years ago
Talked to Erica to clarify the differences in her and my testing results.
The day when she did the test, queue counter in the development version was broken because of issue #1288 She was looking at the 2.1 release version and got 23 seconds since focusing time was not added in that estimate in the release. When I went checking on the same day, I noticed the bug and fixed it in my sandbox so that I could look at it in the develepment version, which is why my number is 36 seconds and is consistent with calculation with focusing time added.