[bob1029]

Sub millisecond timing is basically impossible with context switching involved. Even on a real time kernel config, the best you are going to get with a time slice is 1ms.

With busy waiting, you can achieve timings in the sub-microsecond range, depending on how heavy the loop is.

[bitcharmer]

Not sure what you mean by that but nanosecond precise timing across cpu cores have been reliable for quite a while now.

Key words: constant TSC, invariant TSC, TSC clocksource

[tsegratis]

The hardware providing those nanoseconds is not nanosecond accurate (unless using atomic clock)

However they may be more accurate than 1ms. The guy is saying the timeslice given by the OS for a program to run in has at best a 1ms slot because the OS is switching between threads on a 1ms timeslice basis

So unless you're polling, the timing at which you ask the hardware for nanoseconds will jitter with 1ms offsets

[Firmwarrior]

There are a lot of applications in the world that don't run on a regular processor under regular linux

The guy is overgeneralizing IMO. You can delve deep within the sub millisecond world even as a regular dude with a regular computer and a regular OS by just doing everything in an interrupt context

[bitcharmer]

No, TSC on modern CPUs is much more granular that that. No atomic clocks needed, just a normal quartz crystal. This is how ptp works and you can definitely get sub nanosecond accuracy from it. Wrt scheduling quantum, this is entirely configurable and subject to scheduling policy, priorities and additional mechanics such as isolcpus and nohz. GP's comment is just plain wrong.