In the RTKrcv status view, there is a line titled "missing obs data count" thats been driving me up the wall — the RTKrcv instance processing observations from my local GPS receiver usually/always has 0 missing observations, whereas the instance processing observations from a remote receiver has this number up in the hundreds, indicating to the layman that observations are dropped willy nilly. (See here if you haven't been following along.)
I finally figured out what this number means. At least I think so. The number is stored in the variable called svr->prcout, which in turn is set a couple of places in rtksrv.c:
/* observation data received */
if (ret==1) {
if (fobs<MAXOBSBUF) fobs++; else svr->prcout++;
}
and
/* if cpu overload, inclement obs outage counter and break */
if ((int)(tickget()-tick)>=svr->cycle) {
svr->prcout+=fobs[0]-i-1;
#if 0 /* omitted v.2.4.1 */
break;
#endif
}
In short, the observations are registered as "missing" if either the receive buffer is overflowing, or the defined CPU time limits are exceeded. In the last case, nothing is really missing; courtesy of that "#if 0 ..." the observations are processed regardless, as far as I can work out.
Preliminary testing indicates the "analysis" is correct; I increased misc-svrcycle from 10 to 100 ms, and after 24 hours there are 0 missing observations. I speculate that the reason only the remote instance of RTKrcv has shown significant numbers of missing observations is because the remote receiver is tracking GLONASS as well, and RTKrcv spends more time decoding/processing the observations.