Actually the first IBM PC _didn't_ have a real time clock, that only came in slightly later, either the XT or AT. If you ever ran MSDOS with no autoexec.bat you'd get a reminder of this even years later since the default action was to obtain the time and date for this very reason. It's also the reason for the ~18.2Hz clock interrupt under DOS - it was contrived to overflow a 16 bit counter at the top of the hour so that the hour and date registers could be updated.
See the above, but these days why would you bother in a networked environment and ntpdate is so easy to configure?
Sometimes you are in a networked environment, but can't access ntp at an appropriate time. not all networked environments are equal!
I encountered this recently. I had to come up with a solution for an environment with the following restrictions:
- rPi based "appliance" where the use case is that it's carried to a new location and plugged in for 2 hours a day.
- rPi is to be run headless, no monitor available
- The only network access available is an 802.1x wireless network which requires the date/time to be "right" to negotiate it's way through the authentication dance and get on the network.
- ntp is available *after* authentication, but not before.
After much faffing about trying to concoct workarounds involving saving the date/time to a file and slurping that in at boot time to hope that "right to within a day or two" would be good enough to make the authentication work...
I ended up just adding a cheap RTC module.
A fivers worth of additional hardware budget saved me much more than a fivers worth of development effort.
While I can see why the Pi doesn't have an RTC (and this by no means constitutes grumbling about its lack of RTC[1]) it would have made this particular project much easier!
-Paul [1] Limitations are there to be worked within, problems are there to be solved, bitching and whining about either doesn't get the engineering done :)
Indeed, the XT/286 must be a very rare machine. Of course then there were still people who believed that you could never be wrong (or be blamed) when buying IBM.
And circa 1976 when Byte ran an article about a "Real Time Clock" there was confusion too. "That's not a real clock" wrote one reader. I remember at the time wondering how a software clock could be "real" but then I wasn't looking at it properly.
From the 1975 Radio Shack Dictionary of Electronics (which was just a repackaging of a dictionary from Howard W. Sams):
Real Time Clock: A clock that indicates the passage of actual time, such as elapsed time in the flight of a missile, as opposed to some fictitious time established by a computer program.
I know there was a time when home computers didn't keep track of time, then when they did, it was via software interrupts. I don't know what was done with mainframe and minicomputers.
My OSI superboard had no real time clock, I suppose I could have implemented one, but at 2MHz I didn't want to interrupt things. My Radio Shack Color Computer running Microware OS-9 thirty years ago had a real time clock, using interrupts.
Sure, the definition can change since nowadays every computer has the means of setting their software clocks via hardware.
But, I am nitpicking for two reasons. The first is the original poster of this thread, who does this so often, misdirect things and then sits back with all the answers. His problem, if it really exists, is not the lack of an "RTC", but of a hardware clock. And even then, it's because he's too lazy to set the time on startup.
The other is that I dont' see computers getting time from the hardware clocks except at startup, or when deliberately told. The time is kept with software, the real time clock (it is keeping track of real time). It's not a perfect system, which is why Linux certainly has the means to set the clock from the hardware clock, and all the interest in getting the time over the internet.
But while hardware clocks have become standard, show me a computer that keeps track of time only via a hardware clock.
It was 35 at best. The Altair 8800 is only 40 years old this year.
There was no hardware clock in the IBM PC. Endless add on boards to do that, yet all they did was save the user from having to enter the time every time they turned on their computer. The software didn't go to the hardware clock every time it needed to time stamp a file, it used the software clock that wsa keeping track of real time.
My Radio Shack Color Computer had no hardware clock, yet it kept track of real time when I ran Microware OS-9 on it. All I had to do is enter the time and date on startup, and the files were timestamped.
Circa 1976 you would have seen a very different definition, and since I at lwast wsa reading the computer magazines back then, I'm not confused.
In the 1960s and into the 70s IIRC some mainframes at least (ICL 1900,
2903) had to be told the date and time on boot. 1900 dates were simply a signed 24 bit number where zero was 31Dec1899 and times only resolved to the nearest second.
By the end of the 70s I think most had a battery backed hardware clock (ICL 2900 certainly did). The 2900 hardware clock held date and time as a single integer accurate to the nearest microsecond: this was a sufficiently fine resolution to guarantee a unique file name if you included the timestamp as ccyymmddhhmmssmmmmmm in the file name. This was in fact used by the VME/B operating system whenever it needed a unique filename.
My first microcomputer (a Hewart 6809 that I assembled fro a kit and which ran Flex 09) did not have a clock of any sort. You told it the when you booted Flex and it never did know what 'time of day' meant.
I replaced that by a Gibbs Ultrascience board running OS-9 v2.3 on a
68008 chip. This was a co-processor board that lived in a PC's full length ISA slot. By this time PCs had 386 or 486 chip and a battery backed RTC, so OS-9 got the time and date from the PC's clock at boot time. That was in due course replaced by a Peripheral Technology motherboard running OS-9 v2.4 in a
68020 chip which, used an RTC clock chip with its own internal battery.
The main reason for doing it this way is that the clock chip can be very simple: it only needs to be a simple counter that ticks at the finest time resolution: in most older Linux systems this was a 1 millisecond tick rate, though since POSIX standardisation most standard library functions assume a microsecond tick rate. However, some functions that appeared with Linux kernel 2.6, e.g. futimens() and utimensat(), and were added to the POSIX standard in 2008 assume a nanosecond tick rate.
This approach leaves the complex stuff that deals with leap years, different month lengths, day of week, time zones and daylight saving time etc. where it belongs - in software.
I'd say it depends on how its implemented: if the hardware clock can be mapped into memory address space there's little reason not to read it directly. OTOH, if the RTC clock hardware and/or the MPU chip's memory access hardware can't do that (in Intel terms it might have to read the clock through the Southbridge) then its is likely to be easier (and faster) to keep a copy of the clock in RAM.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
In the Linux context, which is what we're discussing, you are, The kernel time keeping framework is called 'clk', it's the way the periodic timer interrupt gets generated, among other things. The RTC is the hardware that keeps track of external time and date specifically when the computer is powered off.
A real-time clock (RTC) is a computer clock (most often in the form of an integrated circuit) that keeps track of the current time. Although the term often refers to the devices in personal computers, servers and embedded systems, RTCs are present in almost any electronic device which needs to keep accurate time.
Although keeping time can be done without an RTC,[1] using one has benefits:
Low power consumption[2] (important when running from alternate power) Frees the main system for time-critical tasks Sometimes more accurate than other methods A GPS receiver can shorten its startup time by comparing the current time, according to its RTC, with the time at which it last had a valid signal.[3] If it has been less than a few hours, then the previous ephemeris is still usable.
The RTC was introduced to PC compatibles by the IBM PC/AT in 1984, which used a Motorola MC146818 RTC. Later, Dallas Semiconductor made compatible RTCs, which were often used in older personal computers, and are easily found on motherboards because of their distinctive black battery cap and silkscreened logo. In newer systems, the RTC is integrated into the southbridge chip.[10]
Some microcontrollers have a real-time clock built in, generally only the ones with many other features and peripherals.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.