Mixing
Is a Real-Time Clock (RTC) necessary for real-time systems?
Clash Royale CLAN TAG#URR8PPP
up vote
4
down vote
favorite
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?
rtc
edited 7 mins ago
laptop2d
22.5k123175
asked 8 hours ago
www
1568
 |Â
show 6 more comments
up vote
4
down vote
favorite
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?
rtc
edited 7 mins ago
laptop2d
22.5k123175
asked 8 hours ago
www
1568
6
The comparison in the link is just silly.
– pipe
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
6
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.
– Marcus Müller
8 hours ago
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
– MaNyYaCk
8 hours ago
2
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago
 |Â
show 6 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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?
rtc
edited 7 mins ago
laptop2d
22.5k123175
asked 8 hours ago
www
1568
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?
rtc
rtc
edited 7 mins ago
laptop2d
22.5k123175
asked 8 hours ago
www
1568
edited 7 mins ago
laptop2d
22.5k123175
asked 8 hours ago
www
1568
edited 7 mins ago
laptop2d
22.5k123175
edited 7 mins ago
laptop2d
22.5k123175
edited 7 mins ago
laptop2d
22.5k123175
22.5k123175
asked 8 hours ago
www
1568
asked 8 hours ago
www
1568
asked 8 hours ago
www
1568
1568
6
The comparison in the link is just silly.
– pipe
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
6
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.
– Marcus Müller
8 hours ago
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
– MaNyYaCk
8 hours ago
2
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago
 |Â
show 6 more comments
6
The comparison in the link is just silly.
– pipe
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
6
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.
– Marcus Müller
8 hours ago
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
– MaNyYaCk
8 hours ago
2
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago
6
6
The comparison in the link is just silly.
– pipe
8 hours ago
The comparison in the link is just silly.
– pipe
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
6
6
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.
– Marcus Müller
8 hours ago
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.
– Marcus Müller
8 hours ago
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
– MaNyYaCk
8 hours ago
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
– MaNyYaCk
8 hours ago
2
2
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago
 |Â
