<div dir="ltr">I'm going to decide to not to decide right now.  We leave those refclocks in for now.  This conversation is illuminating.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019 at 9:32 AM Eric S. Raymond via devel <<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Richard Laager via devel <<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a>>:<br>
> I have (and was/am using) a clock using the Spectracom driver, with the<br>
> two-digit year. It recently suffered from GPS rollover, so I disabled<br>
> the GPS source in ntpd. I'm using the PPS source with network sources<br>
> (which I was using anyway) to number the seconds. This works well. I<br>
> didn't really care about the GPS source anyway. So if you were to remove<br>
> the driver, I wouldn't care.<br>
> <br>
> That said, if we wanted to do a better job in that driver, the following<br>
> pseudocode seems like it would produce the right results:<br>
> <br>
> We get a two-digit year and a day-of-year number. There is no<br>
> month/date, which I think is used in the NMEA driver to detect and<br>
> correct GPS rollover.<br>
> <br>
> ----<br>
> // Calculate the year assuming the clock works (no GPS rollover).<br>
> full_year = year + 2000;<br>
> while (1) {<br>
>     date = get_some_date_thing(full_year, day_of_year);<br>
>     if (date > BUILD_EPOCH)<br>
>         break;<br>
>     full_year += 100;<br>
> }<br>
> <br>
> // Calculate the year assuming GPS rollover<br>
> if (year < 90) { // or some similar fixed value<br>
>     full_year = year + 2000;<br>
> } else {<br>
>     full_year = year + 1900;<br>
> }<br>
> date2 = get_some_date_thing(full_year, day_of_year);<br>
> while(1)<br>
> {<br>
>     date2 = get_some_date_thing(full_year, day_of_year);<br>
>     if (date2 > BUILD_EPOCH)<br>
>         break;<br>
>     date2 = date2 + 1024 weeks;<br>
> }<br>
> <br>
> if (date2 < date)<br>
>     date = date2;<br>
> <br>
> // Use date<br>
> ----<br>
> <br>
> When my clock was working, it was outputting "18". Both approaches would<br>
> output the same thing, which is correct. This would work until 2090.<br>
> <br>
> Once my clock's GPS rolled over, it started saying 99. Today, it is<br>
> outputting "99 174". The first block would make that 2099 (as would the<br>
> current code). The second block would get the correct value. Note that<br>
> they will always be past the build epoch, so we just take the lower one<br>
> to find the one closer to the build epoch, which here is the right date.<br>
<br>
Please file this as an RFE, with some explanation of what get_some_date_thing()<br>
needs to be doing - I can't quite get it from this.<br>
-- <br>
                <a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br>
<br>
My work is funded by the Internet Civil Engineering Institute: <a href="https://icei.org" rel="noreferrer" target="_blank">https://icei.org</a><br>
Please visit their site and donate: the civilization you save might be your own.<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Mark Atwood<br>
<a href="http://about.me/markatwood">http://about.me/markatwood</a><br>
+1-206-604-2198</p>
</div></div>