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 <[email protected]> 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 > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Very Respectfully, Dan CaJacob
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
