g...@rellim.com said: >> There is nothing to normalize in a l_fp All bit patterns are valid. > Sort of. The header notes imply the integral and fractional part may be > signed or unsigned. Separately. I have not confirmed if the code use that.
The whole point of l_fp is so you can do 64 bit arithmetic. There is no sign bit in the fractional part. It piggybacks on the sign of the high half. > Actually, there may be a better way. NTP defines an Epoch on the wire. > I do not know when it is sent. We are currently in NTP Epoch 0. In 2036 it > goes to NTP Epoch 1. If we can grab that field off the wire we are good. It's not on the wire. At least not in the main packet format. I don't think it is in mode 6. Yet. >> I think the build date of the code will be a good start. > Which breaks regression tests. We tried that on gpsd and the results were, > to be kind, loud. Please say more. I don't remember that scene. > Semms I believed someone that misread the RFC. NTP Time is based on > 1Jan1990, but when using the Epoch it can uniquely define any time backwards > or forward. s/1990/1900/ I think the idea is that a 32 bit value can represent a range that straddles the roll over boundary. If you have some known starting time, values of 32 bit times represent start to roll-over and roll-over to start+32 bits. That's backwards or forwards from the next roll-over rather than backwards or forwards from now. It's the same problem as the GPS 1024 week. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
