Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Marcus Müller]

Ok, see your point. I was a bit hesitant at first because that will end
up needing 64bit division (which might really not be much fun on many
ARMs), but meh, it's not like someone should be pushing tags around as
if they're samples.

Cheers,
Marcus

On Sun, 2017-11-12 at 23:33 +0000, Dan CaJacob wrote:
> Why not make the sub-second offset a uint64. That way you can express time to 
> the atto second (I think). The precision is overkill, but uint32, which 
> barely breaks a picosecond is underkill.
> 
> On Sun, Nov 12, 2017 at 6:19 PM Marcus Müller <address@hidden> wrote:
> > Hi Eugene,
> > yup, fully agree, the whole concept is slightly broken. 
> > So, first of all, I really think the key problem we're constantly working 
> > around is that tags have an integer offset – which leads to rounding 
> > errors, even in relatively benign scenarios.
> > I'd propose we add a fractional part: that would only extend tag_t by 
> > another integer field, so existing blocks wouldn't break, and would allow 
> > non-1:1-sync blocks to properly rewrite tag positions.
> > As you say, floating point is a bad idea when dealing with times (it always 
> > has been – see uhd::time_spec_t, where we're constantly paying off the 
> > technical debt of having floating point as "suggested" default 
> > representation of time, albeit underneath things should (and to some 
> > degree, are) counted in ticks). Thus, I'd imagine a tag_t like
> > struct tag_t {
> >     uint64_t offset; //integer offset, as had
> >     uint32_t fractional_offset; //interpret as fractional part, i.e. 
> > ·2^{-32}
> >     pmt::pmt_t key;
> >     pmt::pmt_t tag;
> >     pmt::pmt_t srcid; // might as well drop this; maybe someone is using 
> > this, but I haven't met them
> >     std::vector<long> marked_deleted; 
> > }
> > Would the fractional offset solve the issues you're seeing, assuming that 
> > we add proper handling to all the existing resamplers?
> > Best regards,
> > Marcus
> > 
> > 
> > On 09.11.2017 20:52, Eugene Grayver wrote:
> > > There is a major problem with the way tags are propagated in blocks with 
> > > non-integer relative rate. If the ratio is not a power of two, the 
> > > numerical accuracy of the floating point will cause the output tags to 
> > > diverge from the input tags.  Consider the fractional resampler. It 
> > > accumulates the timing offset in the range of 0 to 1. However tag 
> > > propagation multiplies the ratio by the sample number. As the sample 
> > > number grows the LSB accuracy of the ratio gets scaled by the ever larger 
> > > value. For a ratio of 1.001 we saw divergence of 1000s of samples over a 
> > > few minutes at 10msps. I rewrote tag propagation for the resampler but 
> > > did not rework the generic logic. I think the key point is to use the 
> > > delta between read and written items to take out the large integer 
> > > difference and then apply the scaling to a local delta within the current 
> > > window.
> > >  
> > > _______________________
> > > Eugene Grayver, Ph.D.
> > > Aerospace Corp., Sr. Eng. Spec.
> > > Tel: 310.336.1274
> > > ________________________
> > >  
> > > 
> > > 
> > > _______________________________________________
> > > 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
> 
> -- 
> Very Respectfully,
> 
> Dan CaJacob
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature