On Sun, 2008-05-11 at 02:16 +0400, Manu Abraham wrote: > Andy Walls wrote: > > 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. > > There is different terminology involved: > > BER: implies a rate which is averaged over a period of time. This > implies the errors in the stream, not after FEC. Yes. I used the term too loosely in my example. Thank you for the clarification/correction. > UNC: Uncorrected symbols over a lifetime, well this is not practically > possible and will wrap around. This is not related to time, but it is > just a measure of the symbols that wasn't been able by the FEC engine to > correct. Right. But maybe a Symbol Error (or Erasure) Rate provides more useful information than just a count, no? An error rate computed over a "short" interval can be used to detect a period of communications interruption within software to alert the user or to take corrective action. Absolute counts aren't useful for assessing the current "health" of the system. > Generally a meaningless term, in many cases except a few. I agree. > Absolute errors are used very scantily, but have been used to see how > good/bad the whole system is. Except for in safety critical systems (fire suppression system, automobile brakes, etc.), how can a "good/bad" determination based on an error count be separated from a time interval over which that error count occurred? > BER cannot define this, as it is defined > before the FEC. Sometimes what's defined in the BER, the FEC engine > might be able to correct and hence. Right BER doesn't define performance of a system, just a constraint under which the system is expected to work. So we can call what I suggested Uncorrected Symbol Rate, or Symbol Error Rate, or Message Error Rate if the FEC covers more than 1 symbol - whatever makes the most sense. My opinion is that reporting of rate is more useful than absolute counts. Regards, Andy > > Regards, > Manu > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
