Re: [Discuss-gnuradio] Scheduler enhancement?

[Piotr Krysik]

Hi Marcus,

Ok, it is therefore indication of problem with an overflow happening in
rtl-sdr source block on the side of PC (there is no more free buffers to
store incoming sample). I'm aware that with RTL-SDR's it is not possible
(as far as anyone knows) to read how many samples were lost. But any
communication error (on side of the device or on side of a PC) will
cause synchronization loss in multiple RTL-SDR's that were synchronized
beforehand. Knowing at least some communication errors will enable
recovering from them - that means calling a function that will make
RTL-SDR receivers to be synchronized again.

Of course information that something went wrong with transmission on the
side of the device would be much more valuable (overflows on the side of
PC can be tackled by increasing number of buffers and speeding up
processing).

Best Regards,
Piotr Krysik

W dniu 22.07.2016 o 12:01, Marcus Müller pisze:
> Hi Piotr,
>
> As far as I grok the gr-osmosdr rtl_souce, this is an overflow
> indication purely based on the fact that in the rtl_source itself, the
> number of the last used buffer is compared with the maximum number of
> buffers that should be – and if that happens, that is an indication that
> the software side noticed things ran over how much buffer there's
> available.
>
> That's pretty different from the USRP approach: It is indeed a kind of
> overflow indication, but it gives no chance whatsoever to recover, since
> the rtl dongle isn't aware of it, and also has no means to actually time
> stamp data. If things get really bad, and USB buffers get lost before
> they even reach userland, librtl can't even notice, I think (the USB
> bulk transfer packets are pretty much samples only, as far as I read
> librtlsdr's librtlsdr.c in combination with rtl_source_c.cc), so there's
> no timing/"original sample count" info available. USRPs actually keep
> track of ACKs coming from the PC.
>
> Best regards,
> Marcus
>
> On 22.07.2016 10:45, Piotr Krysik wrote:
>> W dniu 22.07.2016 o 09:34, Sylvain Munaut pisze:
>>> Hi,
>>>
>>>> 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.
>>> rtl-sdr can't detect sample loss ...
>>>
>>> With USRP, the hw reports overflows to the host, but the rtl-sdr has
>>> no such thing, it will drop sample silently if its internal buffers
>>> overflow.
>>>
>> Here is some form of detection of overflows:
>>
>> http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n305
>>
>>
>> What you are saying means it doesn't detect 100% of overflows?
>>
>>
>> Best Regards,
>>
>> Piotr Krysik
>>