>>> That’s not a big deal, but when we make the base more precise, we lose range. If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and his inter-planetary Internet. :-) >>> The current 24 bits of usec delay isn't that much better at ~16 sec. (Unless there is a proposal to change that to 32 bits?)
On Tue, May 25, 2021 at 9:53 AM Tony Li <[email protected]> wrote: > > Hi Greg, > > Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, > 10 nanoseconds or 100 nanoseconds. > > > Ok. The specific precision isn’t particularly relevant to me. The real > questions are whether microseconds are the right base or not, and whether > we should shift to floating point for additional range or add more bits. > > To Tony's question, the delay is usually calculated from the timestamps > collected at measurement points (MP). Several formats of a timestamp, but > most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where > 32 bits represent seconds and 32 bits - a fraction of a second. As you can > see, the nanosecond-level resolution is well within the capability of > protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from > higher resolution of the packet delay metric, I can think of URLLC in the > MEC environment. I was told that some applications have an RTT budget of in > the tens microseconds range. > > > It’s very true that folks have carried around nanosecond timestamps for a > long time now. No question there. My question is whether it is actually > useful. While NTP has that precision in its timestamps, the actual > precision of NTP’s synchronization algorithms aren’t quite that strong. > In effect, many of those low order bits are wasted. > > That’s not a big deal, but when we make the base more precise, we lose > range. If we go with 32 bits of nanoseconds, we limit ourselves to a link > delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and > his inter-planetary Internet. :-) > > We could go with 64 bits of nanoseconds, but then we’ll probably only > rarely use the high order bits, so that seems wasteful of bandwidth. > > Or we can go to floating point. This will greatly increase the range, at > the expense of having fewer significant bits in the mantissa. > > Personally, I would prefer to stay with 32 bits, but I’m flexible after > that. > > Tony > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
