11
\$\begingroup\$

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?

\$\endgroup\$

closed as unclear what you're asking by Scott Seidman, RoyC, Dmitry Grigoryev, Lior Bilia, Elliot Alderson Nov 6 '18 at 15:24

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 12
    \$\begingroup\$ The comparison in the link is just silly. \$\endgroup\$ – pipe Oct 29 '18 at 10:16
  • 9
    \$\begingroup\$ Yep, @pipe, and atop of that, even the numbers are totally wrong. I'll gladly buy the DS12C887-priced RTC chip with "1 sec of error in 100 years". In fact, I'll buy as many as my savings allow me to buy. That is a 300ppb accuracy. Over 100 years. That's some serious frequency goodness right there. \$\endgroup\$ – Marcus Müller Oct 29 '18 at 10:17
  • 8
    \$\begingroup\$ Real time systems and Real time clock are different things and there is no comparison. RTC is for time keeping and Real Time System is used to serve real time(not as in UTC, but as in quickness) purposes \$\endgroup\$ – MaNyYaCk Oct 29 '18 at 10:18
  • 2
    \$\begingroup\$ @pipe DS12C887, 100 year plan version. \$\endgroup\$ – Marcus Müller Oct 29 '18 at 10:40
  • 3
    \$\begingroup\$ @JimmyB Clocks like this are for timing, not time! Even if you have a reference epoch, we generally set it to TAI (or GPS) and apply the relevant UTC correction when we need UTC. In the case of GPS this correction parameter comes from ephemeris. UTC is a kind of "timezone" in that sense - similarly you do not reset your clock when DST comes into effect and wait for it to re-stabilise - there's nothing to reset, because the clock gives you pulses, not a timestamp. \$\endgroup\$ – Lightness Races in Orbit Oct 30 '18 at 12:27
39
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ Actually those systems most likely do have real-time components, albeit "soft real-time" because the consequences of missing/overrunning a processing tick are small. Not in the misguided sense that the author of the link thought, though. \$\endgroup\$ – Graham Oct 29 '18 at 20:35
  • 2
    \$\begingroup\$ @Graham: In some sense they do, but the margins are so huge you generally think of them as non-realtime. Ultimately any interactive system is realtime if you extend the definition far enough because when it doesn't react for minutes or hours, someone is going to assume it's crashed. :-) So I think it's only useful to categorize something as "realtime" when there are small margins and serious consequences for missing them. \$\endgroup\$ – R.. Oct 29 '18 at 20:46
  • 3
    \$\begingroup\$ @R.. Not all systems are real time, even with huge margins. If a system is capable of hanging indefinitely, it cannot be a real time system. The systems must have absolute guarantees that a timeslot will only take a finite period of time, and a hang (deadlock/livelock) is, by definition, infinite. \$\endgroup\$ – forest Oct 30 '18 at 1:36
  • 2
    \$\begingroup\$ A meta-discussion about exactly what a real time system is doesn't belong in a comment section though. \$\endgroup\$ – pipe Oct 30 '18 at 9:53
  • 1
    \$\begingroup\$ @Uwe: Indeed I messed it up, but now that I look at it again I think I'm off by 2 factors of 10 - shouldn't it be 0.316ppb? Figuring as 1s/(100*secs_per_year) where secs_per_year=31556952. \$\endgroup\$ – R.. Oct 31 '18 at 18:15
39
\$\begingroup\$

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ This is short and to the point answer to the question IMO. \$\endgroup\$ – Rev1.0 Oct 29 '18 at 16:09
  • \$\begingroup\$ Some Federal entities like Banks use 1ns RTC's in their servers, based on atomic clocks. Even a hint of tampering with their microwave links will change the transit time to the receiver. Fast RTC also good for multi-phase semaphores. \$\endgroup\$ – Sparky256 Oct 30 '18 at 4:11
  • 4
    \$\begingroup\$ Some real time systems don't need a timer as they are entirely event driven, and there's no need for any of the events to be time based. The system just needs to respond to each event within the time period allotted for that event, including when multiple events occur very close to each other. In some cases, a preemptive kernel may be needed. External timers might be used to validate the system is operating within it's time constraints. \$\endgroup\$ – rcgldr Oct 30 '18 at 6:18
  • 2
    \$\begingroup\$ If you'd like a real-world example, MicroWare's OS-9 operating system for the Motorola 6809/Hitachi 6309 processors is a Real Time OS. The Tandy Color Computer series utilized 6809s and ran OS-9 (my first exposure to a *nix-like OS) and real time clocks were never standard equipment on that system, and were not required for OS-9 to function. \$\endgroup\$ – zmerch Oct 31 '18 at 13:11
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ The question is how to quantify the reduced CPU time and memory usage of an RTC vs. no RTC in a real-time system. Your answer doesn't answer that. \$\endgroup\$ – pipe Oct 30 '18 at 10:02
  • 1
    \$\begingroup\$ @pipe It depends on the CPU architecture and requirements. It is simply not possible to answer with scarce information given. My answer says why RTC must be in there instead of generic bla-bla about how it could be wihtout it. Programmer and system architect may design a good system and code and bad system and code in terms of time spent on the timing. \$\endgroup\$ – Anonymous Oct 30 '18 at 11:39
