Re: [Discuss-gnuradio] Scheduler enhancement?

[Piotr Krysik]

Hi all,

It's a little bit off-topic but if someone will change the gr-osmosdr,
it would be great to have other stream tags that we are used to see at
the output UHD source. For example if the source prints on the output
that there is some problem with transmission it would be great to add a
stream tag at that moment. In Multi-RTL
(https://github.com/ptrkrysik/multi-rtl/) currently any such event means
that synchronization of channels is lost until user manually calls
resynchronization. Because there is no way to detect samples loss
resynchronization can't be called automatically.

On the wish-list I have a MSG input for controlling the osmocom source,
but this is off-topic even more.

Best Regards,
Piotr

W dniu 20.07.2016 o 23:25, Marcus Müller pisze:
> So, my takeaway from this is:
>
> * Tagging by the scheduler /before/ work is called doesn't make overly
> much sense, because of the blocking wait that might happen before the
> first sample is received
> * Tagging by the block is kind of prone to inconsistencies in tag format
> (though gr-uhd probably established a standard for this), and of course
> would need modifcation of a lot of blocks
> * If you need the precision, you must go for a device with hardware
> timestamping, anyway
> * Tagging by the scheduler /after/ the first work call returned means
> that one could "count backwards" to the first sample, based on sampling
> rate, but will of course be pretty rough, too
>
> All in all, I think having host-clock time stamping as part of the
> hardware source block seems to more sensible way – there's already Ettus
> Hardware handling (libusrp-era USRPs, IIRC) that does that for older
> devices that don't have hardware timestamping.
>
> Actually, thinking about this: abusing ctrlport's callbacks, couldn't we
> just let an "external" observer get notified when a work function
> returns? That observer would ideally be the software cross-correlator
> that syncs up your different hardware.
>
> Cheers,
>
> Marcus
>
>
> On 19.07.2016 23:23, Marcus D. Leech wrote:
>> On 07/19/2016 05:13 PM, Marcus Müller wrote:
>>> Question arising: would you want the tag to contain the time when
>>> general_work() was called, or rather the time of the first sample? Note
>>> that sources should usually be designed to be blocking until there's
>>> data available! That way, between entering general_work() and actually
>>> having the first sample, a lot of time could pass. It might make a lot
>>> more sense to let the block that knows the hardware handle tagging
>>> itself, here.
>>>
>>> Cheers,
>>>
>>> Marcus
>> The idea is to tag when the first samples come off the hardware.
>>
>> Indeed, if one had an N-channel "tag these when the samples show up"
>> block, it would likely be useless, since the scheduler will have
>>   nicely arranged for all of the those channels to have something
>> useful to do the first time it calls work().
>>
>>
>>>
>>> On 19.07.2016 23:00, Marcus D. Leech wrote:
>>>> On 07/19/2016 04:53 PM, Sylvain Munaut wrote:
>>>>> I don't see why this has to be done by the scheduler, I'd do that in
>>>>> the source, or even as a separate OOT that just inserts that tag.
>>>> Doing it in the source means modifying each source to insert, but,
>>>> maybe that's the right thing to do.
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>>      Sylvain
>>>>>