Andy Walls wrote:
> On Sun, 2008-05-11 at 23:33 +0400, Manu Abraham wrote:
>
> > I am talking about standard DVB demods:
> > Every demodulator provides a standard interface, whether you know it or not.
> >
> > BER, Bit Error Rate (symbols per unit time)
> > Strength, usually a RMS value (Absolute)
> > SNR, Signal To Noise Ratio (Relative)
> > UNC, Uncorrectable symbols (Absolute)
> >
> > These parameters have meanings for the users, not just Linux users but
> > general users on the whole. Most DVB stuff is quite standardized, most
> > of which you can find in ETSI specifications and or old DVB.org whitepapers.
> >
> > All the resultant parameters that which an API provides, should be that
> > which is a standard definition, rather than defining something which is
> > bogus. You take anything standardized, you won't find any other
> > difference from the above, almost all demodulators follow the
> > specifications involved therein.
>
> Manu,
>
> I will agree with you then, drivers shouldn't compute a UNC block rate.
>
>
> Oliver,
>
> However, the original spec that was quoted, implied that *applications*
> would/could do just that: compute a rate from UNC block counts:
Applications may do whatever they wish with the UNC counter:
- provide the raw error count
- present the number of UNC blocks over a sliding window (last minute,
last hour, whatever)
- calculate an UNC rate [1]
[1] Imho not very useful. UNC should remain constant or increment very
slowly. Otherwise the ts stream will be unusable.
> > 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
>
> Putting aside whether such UNC block rates are useful or not, the
> specification as quoted facilitates the following use case:
>
> Multiple applications, can compute UNC block rates over different,
> possibly overlapping intervals of different lengths, with the
> applications required to handle rollover gracefully.
This a a very important point: The frontend may be opened by multiple
readers, so a driver _must_ _not_ reset the UNC counter after reading.
I guess that's why UNC was defined this way.
Btw, this is a common concept: SNMP (Simple Network Management Protocol)
counters behave the same way.
> The specification as is, appears to be the easiest way to support this
> use case, and it works provided the hardware automatically performs
> rollover of the UNC block counter.
>
> If this is a use case that needs to be supported, then to handle the
> case of hardware that doesn't automatically roll the UNC counter over to
> zero, the last sentence of the specification might be changed to
> something like this:
>
> "Note that the counter will wrap to zero after its maximum count has
> been reached. For devices where the hardware does not automatically
> roll over to zero, when the ioctl would return the maximum supported
> value, the driver will reset the hardware counter to zero."
>
>
> This isn't perfect as some UNC counts will be lost after the counter
> saturates, but aside from this exceptional circumstance, the use case
> would be correctly supported.
The driver should do its best to implement the API spec. It might:
- return the value of a counter provided by the hardware if it matches
the API spec
- implement a counter in software (see proposed patch for an example)
- return -ENOSYS if it cannot support the UNC counter [2]
Btw, the spec refers to an error code ENOSIGNAL, which does not exist.
:-(
[2] Unfortunately some drivers return a bogus value if they cannot
provide UNC. This is a bug and should be fixed!
Returning 0 is wrong. I'll fix the stv0299.
It is unlikely that the 32 bit UNC error count wraps. If it does, the
'UNC rate' is very high, and it does not matter whether a few errors
are lost...
Anyway the application should handle the wrapping of the UNC counter
properly.
@all:
1. If nobody objects I will commit the patches.
2. Please check and fix the other frontend drivers to follow the spec.
CU
Oliver
--
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
