discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Scheduler enhancement?


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Scheduler enhancement?
Date: Wed, 20 Jul 2016 23:25:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

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
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]