How accurate would the time on my Raspberry Pi 3 be if it is continuously connected to the Internet, but without an RTC?
According to wikipedia, the Network Time Protocol used by default on Raspbian and millions of other networked devices and computers:
is intended to synchronize all participating computers to within a few milliseconds
In fact, NTP is used on systems (servers, PCs, etc.) that have an RTC in order to correct for the drift computer clocks may have. Meaning, if you added an RTC, it would be kept accurate by using the exact same network mechanisms that are used to set the OS "software" clock already (which, realistically, is tied to the processor frequency, i.e., there's crystal in there somewhere that effectively keeps the time while the system is on).
NTP protocol attempts to measure and compensate for network latency and other delays, it is very accurate even when using public time servers.
RTC is used to maintain system time when power is removed, and it not necessarily even accurate, after your raspberry PI has booted up and received the time from
NTP it will continue to count time without an
RTC even if network is disconnected.
NTP you are not continuously synchronizing to the network, the system time is maintained with a timer based on the cpu clock.
When run with a local network time server,
NTP can achieve accuracy of
When run over the public internet, dynamic and potentially asymmetric routing of packets contributes to a poorer estimate of network delays. However, you can expect accuracy of well under
1s with most documentation claiming an accuracy of
100ms over the public internet.
If you need better synchronization, without better accuracy, you may consider running a local NTP server to synchronize multiple raspberry pi relative to each other with better than
1ms synchronization (good for aligning sensor data) .
If you need both accuracy and synchronization, you can run a Stratum 1 NTP server using GPS as the time source.
Presence or absence of RTC has nothing to do with timekeeping precision. It's purely a matter of being able to keep (a poor approximation of) current time while the device is powered down so that the system time is correct before you bring up the network device and ntpd.
Note that if you want a secure remote clock source rather than plain ntp, you'll need to know a rough idea of the current time (accurate within month scale) in order to validate certificates; this is probably the main modern purpose of an RTC on internet-connected devices.
Having done experiments with C++ on my RPI3 (Stretch) using the sys/time.h function gettimeofday(**) and the wiringPi API then measuring against a scope, streamlined applications can obtain sub-millisecond resolution and accuracy on timing.
Now if you are using other languages on the RPI you may not be able to obtain those speeds.
We get accuracy of better than a second on several units using a public NTP server the other side of a complex and busy network. We also only need accuracy of the order of 1s (which the system clock can maintain for days while powered up).
Check out the ntpd man page, but after configuring a server, making sure that
ntpd -g runs on boot should be all you need. The
-g gets you back to real time if the clock is way out, such as after loss of power.