PC clocking uses a reference oscillator of about 25MHz (a popular choice for Ethernet and PCIe). This starts as a crystal sine wave that is ‘squared up’ by a buffer to make a digital signal. That square wave then is used to generate the various frequencies (CPU, DRAM, PCIe, etc.) using PLL multipliers and dividers. The resulting clocks will usually will have some ratio relation to each other.
The system clock tick also comes from the same reference, and is used to drive timers and a system clock counter. It will also have a numerical relation to the reference oscillator, but won’t necessarily be an integer relationship to the CPU clock. This clock tick in turn generates an estimate of ‘wall clock’ time. The operating system uses this as the reference time. This is the time that's returned by the operating system, e.g., via the
get_time() system call.
However, there's a problem. The difference between local estimated ‘wall clock’ time and actual standards-traceable time is expressed as a clock drift, and is indeed influenced by the accuracy and stability of the system oscillator. PC crystals aren’t expected to be more accurate than about 30ppm or so, nor are they stabilized, so if that matters the local time needs to be corrected from a traceable source.
Where does this matter? Servers for example, need accurate time stamps on transaction events.
These systems that need a calibrated reference will initially adjust their estimated ‘wall clock’ based on an independent local, nonvolatile reference. This can (and often is) in the form of a local battery-backed real-time clock (sometimes called the CMOS clock) that establishes an estimate of wall clock time at start-up.
Once the system is running, the machine can access a standards-traceable time reference over a network using a protocol like NTP. Wireless systems may use a cellular radio or even a GPS receiver that has standards-traceable time (this is true for all cell phones these days.)
Whatever the method - CMOS clock, NTP, GPS or cell radio - this calibration ensures an accurate wall clock time.
One case where the system crystal itself is adjusted in real-time is digital television receivers. These use embedded timing references in MPEG-2 Transport to adjust a VCO or 'pullable' crystal to cancel the clock drift. This ensures video playback doesn't have long term over- or under-run issues. (Nowadays, they use a fractional-n clock synthesizer to make that adjustment.) This standard then generates the video and audio playback clocks. Systems that don't use this correction will instead skip/repeat frames and / or glitch the audio. (experience: media processor IC design.)
Now, as far as a low-end MCU, there isn’t necessarily a system time tick unless it’s generated from a timer. This will have some divisor relationship to the system crystal, whose accuracy determines clock drift. A decent, properly loaded crystal should still deliver +/-50ppm or so; RC oscillators, not so much. Again, if accuracy is critical, best to re-sync with a known reference to establish known wall-clock time.