On Sat, 2008-05-10 at 17:27 +0200, Oliver Endriss wrote: > Oliver Endriss wrote: > > e9hack wrote: > > > the uncorrected block count is reset on a read request for the tda10021 and stv0297. This > > > makes the UNC value of the femon plugin useless. > > > > Why? It does not make sense to accumulate the errors forever, i.e. > > nobody wants to know what happened last year... > > > > Afaics it is ok to reset the counter after reading it. > > All drivers should behave this way. > > > > If the femon plugin requires something else it might store the values > > and process them as desired. > > > > Afaics the femon command line tool has no problems with that. > > Argh, I just checked the API 1.0.0. spec: > | FE READ UNCORRECTED BLOCKS > | This ioctl call returns the number of uncorrected blocks detected by the device > | driver during its lifetime. For meaningful measurements, the increment > | in block count during a speci c time interval should be calculated. For this > | command, read-only access to the device is suf cient. > | Note that the counter will wrap to zero after its maximum count has been > | reached > > So it seens you are right and the drivers should accumulate the errors > forever. Any opinions? For communications systems, whether its is two-way or one-way broadcast, most people are concerned with the error *rate* (errors per unit time) rather than absolute error counts. Communications engineers have a good understanding of what it means to have a 10^-2 BER vs 10^-12 BER, and adjust their expectations accordingly. Absolute counts have less meaning to engineers, and I'm not sure what a layman would make of them. I'd suggest whatever error counts you store have a start time and starting value (i.e. 0) associated with them, so when you look at the accumulated value at present you can determine the average error rate. When should the error counter and start time be reset? On channel (frequency) change is a convenient and make sense to me. When the counter overflows is obviously another time. When the time reaches a certain number of seconds? Maybe implement a moving average (sliding window) to better report the current instantaneous error rate. Regards, Andy > CU > Oliver > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
