Performance differences between nanosleep and /dev/rtc

I've been converting the main loop of an embedded linux program to run on a server and one of the nice to haves will be to run non-root. The program is in charge of periodically requesting an IO scan from a network device - every 2ms. Today I replaced the use of /dev/rtc with a call to nanosleep. In this particular case we can get away with plenty of latency but I'm wondering if the nanosleep call can be left in for the case when we're running on the embedded device with more strict timing requirements (which is the case for bigger projects). Is there a big difference in performance?

It depends on the Linux kernel version. From the time(7) manpage:

   High-Resolution Timers
       Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the
       size of the jiffy.

       Since  Linux  2.6.21,  Linux supports high-resolution timers (HRTs), optionally configurable via CON‐
       FIG_HIGH_RES_TIMERS.  On a system that supports HRTs, the accuracy of sleep and timer system calls is
       no  longer constrained by the jiffy, but instead can be as accurate as the hardware allows (microsec‐
       ond accuracy is typical of modern hardware).

Note: "jiffy" is the timer tick frequency mentioned in the answer by "Greg". Also note that the system calls that this refers to includes nanosleep().

That is, if you have a recent enough version of the kernel on your embedded target, nanosleep() should be good enough. If you have an older kernel version, you're indeed limited by the clock tick frequency, and in that case you might have problems as 2 ms is quite close to the 1 ms tick frequency with CONFIG_HZ=1000.

Man-page for nanosleep suggests that kernel-timers are used, making it sensitive to the value of "HZ" (the kernel "tick"). The tick is commonly 1000HZ (1ms), however for an embedded system this value may not necessarily be the same, you can configure it with kernel parameters depending on what timing sources you have available.

Since /dev/rtc uses interrupts it doesn't tie you to HZ so timing could be more sensitive. Of course that also depends on your RTC hardware.

If in doubt, make a thin abstraction which lets you set a time and pass a callback so you can switch between implementations, and as always with embedded systems - measure it on the real device.