[linux-dvb] [PATCH] Fix the unc for the frontends tda10021 and stv0297

[Andy Walls]

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
>