3
\$\begingroup\$

This seems to be an issue of terminology surrounding the use of the term "real time".

Real-time clock

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.

Real-time system

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.

Real-time clocks vs high resolution timers

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.

\$\endgroup\$
  • \$\begingroup\$ As a slight niggle, "shortest [...] possible" isn't considered real time. Real time is response in deterministic time, or with defined ordering if multiple events occur simultaneously. \$\endgroup\$ – awjlogan Oct 31 '18 at 13:09
2
\$\begingroup\$

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:

  • disable interrupt from wake-up latch
  • set the wakeup time for up to 0x7FFFFFFF ticks (about 9 hours) ahead of present
  • reset the wakeup circuit
  • read the clock
  • if newly-read time indicates wake-up time has been reached, act appropriately
  • enable interrupt from wake-up latch

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.

\$\endgroup\$
  • \$\begingroup\$ "Real" RTCs also provide calendar functionality (day-of-month, day-of-week, leap years,...), which may be cumbersome to implement yourself in software. \$\endgroup\$ – JimmyB Oct 30 '18 at 11:42
  • \$\begingroup\$ @JimmyB: Software that needs to do anything non-trivial with dates and times will generally include such logic anyway, and being able to keep things in linear format except when performing user I/O would be much cleaner than having to convert from the useless BCD YMDhms to linear time every time it reads the RTC and convert back to the useless fromat when writing. \$\endgroup\$ – supercat Oct 30 '18 at 14:51
  • \$\begingroup\$ @JimmyB: As a simple example, if one were to power up the system at what seemed to be 2016-03-01 00:30, and it was last powered on at 2015-10-01 at 00:30:00, what time would it be? Software would need to know that February had 29 days in 2016 to determine that the time was 2015-02-29 23:30:00, so what exactly does the calendar hardware buy? \$\endgroup\$ – supercat Oct 30 '18 at 14:55
  • \$\begingroup\$ The RTC chip referenced in the OP handles leap years correctly by itself. \$\endgroup\$ – JimmyB Oct 30 '18 at 15:44
  • \$\begingroup\$ "Software that needs to do anything non-trivial with dates and times" Sure. But an RTC is just a clock. It tells you what time it is when you ask for it, it does not compute your age in seconds for you. So if you want to timestamp your log entries the RTC is all you need and you won't have to deal with any kind of date/time math. If you want to do arbitrary calculations on times it is not of much use to you. \$\endgroup\$ – JimmyB Oct 30 '18 at 15:52
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ How exactly coupling an RTC to a watchdog can guarantee that the clock remains "in phase with various things"? \$\endgroup\$ – Dmitry Grigoryev Nov 5 '18 at 12:03
  • \$\begingroup\$ Okay if you use external clock source you are dependent on that source, as well as the circuitry connecting it like capacitance and resistance or impedance. So this is described by harmonic oscillation whose solution is a wave and then see phase angle etc, as well as application of microprocessor to answer everything you just asked. All this stuff unfortunately does have to be accounted for in many applications. \$\endgroup\$ – marshal craft Nov 5 '18 at 19:50
0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ That's not entirely true. You can, for example, trust a certificate (especially a pinned one) even though it is expired or theoretically was issued in what seems to be the future. However it's generally a better idea to get your NTP fix before trying to do be an SSL client; naturally security schemes for NTP have to be designed to work without needing to start with a sensible idea of the time. \$\endgroup\$ – Chris Stratton Oct 29 '18 at 16:45
  • 3
    \$\begingroup\$ Grossly over exaggerated and whilst exaggeration is a heartwarming and beautiful thing, if it forms the principal message, then it's wrong. Non of the modes of operation of ciphers fundamentally require the time or date. \$\endgroup\$ – Paul Uszak Oct 29 '18 at 22:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.