Re: Details about DVB frontend API

[Julian Scheel <julian@jusst.de>]

Manu Abraham schrieb
> Not only is it time critical, but it should also be "atomic", ie it
> should be all in one go, ie one single snapshot of an event, not
> events bunched together serially. Things wont seem that "atomic" on a
> system with a large load. Latency will have a significant effect on
> the statistics (values) read back, since it is again disjoint events.
>   
Right, the values should be treatened as a unique unit...
> Time stamping would be helpful, prior to any processing by the library
> such that the time overhead for the calculations is offset, but that
> can be really useful within the same library alone. I can't imagine
> how time stamping can be helpful to result a low latency.
>   

No, timestamping would of course not be helpful for reducing the 
latency, it would just allow to correctly interpret values if they are 
delayed. So that you won't assume the values you receive can be taken as 
proven for the current moment.

> If you don't have a low latency, Consider this (even when you are able
> to ignore the statistics for any general processing, on the thought
> that "i can always live with those errors and i always had"):
>
> The error fedback into the loop for a sat positioner/rotor. The final
> calculated position will never be the actual position that you wanted
> the antenna to be at a certain location. The problem would be made
> worser by the different rotor speeds as well, to add to the nightmare.
>
> With the V5 operation, you bunch operations together in a serial
> manner, it is atomic to the sense that it happens or doesn't happen,
> but it is not atomic to the sense of any particular time frame. You
> just keep your fingers crossed that the CPU executes the event in the
> shortest frame. This won't hold good in all cases when there is a high
> latency on the system when there is a significant load.
>
> eg: You can imagine an IPTV headend streaming data, with a small CPU
> with multiple tuners and trying to compensate the offset that's
> introduced.
>
> Still worser situation: imagine a gyro stabilized setup, where the
> base itself is not that stationary.
>   

Ok, thanks for the details about how V5 API deals with this. Indeed this 
is a major issue one has to think of when talking about signal statistics.

> Some other points to be considered:
> * As of now, the get/set interface is not used for any signal statistics
>
> * Even if one prefers to normalize all parameters into one single
> standard, even then you wouldn't land with a get/set interface.
>
> * The generic get/set interface is good when you have an unknown set
> of parameters, such that one can keep adding in parameters.  Eg: most
> people favoured this approach when we had a larger set of modulations/
> error correction and other parameters.
>
> For the case what we have currently, we do not have such a varied set
> of parameters to consider.

Right, the situation about the parameters which will be requested in 
terms of signal statistics should not change for future frontend types, 
so it really should be a save approach to have a static API here. I have 
not yet done a very detailed look into your proposed patch, but I will 
do so tomorrow.
I really would like to see a reliable statistics API in v4l-dvb soon.

Regards,
Julian