Differences

This shows you the differences between two versions of the page.

--- blog:articles:software:lunaclockpub [2024/06/21 13:54] – Phil Ide
+++ blog:articles:software:lunaclockpub [2024/07/28 14:53] (current) – [Lunar Clock Published] Phil Ide
@@ Line 7: / Line 7: @@
 I have decided not to turn the program into an NTP server, since that is non-trivial task. If someone thinks that would be a great idea (I no longer think so), they can take existing NTP code and amend it.
+===== Recent Updates =====
+{{rss>https://github.com/stroggprog/rtap/commits/main.atom date 3}}
 ===== New Philosophy =====
@@ Line 28: / Line 32: @@
 Since there is a processing delay while the RPC server adjusts the timestamp, the RPC server cannot be used as a clock with a granularity less than a microsecond. A program that represents a clock (e.g. displaying the time and updating in real-time) must take this into consideration. However, it can make its own adjustments if it notes the turnaround time between requesting the adjusted time and receiving it - but the process of applying the secondary adjustment of the turnaround time is also time expensive. Nonetheless, noting the average turnaround time will reveal how accurate the displayed clock is. If it takes an average of 150 microseconds to receive the timestamp from the RPC server, the clock cannot be relied on to be more accurate than this (and since this is an average, arguably it is less accurate than this). Therefore, in this case, the clock should not display greater granularity than thousandths of a second - which is fine for most clocks which only wish to display seconds with an update of approximately ten times per second.
+~~socialite~~
+~~DISCUSSION~~