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

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em Thu, 17 Jan 2013 19:15:22 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> 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. 

UCB is just DTV_QOS_ERROR_BLOCK_COUNT. 

PER is DTV_QOS_ERROR_BLOCK_COUNT / DTV_QOS_TOTAL_BLOCKS_COUNT

Not all frontends will of course provide PER.

> 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.

Hmm... good point.

Let's see when those counters would overflow with u64 (please correct
if I did any wrong calculus on bc).

We have:
	2^64 = 18,446,744,073,709,551,616

Assuming a bit rate of 54 Mbps, we have:
	bits_per_sec = (54*1024*1024*1024)
	bits_per_sec = 57,982,058,496

In this case, the bit error count will overflow in:
	time_to_overflow = 2^64 seconds / bits_per_sec =
			 = 18,446,744,073,709,551,616 / 57,982,058,496
		         = 318,145,725 seconds
So,
	time_to_overflow is more than 3682 days and more than 10 years

DTV_QOS_TOTAL_BLOCKS_COUNT increments slower than DTV_QOS_TOTAL_BITS_COUNT
(204 * 8 times slower).

So, it would take 318,145,725 * 204 * 8 seconds (or 6,009,419 days) to
overflow).

IMHO, except for professional applications that would be continuously
running for more than 10 years , there's no need to be
careful about overflows.

That said, I still think that the counters should be reset when
a new channel is tuned (e. g. when set_frontend is called from
userspace) or when the user requests for a counters reset, as the 
statistics from one channel/transponder are different than the ones
for other channels/transponders.

Mauro