Em Tue, 15 Jan 2013 16:08:14 +0530 Manu Abraham <abraham.m...@gmail.com> escreveu:
> On Tue, Jan 15, 2013 at 8:00 AM, Mauro Carvalho Chehab > <mche...@redhat.com> wrote: > > Add DVBv5 methods to retrieve QoS statistics. > > > > Those methods allow per-layer and global statistics. > > > > Implemented 2 QoS statistics on mb86a20s, one global only > > (signal strengh), and one per layer (BER). > > > > Tested with a modified version of dvbv5-zap, that allows monitoring > > those stats. Test data follows > > > > Tested with 1-segment at layer A, and 12-segment at layer B: > > > > [ 3735.973058] i2c i2c-4: mb86a20s_layer_bitrate: layer A bitrate: 440 > > kbps; counter = 196608 (0x030000) > > [ 3735.976803] i2c i2c-4: mb86a20s_layer_bitrate: layer B bitrate: 16851 > > kbps; counter = 8257536 (0x7e0000) > > > > a) Global stats: > > > > Signal strength: > > QOS_SIGNAL_STRENGTH[0] = 4096 > > > > BER (sum of BE count and bit counts for both layers): > > QOS_BIT_ERROR_COUNT[0] = 1087865 > > QOS_TOTAL_BITS_COUNT[0] = 67043313 > > > > b) Per-layer stats: > > > > Layer A BER: > > QOS_BIT_ERROR_COUNT[1] = 236 > > QOS_TOTAL_BITS_COUNT[1] = 917490 > > > > Layer B BER: > > QOS_BIT_ERROR_COUNT[2] = 1087629 > > QOS_TOTAL_BITS_COUNT[2] = 66125823 > > > > TODO: > > - add more statistics at mb86a20s; > > - implement support for DTV_QOS_ENUM; > > - some cleanups at get_frontend logic at dvb core, to avoid > > it to be called outside the DVB thread loop. > > > > All the above changes can be done a little later during this development > > cycle, so my plan is to merge it upstream at the beginning of the > > next week, to allow others to test. > > > > > An API should be simple. This is far from simple. This API looks horribly > complex and broken, for anyone to use it in a sane way. It is not complex. See my answer to Antti with a few code snippets. > Polling from within dvb-core is not a good idea, as it can cause acquisition > failures. Continuous polling is known to cause issues. Polling from Kernel or from userspace has the same results. If a hardware is known to be broken with polling, the driver needs to handle it. With a Kernel polling, drivers can have more control, as it should not be hard to change the dvb-frontend polling time for it to be set by the driver. It could even be possible to have an interrupt-driven process to update the statistics, if the hardware supports it. > Adding counters to be controlled externally by a user is the most silliest > thing altogether. Huh? There's nothing that userspace can control. All userspace does with the API is to read values. Nothing more, nothing less. > All these things put together, makes it the most inconvenient thing to be > used. > Eventually, it results in more broken applications than existing. > > Not to forget that too much work has to be put into drivers, which aren't > going > to make things better, but rather even more worser. Not necessarily drivers need to be patched, as the existing callbacks could be used. Still, I think it makes sense to gradually change the drivers we care to the new way, in order to provide a better API. Of course, the old calls should still work. So, it is not getting anything worser. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
