<div dir="ltr">Previous attempt to <a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a> bounced, but everything looks good now.<div><br></div><div>I apologize to those that already received this.<br clear="all"><div><div class="gmail_signature"><br></div><div class="gmail_signature">Clark B. Wierda</div></div>
<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Clark B. Wierda</b> <span dir="ltr"><<a href="mailto:cbwierda@gmail.com">cbwierda@gmail.com</a>></span><br>Date: Sun, May 22, 2016 at 2:10 PM<br>Subject: Re: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up<br>To: <a href="mailto:gpsd-dev@nongnu.org">gpsd-dev@nongnu.org</a>, <a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a><br>Cc: "Eric S. Raymond" <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>><br><br><br><div dir="ltr">Just a few general thoughts:<div><br></div><div>It might be easier to follow if the "clockmaker" sequence is presented separately from the "manual" sequence.  Likely, this would be different parts of the same document.</div><div><br></div><div>Any discussion of fudge factors beyond any defaults in the code (if PPS is reliable, they are not needed) and performance tuning is applicable to any installation and should be a separate document.  The Timeservice document related to GPSD already exists and discusses many of these items.</div><div><br></div><div>The main sequences noted above should document the "happy path".  Handling the problem should go to a Troubleshooting section with more detailed information.  This will reduce the opportunity to confuse the naive user that is the target of this document.</div><div><br></div><div>Likewise, I think we should like the scope in the primary sections to the Raspberry Pi.  There are at least 5 variants there (at least 2 of which will not accept the GPS HAT).  [I'd actually be tempted to write to the RPi 2B as that is likely to be the most common while avoiding the issues with the RPi 3B.  The special case would be handled as noted above with special section on the differenecs.]  There are many documents on the 'Net that reference another document as a baseline and only document the changes.  The Raspberry Pi is likely to remain the majority player in this space for the foreseeable future.  Some of the other devices in this space are going to be work-alike or work-similar.  Most users who are going to be trying something like an ODroid, or Banana, are likely to be able to handle the needed adjustments themselves.  Something further afield, like the Beaglebone, will be different enough to add significantly to the complexity in handling.</div><div><br></div><div>Finding the IP of the Pi would be one of those things that could go in a separate section if it doesn't "just work".  Just adding a keyboard and monitor long enough to find the address is likely to work for most people.  Much beyond that is going to be risking confusion to the target audience.</div><div><br></div><div>I'm reminded of the NTPsec motto and I think we should apply that here.  The main sequence should be as simple as possible.  I think the sections could be something like Introduction, Scripted/Automated/clockmaker, Manual, Troubleshooting, Special Cases, References.<br><div class="gmail_extra"><br></div><div class="gmail_extra">I know this is late in the process for this kind of input, but I hope this is still useful in some way.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br clear="all"><div><div>Clark B. Wierda</div></div></div></div></div>
</div><br></div></div>