| home | layout | structure | qd | hexdump |
          File : queue.dat
 Queue Version : 5.01
          Size : 7168 bytes
    F@H Client : FAH502-Linux.exe

Progress Rate

2.94 X min speed
If progress and expiration time can be determined for this work unit, then the rate of progress can be calculated as a factor times the minimum speed necessary to barely make the deadline. If this number is less than 1.00, it means that if the unit continues to process at the effective rate it has gone since it was downloaded, it won't finish in time. If the machine has been running FAH exclusively 24/7, then it is hopelessly too slow. The current unit might as well be deleted, and the client should be reconfigured to process only deadlineless units. Before the V5.00 client, that was done by selecting a preference for Genome units. See the note below explaining how the fraction complete, and thus also the min speed factor, may be inaccurate before the unit is 2% done.

NOTE that with regard to these last three items, until the unit is several percent finished, the displayed values may not be very accurate. Especially with Gromacs units, where there are checkpoints and log entries made between frames, qd can't establish the calculation rate until the unit is at least 2% done. This will cause the percent complete to show only 0% or 1%, and the point/hour rate and min speed numbers to be significantly lower than their proper values. Further, with Genome units, there is quite a bit of time spent in initialization as the rotamers library is calculated. At the beginning of the unit, this time all appears to be taken by the first tenth of the first sequence, which can make the rate of progress initially appear to be as low as one half of its ultimate value. This also affects, of course, the expected completion time for the unit.