Em Thu, 17 Jan 2013 19:15:22 +0200 Antti Palosaari <crope@xxxxxx> escreveu: > On 01/17/2013 06:50 PM, Mauro Carvalho Chehab wrote: > > Em Thu, 17 Jan 2013 11:33:46 +0200 > > Antti Palosaari <crope@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
