Execution Time for RESTR Block in Harmony
We would like to calculate the module execution times in DBDOC. Unfortunately, the documentation for FC 140 RESTR block indicates only the range of minimum to maximum times:
- 25.93 to 1,600.38 μsec for SPC700, HC800
- 62 to 2,571 μsec for Harmony Area Controller (HAC)
- 108 to 4,500 μsec for Harmony Bridge Controller (BRC-300/400/410 and HPG800)
- 123 to 5,141 μsec for Harmony Bridge Controller (BRC-100/200)
- 635 to 30,650 μsec for the oldest Multi-Function Processors (IMMFP11/12)
Composer and WinCAD both calculate based on the largest value, yielding useless results for understanding the CPU loading. We would make good use of the exact times on a function code by function code basis to give users a more correct calculation of the execution time for each segment.
Answers
This question has not yet been answered.
by Alan Rank: 13 on 4/6/2017 6:23:24 AM | Like (0) | Report
Hi Geoff,
Yes, the calculation of a meaningful execution time for a configuration with RESTR blocks has been a longstanding wish for many I think, but is also complicated by..
a.) Maximum number of NVRAM writes per second. Prior to BRC revision L there is a published limit of 20 NVRAM writes per second which could be easily exceeded if the RESTR save flag was not gated. The most common symptom of exceeding this rate was the redundant controller cyclically dropping from hot to warm standby. Revision L0 lifted this to 80 NVRAM writes per second but it is still possible to drop the redundant controller if there are sustained NVRAM write rates. Not sure if there have been any enhancements since revision L0 or what the HPC/SD700 support. So, even if the cycle time calculation is reasonably accurate the configuration itself may not work correctly in real world conditions.
b.) The RESTR save flag/save permissive. If the save flag/save permissive inputs are gated through logic the calculation of the individual RESTR block execution time becomes difficult as the RESTR function is longer occurring at the same period as the segment cycle time. Whilst this gives the potential for hundreds of restore blocks in a configuration without exceeding NVRAM write limits discussed above or execution time overruns, it also makes calculating a realistic execution time difficult offline unless you can determine the gating logic operation programmatically.
I haven't seen a document that provides the information you are looking for, however in the past I have used the worst case data from Appendix A data of the FC manual, converted this to a us/byte factor and then applied this factor to each instance of restore block and the number of bytes being written.
For instance for an MFP01/02
1062 bytes takes 30650us = 29us/byte
46 bytes take 635us = 14us/byte
Even just using the worst case of 29us/byte for every byte written by the RESTR block instead of the flat 30650us per RESTR instance improves the estimation of the cycle time markedly. The bytes Vs execution time relationship is not linear but with a with some empirical data using the most common function code NVRAM sizes a lookup table could be created.
Good luck,
Alan
by Geoff Michaels Rank: 356 on 4/6/2017 6:59:23 AM | Like (0) | Report
Thanks, Alan.
First, if no better information comes along, your approximation will allow us to do a better job with the estimation. Also, since we take the hardware into account, we can work the NVRAM writes into it.
When we started looking at NVRAM, we began by flagging blocks that are being written every cycle. This led us to blocks that never get saved, an even more severe problem. One site had over 200 out of 900 such blocks.
DBDOC will continue to add error checking for the numerous errors that Composer fails to find. Thanks, again.
Add new comment