On 05/12/2008 03:16 PM, Oliver Endriss wrote: > 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 > Will the behaviour of femon change, and if so, in what way? I use it now to see at what points in time I've had hickups by writing femon's output to a file and grep -nv "unc 0". This way I can see for example I've had errors at 16:35 and 17:48. If this will still work after the patch, I'm fine with it. If it won't work, will there be an alternative? P. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
