Latency difference between posix & non-posix timer

Latency difference between posix & non-posix timer

[Ran Shalit]

Hello,

We made some testing on out cpu, installed with 4.1.15-rt17 kernel,
and we observed significant difference in latency between posic to
non-posix cyclictest benchmark.

with non posix we reach max ~50usec
while with posix we reach max ~170usec

On checking the exaples in cyclic test wiki, it seems that the
difference should not be that big :
https://rt.wiki.kernel.org/index.php/Cyclictest

What is the reason for such difference in behaviour ?
Does it mean we better use non-posix timer in application ?

kernel version
==========
user@user-desktop:~/rt-tests-1.0$ uname -a
Linux user-desktop 4.1.15-rt17mah #6 SMP PREEMPT RT Wed Dec 23
20:12:08 CET 2015 x86_64 x86_64 x86_64 GNU/Linux

cpu information
==========
user@user-desktop:~/rt-tests-1.0$ cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 55
model name    : Intel(R) Atom(TM) CPU  E3815  @ 1.46GHz
stepping    : 9
microcode    : 0x903
cpu MHz        : 1463.000
cache size    : 512 KB
physical id    : 0
siblings    : 1
core id        : 0
cpu cores    : 1
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt
tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch arat epb dtherm
tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
bugs        :
bogomips    : 2930.40
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management:

Best Regards,
Ran

Re: Latency difference between posix & non-posix timer

[Sebastian Andrzej Siewior]

On 2017-02-05 19:11:01 [+0200], Ran Shalit wrote:
> Hello,
Hi,

> We made some testing on out cpu, installed with 4.1.15-rt17 kernel,
> and we observed significant difference in latency between posic to
> non-posix cyclictest benchmark.
> 
> with non posix we reach max ~50usec
> while with posix we reach max ~170usec
> 
> On checking the exaples in cyclic test wiki, it seems that the
> difference should not be that big :
> https://rt.wiki.kernel.org/index.php/Cyclictest
> 
> What is the reason for such difference in behaviour ?
> Does it mean we better use non-posix timer in application ?
As written in the other thread (regarding posix-timer):
I tested today v4.9-RT and didn't notice such high spikes between
clock_nanosleep and the posix timer. You have the consider that the
wakeup happens from ktimersoftirq so you have one additional context
switch here.
I general the clock_nansleep interface should be preferred if possible
to avoid that ctx switch.

Sebastian

Re: Latency difference between posix & non-posix timer

[Ran Shalit]

On Wed, Feb 15, 2017 at 7:12 PM, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2017-02-05 19:11:01 [+0200], Ran Shalit wrote:
>> Hello,
> Hi,
>
>> We made some testing on out cpu, installed with 4.1.15-rt17 kernel,
>> and we observed significant difference in latency between posic to
>> non-posix cyclictest benchmark.
>>
>> with non posix we reach max ~50usec
>> while with posix we reach max ~170usec
>>
>> On checking the exaples in cyclic test wiki, it seems that the
>> difference should not be that big :
>> https://rt.wiki.kernel.org/index.php/Cyclictest
>>
>> What is the reason for such difference in behaviour ?
>> Does it mean we better use non-posix timer in application ?
> As written in the other thread (regarding posix-timer):
> I tested today v4.9-RT and didn't notice such high spikes between
> clock_nanosleep and the posix timer. You have the consider that the
> wakeup happens from ktimersoftirq so you have one additional context
> switch here.
> I general the clock_nansleep interface should be preferred if possible
> to avoid that ctx switch.
>

I understand, Thank you a lot.
Ran

> Sebastian