Assuming that we are working on a real-time Linux system and hardware which consists of high resolution timers, does having an RTC affect the real-timeliness of the system?
Here it says that it reduces CPU and memory usage, but is there a way to compare the difference somehow?
Real Time Systems are something that responds to an internal or external event /stimuli in a specified time and that time is usually in milli or micro seconds. It needs timer of small precision rather than RTC.
And the answer to your question is No, it won't affect the real timeness of the system.
The article you linked is just complete and utter nonsense. The "real time" in "real time clock" (as it's used to refer to the type of hardward device described in the article) and the "real time" in "real time systems" are completely different terms. The former means storing the current calendar time (usually some very poor approximation of it, as opposed to high-precision like the linked article claimed) and advancing it without external power, using a long-life button/coin type battery. The latter means responding to events with hard bounds on latency from the time of the event to the time of the response.
A few other bits from the article, to establish that it should be regarded as untrustworthy:
Almost negligible. Of the order of 1 sec in 100 years
1 sec in 100 years is roughly 317 ppt (yes, that's parts per trillion). You can't get that kind of clock stability with any existing commercially-available clock technology. Even getting it to 1 second per year would require at least an OCXO which requires a high-power, always-on oven regulating the temperature. The idea you could get it with a device powered by long-life coin battery is laughable.
real time systems like digital clock, attendance system, digital camera
None of these are what one would call real time systems.
If your system is offline after reset and having RTC, it will be able to put proper dates into the logs. Logs could be huge in case you need to look through them and having wrong timestamp will make you, your software developers and clients crazy, and in general investigation almost impossible.
Easy or difficult, low or high in the article you refer to is a kind of personal opinion. It is difficult and costly if you never did it before and do not have clear system requirements and statement of work; and it is easy and cheap when you know what you need and what is the best device to be used.
In most systems, the only real advantage of an RTC peripheral over other forms of time-keeping is that the RTC's time measurements will be unaffected when the rest of the system goes to sleep or--in some cases--is powered off entirely. Many RTC peripherals are in fact designed in ways that would make them impractical for most purposes other than recording approximate time of day. Many RTC peripherals (probably a majority but perhaps not a supermajority), for example, are limited to reporting time in one-second increments, and many of them will at least sometimes require busy-waiting for synchronization when setting an alarm or--in some cases--even simply trying to read the time. As a consequence, the normal way to use an RTC is to simply copy its value to a more useful clock on startup, set it whenever "wall time" is set, and ignore it the rest of the time.
All of the useful purposes that can be accomplished with an RTC chip could be accomplished with minimal cost and power consumption using a 47-bit ripple counter whose bits can be asynchronously forced to ones, 48 bits of battery-backed RAM (to store a "delta" value), a 32-bit alarm register, and an equality comparator whose lower bits are gated with upper bits of the comparator (so the lower bits won't even be examined unless or until the upper bits match), a simple de-glitcher (a sequence of slow inverters and a NAND, an asynchronously resettable wakeup latch, and circuitry to asynchronously read out the clock. Reading the clock while it's incrementing may yield bogus results, but if any two consecutive reads match, both will be guaranteed correct, and any four consecutive reads would be guaranteed to contain two that match (and are thus correct) unless more than 1/32768 second elapses between the first and last. Setting the alarm may generate spurious wake-up events, but the sequence:
should handle all edge cases sufficiently easily as to be suitable for general-purpose time-keeping use. Unfortunately, for whatever reason, RTC peripherals are never designed that way, but are instead more complicated and less useful.
This seems to be an issue of terminology surrounding the use of the term "real time".
A real-time clock is a device for stable/accurate (within some tolerance) timekeeping, so that the host system can use it to associate events/actions with the time and date of occurrence.
You can think of a real-time clock as analogous to the innards of a digital watch interfaced to the computer. It has an independently powered time reference designed to be stable and reasonably accurate. Like a digital watch, it won't lose track of the current time just because the host computer was shut down. Real-time clocks have been fitted to computers mostly as a convenience so that the user doesn't have to re-enter the current time and date every time the system is started, or make frequent adjustments to compensate for drift.
The alternative to a real-time clock would be to use software and internal timers driven by the system clock. Such an approach is workable (the original IBM PC worked that way), but is not particularly stable; it will also lose track of the date/time at any point the operating system is shut down, hangs, or crashes.
When the term "real-time" is applied to a computer system or application, it describes a system that responds to real-world events in a very short, deterministic amount of time - often just a few milliseconds, sometimes less, with defined ordering of simultaneous inputs. Real-time systems are used for such things as machine control - robotics, simulations, and games. Although a real-time application may make use of current time and date information, an application isn't "real-time" just because it makes use of the current time and date.
As stated above, the purpose of a real-time clock is to reliably keep track of the current date and time, generally only to the second; a good one will have minimal drift (seconds gained or lost each day). Real-time clocks generally don't have high resolution; their base clocks often run quite slowly in comparison to modern CPU clocks; this is to minimize power consumption (drain on its independent power source) so that the clock will continue to reliably keep time if the host computer is powered off for an extended period.
A high-resolution timer isn't concerned with the current time or date; its purpose is to measure time intervals at some precision, perhaps microseconds or even less. To accomplish this, it must be based off a stable, high frequency clock - typically the computer system clock. High-resolution timers are also not typically concerned with drift over long durations, because the usual purpose is time measurement over short durations. High-resolution timers don't have the same power consumption concern as real-time clocks because they don't have a job to do while the host computer is powered off.
I think the primary reason for a real time clock is accurate time at up to some interval. The regular clock is usually trimmed with capacitors and can have larger discrepancies on frequency based on a wide variety of factors perhaps out of control such as miss-tuned capacitance/resistance of the clock timing circuit, uncertainty in the timing of the clock being used which serves the duel purpose for performance, as well as there is often programmable logic to divide the times which again can introduce error.
Usually the RTC can have timers and watch dogs etc. Coupled to it, giving guaranteed or good assumption that at regular precise intervals that even can remain in phase with various things- given procedures or code will be executed. You can't easily get this with a regular clock. Or you need to be very careful in production that the clock is accurate. You can see things like audio and what not may need to use the rtc instead of the high speed system clock.
As for just what RTC means I can not say for sure myself. I know Linux is a prevalent tool in the embedded world however I'm not sure it how well it works for all real time applications. Multithreading can make execution times non deterministic, however when hardware greatly exceeds the performance requirements many solution will work fine even in real time applications.
Then there are mission critical and low performance applications. One desirable thing here is deterministic and often lower complexity solution. Here the RTC can be used obviously. Linux may provide special access to the interrupts coupled to it. It seems to me for deterministic real time you require not only an rtc but interrupts or o.s. Access to them.
You will need a real time clock if you're relying on secure communication with other computers on the internet (not 100% must have, but if you don't have a local time reference you need to trust something else, and you can't trust certificates unless you know the date).
So, no, you don't need one for all 'real-time' systems. However, depending on your application, you might still want an RTC as the most energy efficient way of acquiring a good time fix after being in a low power state.
