On 01/17/2013 08:11 PM, Mauro Carvalho Chehab wrote:
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).
It will not overflow, as you maybe remember I calculated few days back
that u32 will overflow BER counter in 10 seconds in very special case
where I used 32MHz BW (DVB-C2) and quite optimal (14bit? SNR very big)
samples from Shannon. If BER will not overflow then no need to care
about uncorrected blocks as those are much more smaller than BER total bits.
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.
Resetting counters when user tunes channel sounds the only correct option.
OK, maybe we will see in near future if that works well or not. I think
that for calculating of PER it is required to start continuous polling
to keep up total block counters. Maybe updating UCB counter continously
needs that too, so it should work.
regards
Antti
--
http://palosaari.fi/
--
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
