@mreiter is correct: MpDataRegPar is used only for registration, once that is done, this FUB basically does nothing.
As to the performance topic (that’s a bit of a longer story):
MpData was never really meant for fast recording without tolerance. That is mainly because MpData stores the recorded values into a buffer (NOT a FIFO, at least not in the traditional sense). Once the buffer is full, it is transferred to a file (that is done to avoid killing the data storage with too many write requests). And here’s the problem… As long as the buffer is full, no new data can be recorded, until the information that is currently inside the buffer was removed from it.
Now, as you realised, that’s usually not a problem if you either have long task classes or tolerances, but for, let’s call them “time-critical tasks”, that creates a problem. The bigger the buffer, the more data has to be moved, first into RAM (which is usually the part triggering the violation, because it has to be done before recording the new values), then afterwards into the actual file (already done in IDLE up to my knowledge).
Unfortunately I cannot give concrete advise, but I have heard of some projects, where tinkering with the buffer size resolved such issues. However, there is no guarantee that works, the only reliable solution is to use a higher TC with tolerance (e.g. 10ms TC#8 +100ms tolerance).
Out of curiosity:
- How much data are you recording (number of PVs, datatypes are pretty much irrelevant)?
- How often are you recording (e.g. time-based 10ms, value change, custom trigger) and what is your task class time?
- How big did you configure your buffer and file size (+ file type)?
- Which “Save interval” did you configure?
PS: Regarding your thought of using a FIFO. That would most likely run into a situation that MpData does not have (or is solving)… What if the buffer (FIFO) is full, but there is no time (yet) to process the data? Are you then overwriting the oldest value, effectively losing it, or are you going to just not store anything new (also losing data) until it was processed, or do you make your FIFO bigger than it needs to be so that such situations are accounted for (technically wasting memory). MpData is trying to solve this by grabbing the buffer contents back into RAM when it is full (which unfortunately requires more time, especially for bigger buffer sizes) and then triggering a background save operation on this data, allowing new values to be recorded and stored into the buffer immediately.
PPS: I’m not saying that MpData is perfect, it was just one of the first components of mapp Services (or “mapp” as it was called back then), and it has never been extended/reworked to a more modern version. Hence I would love to hear feedback how it is used, because that makes it easier for us to plan ahead (we don’t hear a lot of complaints or feedback regarding this component).
And regarding the limits… We need to improve our documentation. That’s something we also realised…
… I thought that at least internally we used a higher-precision datatype. OK, then ignore what I said about setting it to 