When I read the Node HTTP module documentation, I noticed the server.timeout property. I wanted to introduce it briefly, but after sorting it out, I found that there is a huge content supporting timeout: server.timout -> node core timers -> uv timers -> linux msleep/hrtimer -> clocksource -> tsc -> cmos rtc -> clock After the end of the timer series, Noder can roughly understand: How clock cycle drives Linux msleep/hrtimer; The relationship between Linux timers and UV timers; Relationship between Node timers and UV timers.

Understanding the working principle of the Linux timer helps us to have a deeper understanding of the real features of the Node timer.

Timer core Components

  1. Stone core – Clock source – Hardware
  2. Guardian – Record time – software
  3. Timing dog – Event source – Hardware

Note the distinction between time and time: 2020-11-22T12:31:37.696z moment; 1000ms is the time. The system initialization moment comes from RTC, and the subsequent moments come from the calculation of time + time

Stone heart

At the hardware level there are two main modules: CMOS and CPU. CMOS can continue to vibrate and update RTC time after power failure. After CPU is powered on, the TSC register can record the summation of cycles after power on, whose essence is just a Counter of +1 after receiving high voltage.

In Frequecy, the operating system can obtain RTC, TSC, and Frequecy. In Frequecy, the system time can be calculated as RTC + TSC/Frequency

Hardware defects:

CMOS: RTC is the time when the entire system is initialized, but its accuracy is low in milliseconds, so it is difficult to align multiple machine clocks in milliseconds

TSC: Although the ACCURACY of TSC can be at the level of nanosecond, it can only record the time after power-on. TSC uses 64-bit storage, and at 10GHz, the overflow time is 2**64/(1E10 *3600*24*365)≈58Y

Note the distinction between time and time: 2020-11-22T12:31:37.696z moment; 1000ms is the time. System initialization time comes from RTC, so system time = initial time + time.

The guardian

ClockSource is an abstraction from the hardware TSC, and the cycle in the TSC register can be read by the read method and then assigned to itself, although it lags behind the actual TSC until the read method is called.

At present, the highest precision hardware: TSC > HPET > ACPI_PM, they are all time recorders, which store cycle.

#$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
tsc hpet acpi_pm 
#$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc
Copy the code

The main job of TimeKeeper is to actively call read in ClockSource, and then convert cycle to timestamp (time to time conversion) and record to itself. The operating system reads the time from TimeKeeper.

Housekeeper faults:

TimeKeeper is just an abstraction of time, and there is no way to implement automatic updates of time, requiring external calls for updates, so time lags behind real TSC.

Timing of the dog

Both ClockSource and TimerKeepr are abstractions of numbers and cannot be actively updated. Therefore, in order to keep time in real time, a program constantly calls read to update the time.

Combined with the contents of timer: Stone heart, a self-renewing time prototype might look something like this:

while(true) { const cycles = TimeKeeper.ClockSOurce.read(tsc); const now = TimeKeeper.setTimer(cycles); if (now ! = 'double 11') {schedule(); // Let the CPU do something else, and wait for the update time, after all, time is not food}} discount ();Copy the code

The problems of this timer are as follows: The CPU callback time cannot be controlled and may time out. Frequent CPU scheduling.

Software and hardware must cooperate with each other, the above problems are unavoidable without hardware support, so it is necessary to introduce a very sophisticated hardware APIC advanced programmable interrupt control.

At present, the most amazing APIC is: LAPIC – Deadline, and ClockeEventDevice is an abstraction of APIC hardware.

#$ cat /sys/devices/system/clockevents/clockevent0/current_device 
lapic-deadline
Copy the code

It is awesome because it is a timer itself: you can give an APIC a timed cycle number and send an event when cycles in TSC reach that number.

With events (notifications) based on cycle(precision), it is no problem to implement a high-precision timer; Low – precision timer can also be simulated by high – precision timer.

conclusion

  1. The RTC in CMOS provides the initialization moment
  2. Crystals in CMOS provide oscillations
  3. The TSC register in the CPU only records the cycle number of oscillations since power-on
  4. An APIC in a CPU can generate events according to a preset cycle

Hardware and software complement each other. What needs efficiency support is supported by hardware, and in the absence of hardware, it can be simulated by software.

Follow my wechat official account “SUNTOPO WLOG”, welcome to leave a comment and discuss, I will reply as much as possible, thank you for reading.