show 6 more comments
7 Answers
7
active
oldest
votes
up vote
16
down vote
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.
answered 8 hours ago
MaNyYaCk
707421
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
add a comment |Â
up vote
11
down vote
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 30 ppb. You can't get that kind of clock stability without 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.
answered 3 hours ago
R..
33117
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
add a comment |Â
up vote
4
down vote
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.
answered 7 hours ago
Anonymous
4,7541728
add a comment |Â
up vote
1
down vote
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 need one.
answered 6 hours ago
Sean Houlihane
3,2651921
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.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
supercat
37.7k159107
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
marshal craft
1187
add a comment |Â
up vote
-1
down vote
For high resolution timers in computers you use other types of components, most likely a crystal oscillator or similar. These are made to give a very precise frequency output and that is what is needed in a real time system when you work with things that should happen every x us/ms.
They might still have a small error that builds up over time and therefor can a RTC be a good compliment for the features within the system that needs time in data/time format.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
add a comment |Â
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
16
down vote
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.
answered 8 hours ago
MaNyYaCk
707421
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
add a comment |Â
up vote
16
down vote
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.
answered 8 hours ago
MaNyYaCk
707421
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
add a comment |Â
up vote
16
down vote
up vote
16
down vote
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.
answered 8 hours ago
MaNyYaCk
707421
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.
answered 8 hours ago
MaNyYaCk
707421
edited 8 hours ago
answered 8 hours ago
MaNyYaCk
707421
answered 8 hours ago
MaNyYaCk
707421
answered 8 hours ago
MaNyYaCk
707421
707421
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
add a comment |Â
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
This is short and to the point answer to the question IMO.
– Rev1.0
2 hours ago
add a comment |Â
up vote
11
down vote
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 30 ppb. You can't get that kind of clock stability without 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.
answered 3 hours ago
R..
33117
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
add a comment |Â
up vote
11
down vote
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 30 ppb. You can't get that kind of clock stability without 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.
answered 3 hours ago
R..
33117
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
add a comment |Â
up vote
11
down vote
up vote
11
down vote
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 30 ppb. You can't get that kind of clock stability without 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.
answered 3 hours ago
R..
33117
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 30 ppb. You can't get that kind of clock stability without 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.
answered 3 hours ago
R..
33117
edited 3 hours ago
answered 3 hours ago
R..
33117
answered 3 hours ago
R..
33117
answered 3 hours ago
R..
33117
33117
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
add a comment |Â
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
The first sentence is really everything that has to be said here. The whole website seems dubious at best.
– pipe
2 hours ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
@jrh: As far as I know, yes, they're way above an OCXO on the cost scale - thus the "at least". A quick search seems to confirm that: digikey.com/product-detail/en/microsemi-corporation/…
– R..
48 mins ago
add a comment |Â
up vote
4
down vote
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.
answered 7 hours ago
Anonymous
4,7541728
add a comment |Â
up vote
4
down vote
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.
answered 7 hours ago
Anonymous
4,7541728
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered 7 hours ago
Anonymous
4,7541728
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.
answered 7 hours ago
Anonymous
4,7541728
edited 7 hours ago
answered 7 hours ago
Anonymous
4,7541728
answered 7 hours ago
Anonymous
4,7541728
answered 7 hours ago
Anonymous
4,7541728
4,7541728
add a comment |Â
add a comment |Â
up vote
1
down vote
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 need one.
answered 6 hours ago
Sean Houlihane
3,2651921
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.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
1
down vote
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 need one.
answered 6 hours ago
Sean Houlihane
3,2651921
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.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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 need one.
answered 6 hours ago
Sean Houlihane
3,2651921
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 need one.
answered 6 hours ago
Sean Houlihane
3,2651921
answered 6 hours ago
Sean Houlihane
3,2651921
answered 6 hours ago
Sean Houlihane
3,2651921
answered 6 hours ago
Sean Houlihane
3,2651921
3,2651921
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.
– Chris Stratton
2 hours ago
add a comment |Â
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.
– Chris Stratton
2 hours ago
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.
– Chris Stratton
2 hours ago
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.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
supercat
37.7k159107
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
supercat
37.7k159107
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
answered 2 hours ago
supercat
37.7k159107
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.
answered 2 hours ago
supercat
37.7k159107
answered 2 hours ago
supercat
37.7k159107
answered 2 hours ago
supercat
37.7k159107
answered 2 hours ago
supercat
37.7k159107
37.7k159107
add a comment |Â
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
marshal craft
1187
add a comment |Â
up vote
0
down vote
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.
answered 2 hours ago
marshal craft
1187
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
answered 2 hours ago
marshal craft
1187
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.
answered 2 hours ago
marshal craft
1187
answered 2 hours ago
marshal craft
1187
answered 2 hours ago
marshal craft
1187
answered 2 hours ago
marshal craft
1187
1187
add a comment |Â
add a comment |Â
up vote
-1
down vote
For high resolution timers in computers you use other types of components, most likely a crystal oscillator or similar. These are made to give a very precise frequency output and that is what is needed in a real time system when you work with things that should happen every x us/ms.
They might still have a small error that builds up over time and therefor can a RTC be a good compliment for the features within the system that needs time in data/time format.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
-1
down vote
For high resolution timers in computers you use other types of components, most likely a crystal oscillator or similar. These are made to give a very precise frequency output and that is what is needed in a real time system when you work with things that should happen every x us/ms.
They might still have a small error that builds up over time and therefor can a RTC be a good compliment for the features within the system that needs time in data/time format.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
For high resolution timers in computers you use other types of components, most likely a crystal oscillator or similar. These are made to give a very precise frequency output and that is what is needed in a real time system when you work with things that should happen every x us/ms.
They might still have a small error that builds up over time and therefor can a RTC be a good compliment for the features within the system that needs time in data/time format.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
For high resolution timers in computers you use other types of components, most likely a crystal oscillator or similar. These are made to give a very precise frequency output and that is what is needed in a real time system when you work with things that should happen every x us/ms.
They might still have a small error that builds up over time and therefor can a RTC be a good compliment for the features within the system that needs time in data/time format.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 3 hours ago
GuzZzt
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 3 hours ago
GuzZzt
1
answered 3 hours ago
GuzZzt
1
1
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
GuzZzt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
add a comment |Â
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
"high resolution" != "high precision".
– Long Pham
3 hours ago
"high resolution" != "high precision".
– Long Pham
3 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
Why would the crystal oscillator to the microcontroller have a small error but not the crystal oscillator in the RTC?
– pipe
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
It wouldn't. But many real systems don't need a crystal for the main processor clock, and instead use a very low power on-chip RC oscillator; precise enough for say RS232, but expected to drift quite a bit. In that case, the RTC crystal may be the only moderately accurate rate source in the system.
– Chris Stratton
2 hours ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f403878%2fis-a-real-time-clock-rtc-necessary-for-real-time-systems%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
6
The comparison in the link is just silly.
– pipe
8 hours ago
Neil, I hope you revisit this question: My guess (based on my knowledge of where I'm from and my knowledge of the suffix of your nickname) is that you are more of a native speaker than I am, but wouldn't "effect the real-timeness" be a correct thing to say?
– Marcus Müller
8 hours ago
6
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.
– Marcus Müller
8 hours ago
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
– MaNyYaCk
8 hours ago
2
@pipe DS12C887, 100 year plan version.
– Marcus Müller
8 hours ago