Non-Deathmatch: Preempt v. Low-Latency Patch 178
LiquidPC writes: "In this whitepaper on Linux Scheduler Latency, Clark Williams of Red Hat compares the performance of two popular ways to improve kernel Linux preemption latency -- the preemption patch pioneered by MontaVista and the low-latency patch pioneered by Ingo Molnar -- and discovers that the best approach might be a combination of both."
More serious player in the shadows (Score:3, Interesting)
One good way to reduce kernel latency.. (Score:5, Interesting)
One thing not mentioned so far is that one of THE largest scheduler latency problems comes from the driver for a PS/2 mouse, a very common item to be found plugged into servers which have no need for it. By removing the PS/2 mouse (and driver..) a significant latency improvement can be gained!
It's a pity that most USB mice don't seem to provide quite the quality of use as the PS/2 items (although this is probably also a driver issue)
Loy latency can be an advantage, but it is important that the cost of the lower latency is not an increase in total load, as in reality the lower latency does not provide a large gain in performance for most desktop or server roles, but rather is a measure more often used in real time systems, which it can make the difference between a system working or not.
An example of this is in an ignition ECU for a V12 engine at 6000 RPM, a (pair of) plug is firing every 1/600th of a sceond (1.66ms), but the accuracy of the firing even must be in the order of 10us, which is not yet reachable be any 'standard' unix kernel, but quite easy to get on a much simpler ECU (I use an SH-2 at 24 MHz) than you would notmally find using a true real-time kernel.
With some developments is may be possibly for a form of linux to reach this level, which would be fantastic, as a LOT of time is spent in embedded development providing 'operating system' level functionality around the actual application code, and with embedded processors getting faster, and memory getting cheap, embedding *nix has become much more of a possibility.
Re:What's up with the degrading performance? (Score:4, Interesting)
It's called a bug - they'll figure it out.
it's not acceptable to reboot the machine every day to maintain performance
Hey, it worked for NT4 admins, why not for embedded developers? *rimshot*
Sorry. But seriously, anyone looking for hardcore low latency in Linux right now for systems that need that buzzword compliant "five 9's" should probably wait on using Linux until it's READY. Make no mistake, with as much interest and developer hours as are going into it, Linux WILL make it into this market, and it will succeed; it's merely a matter of time. (and hell, at this rate, it may not be long...)
Measuring latencies? (Score:3, Interesting)
Re:The Linux kernel preemption project (Score:1, Interesting)
Pretty shameful for
Re:QNX vs. Linux (Score:2, Interesting)
All times given below are in microseconds (sec).
Processor_______Context____Interrupt Latency
Pentium/133_____1.95_______4.3
Pentium/
486DX4__________6.75______
386/33__________22.6_______15
With nested interrupts, these interrupt latencies represent the worst-case latency for the highest priority interrupt. Interrupt priority is user-definable and the interrupt latency for lower-priority interrupt sources is defined by the user's application-specific interrupt handlers. "