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

[Dan CaJacob]

I suppose if you don't have 64 bit, you can just shift it to be 32-bit and sacrifice the lost precision. There's probably other possibilities, but I think the newer ARM stuff is going 64-bit anyhow.

On Mon, Nov 13, 2017 at 2:01 PM Marcus Müller <address@hidden> wrote:

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

--

Very Respectfully,

Dan CaJacob