Improving idle behavior in tickless systems
Improving idle behavior in tickless systems
Posted Jan 2, 2019 7:33 UTC (Wed) by flussence (guest, #85566)In reply to: Improving idle behavior in tickless systems by rweikusat2
Parent article: Improving idle behavior in tickless systems
>And this is simply not true. A NIC will generate interrupts in response to uncontrollable, external events for both sending and receiving. The same is true for any other kind of interrupt-using device not driven by the computer itself.
Input devices are some of the most predictable, actually. A pointer interrupt is statistically almost certain to be followed by another (thanks to Newton's laws of physics), and at regularly spaced intervals (grep MOUSE_DPI /lib/udev/hwdb.d/70-mouse.hwdb). A keyboard key down event is often followed by a corresponding key up a few milliseconds later, or some action on a known timeout.
Input devices are some of the most predictable, actually. A pointer interrupt is statistically almost certain to be followed by another (thanks to Newton's laws of physics), and at regularly spaced intervals (grep MOUSE_DPI /lib/udev/hwdb.d/70-mouse.hwdb). A keyboard key down event is often followed by a corresponding key up a few milliseconds later, or some action on a known timeout.
Strong assumptions can also be made about network interrupts due to the earliest departure time queueing algorithm, wifi packet intervals, characteristics of low-spec consumer ISP hardware, timer quantization everywhere else in the stack. I just left wireshark open for a minute and saw several flows with regularly spaced packets.
Algorithmically generated inputs are really not good sources of entropy, if they were servers wouldn't need hardware RNGs.
