Jiffies too low for acceptable ppoll accuracy

Hi Kay,

There are a couple of things you could check and/or add here as you provide very little information.

First of all, your kernel, -4, is relatively old. At the moment -16 is the released kernel and -19 is the latest security update. Could you please test with that one?

Could you please add some information about your hardware? And attaching a dmesg would also be good.

Also, the -generic kernel is geared towards desktop usage. So it provides a certain balance between realtime behaviour and throughput. One of these choices involves the preemption model within the kernel. -generic uses the voluntary preemption. You could try the -rt kernels, which have a higher preemption level, which may affect throughput.

I also wonder whether ppoll really is the interface to use. The ubuntu kernels all have high res timers enabled. It is best for you to research the web about how to use these. You should be able to get below microsecond values, IIRC, on relatively modern hardware.

Finally, I'm not sure whether checking an ELF note is the best way to determine the current HZ value of the kernel. First of all, that ps tool also needs to work on older kernels and second because in 2.6 there is no longer a relation between the user space HZ and the kernel HZ.

Umm, should've been more clear perhaps...
Grep for PREEMPT on the ubuntu and redhat kernel configurations (usually located in /boot/config*). Also of interest are then the various HZ related config items (hint grep HZ /boot/config-..).

And a diff between the redhat dmesg and ubuntu dmesg could also be revealing (for example different clock sources). And which version is the RH kernel?

Hello,

please find attached the output of dmesg from the Ubuntu machine. Please ignore the NVidia modules, this is only a recent change that I made, because xserver-xorg-driver-nv started to segfault too badly. The problem existed before. The only other noteworthy difference is that I am using the RT2500 driver, because the RT2x00 that Ubuntu is using for a couple of releases was deeply broken. I can reproduce the issue on machines without both the drivers.

The CPU is Intel Dual Core with 2G RAM. The problem was initially observed on 2.6.22 already, a kernel that I was using longer due to the RT2x00 problem that I got only recently under control.

Hello,

please find attached the output of one of our RHEL machines with comparable hardware. We normally use HP G5 machines, but that is a normal desktop PC with Dual Core too. The claim is that the problem shows relatively hardware independent. I must admit, that we never use the same hardware with RHEL and Ubuntu, but all Ubuntu machines fail the test, all RHEL machines (version 3, 4 or 5) pass it.

Hello,

according the ps sources, the ELF note is the only reliable way to get the hands on the period one jiffy in /proc represents. The issue at hand is that I have implemented lock files that contain a "life" information from a process that is supposed to be unique, by combining the start time and pid (together they will be unique across reboots, provided time is not way off). For that I needed to decode the "started this many jiffies after boot" value of the running kernel. So even if 100Hz is not correct, for the decoding that value must be had:

It seems Ubuntu is in fact using:

CONFIG_NO_HZ=y
CONFIG_HZ=250
CONFIG_HZ_250=y

My understanding of tickless is not that you achieve a higher granularity for scheduler sleeps that 4ms, but it would mean not every tick must be performed, but instead multiple can be done at later wakeup, mostly only relevant for idle machines, isn't it?

That maches the values I measure, waking up <4ms too late.

On RHEL they appear to be using:

CONFIG_HZ_1000=y
CONFIG_HZ=1000

And that matches the <2ms obversation fine too.

What I do not get is why ppoll is using a resolution for the wake up time of nanoseconds, when in fact little more than 1ms can actually be had anyway. May have its uses when the CPU slice from scheduler is used up, and we want to wake up with values below 1ms in the future, to not have to round up. Other than that I would be confused.

With nanosleep or things from hrtimer.h, I could try to use poll on the monitored file handles, but I am wondering if the scheduler will not still limit me. I am going to make a prototype implementation that is going to use poll with 0 timeout and small nanosleeps (100us e.g.) in between to avoid busy loop. May work and would be a nice improvement. But why wouldn't ppoll already do that?!

About the desktop tuning of generic. Indeed. For a desktop machines low latencies should be easy to achieve, for a server that's not normally needed. I will try the -rt kernel if that nanosleep trick doesn't work, our goal is to not require too much about the used kernel.

Yours,
Kay Hayen

Kay,

With RHEL 1000Hz I would expect <1ms delays. So there's something funny as well.

As for ppol using ns precision to specify the timeout is the future. Otherwise you end up changing the interface every 2 years (due to Moores law).

As for your unique key, you could simply use the uptime. That starts counting at startup. (see man sysinfo)

Your last paragraph really is key, I guess. You want standard packages, yet achieve low latency.

Given the above, I don't think this is a bug in the kernel. The kernel configuration was consciously decided upon by the Ubuntu kernel team. What you are seeing is due to that decision.
So I'll convert it into a question and we can continue there.

The reporter is having expectations from the kernel which are not satisfied.
In this case that (realttime) behavior is for a large part defined by the kernel configuration. And that has consciously been decided upon by the kernel team.

As such not a bug.
However, we do not need to let the reporter down and can still help him achieve his goal.

Kay,

Would you mind commenting here and/or mark it as solved/answered?

Thanks.

Hello Jan,

did you see my comment on:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/252728/comments/8

I wasn't aware that the question is not just the bug with a different status, sorry for posting there.

In general, I agree, it's not a bug, it's more like what can I do to improve the documentation or glibc possibly.

Yours,
Kay Hayen