alexxcons
commented
2 years ago Maybe a better way (out of this PR) would be to set some kind of flag/tag on the data whenever this happens, so the correlation between missing data and thes slow poll loop iterations can be investigated without spamming the log system?
in any case, logging in a real-time thread/handler is a bad idea, since the logging affects it's performance in the first place ... we should replace text-based logging in hot-paths entirely and maybe (maybe) replace it with a proper metrics logger (<-> logged via prometheus) and server-local diagnostics property.
I agree with you, logging does not make much sense here / generally in code which possibly is called within high rate. I opened an issue to fix it in a general way: https://github.com/fair-acc/gr-digitizers/issues/102
I was to quick with adding that warning in #92. The warning was printed alot on different servers, filling up our graylog with nonsense messages.
I tried to increase the poll duration to get rid of the warning. Though for some frontends, as soon as no warning was displayed, the number of received samples per time on the FESA side did not match the expectations any more (in some cases as well lost buffers were observed).
So I suppose it is normal / can be expected that ocasionally no waiting needs to be done, and it should not lead to a warning.