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
>