Re: [PATCH RFCv10 00/15] DVB QoS statistics API

[Antti Palosaari <crope@iki.fi>]

On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Jan 2013 11:33:46 +0200
> Antti Palosaari <crope@iki.fi> escreveu:
>
>> What goes to these units in general, dB conversion is done by the driver
>> about always. It is quite hard or even impossible to find out that
>> formula unless you has adjustable test signal generator.
>>
>> Also we could not offer always dBm as signal strength. This comes to
>> fact that only recent silicon RF-tuners are able to provide RF strength.
>> More traditionally that estimation is done by demod from IF/RF AGC,
>> which leads very, very, rough estimation.
>>
>> So at least for the signal strength it is impossible to require dBm. dB
>> for SNR is possible, but it is very hard due to lack of developers
>> knowledge and test equipment. SNR could be still forced to look like it
>> is in given dB scale. I think it is not big loss even though SNR values
>> reported are a little bit wrong.
>>
>>
>> About half year ago I looked how SNR was measured every demod we has:
>>
>> http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt
>>
>> as we can see there is currently only two style used:
>> 1) 0.1 dB (very common in new drivers)
>> 2) unknown (== mostly just raw register values)
>
> It could make sense to have an FE_SCALE_UNKNOWN for those drivers, if
> they can't converted into any of the supported scales.
>
> Btw, as agreed, on v11:
> 	- dB scale changed to 0.001 dB (not sure if this will bring much
> gain, as I doubt that demods have that much precision);
> 	- removed QoS nomenclature (I hope I didn't forget it left on
> 	  some patch);
> 	- removed DTV_QOS_ENUM;
> 	- counters reset logic is now driver-specific (currently, resetting
> 	  it at set_frontend callback on mb8620s);
>
> I'll be posting the patches after finishing the tests.
>
> What's left (probably we need more discussions):
>
> a) a flag to indicate a counter reset (my suggestion).
>
> Does it make sense? If so, where should it be? At fe_status_t?
>
> b) per-stats/per-dvb-property error indicator (Devin's suggestion).
>
> I don't think it is needed for statistics. Yet, it may be interesting for
> the other dvb properties.
>
> So, IMHO, I would do add it like:
>
> struct dtv_property {
>          __u32 cmd;
> 	__s32 error;		/* Linux error code when set/get this specific property */
>          __u32 reserved[2];
>          union {
>                  __u32 data;
>                  struct dtv_fe_stats st;
>                  struct {
>                          __u8 data[32];
>                          __u32 len;
>                          __u32 reserved1[3];
>                          void *reserved2;
>                 	} buffer;
>          } u;
>          int result;
> } __attribute__ ((packed));
>
> A patch adding this for statistics should be easy, as there's just one
> driver currently implementing it. Making the core and drivers handle
> per-property errors can be trickier and will require more work.
>
> But I'm still in doubt if it does make sense for stats.
>
> Devin?
>
> Cheers,
> Mauro
>

There is one issue what I now still think.

dvb_prop[2].cmd = DTV_QOS_BIT_ERROR_COUNT;
dvb_prop[3].cmd = DTV_QOS_TOTAL_BITS_COUNT;
dvb_prop[4].cmd = DTV_QOS_ERROR_BLOCK_COUNT;
dvb_prop[5].cmd = DTV_QOS_TOTAL_BLOCKS_COUNT;

For me this looks like uncorrected errors are reported as a rate too (as 
both error count and total count are reported to app). But that is not 
suitable for reporting uncorrected blocks! It fits fine for BER, but not 
UCB. If UCB counter is running that fast then picture is totally broken. 
Behavior of UCB should remain quite same as it is currently, increases 
slowly over the time. If you start resetting counters as for BER then 
UCB is almost all the time 0. User wants to know UCB errors in frame of 
days rather than minutes.


regards
Antti

-- 
http://palosaari.fi/