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 <muel...@kit.edu> 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 <marcus.muel...@ettus.com>
> 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 <(310)%20336-1274>
> > > > ________________________
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > --
> > Very Respectfully,
> >
> > Dan CaJacob
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Very Respectfully,
Dan CaJacob
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
