Slashdot Mirror
Andrew Morton And The Low-Latency Kernel Patch
An Anonymous Coward writes: "KernelTrap has interviewed Linux kernel hacker Andrew Morton, author of the low-latency patch. Though his patch has received less attention than Robert Love's preemptible kernel patch (recently merged into the 2.5 kernel), it results in quite significantly lower latencies. The interview is quite interesting, delving into the low-latency patch, explaining how it works and the differences between it and the preempt patch. He also talks about his ext3 work, porting that journaling filesystem from the older stable 2.2 kernel to the current stable 2.4 kernel."
I really like reading things like this.
That's why Linux is so great -- even if you're not good enough to work on the kernel, you can read about some of the issues that pop up. If you use Linux for awhile, and if you get to the point where you roll your own kernels and apply patches, you end up learning a lot about how the system works.
The MS guys are smart, and they're making some good systems now, but you can spend your whole life with them and not have much of a clue about what's going on under the hood.
If MS would open up their internal developer discussions to the public, it would take MS system administration to a whole new level. I understand why they can't do that, but it is a great example of what's nice about Linux.
The difference is that hard real time doesn't mean low latency it just means that there is a _guaranteed_ maximum latency.
Soft real time means that you can almost gaurantee the latency. Generally, of course, you want these latencies to be pretty small. Soft real time is for when you use check the "use real time where available" option on xmms and run it under sudo.
I hear that Linux (probably with patches) is a little better than windows and a little worse than os X for latency.
"The low-latency patch yields worst-case latencies of around 1.5 milliseconds at present. The preempt patch is around 80 milliseconds,
but with the locking changes it should also yield 1-2 millisecond latencies." On what speed processor? 1.5ms is way too long for any kind of processor being sold these days. Try 100us maximum latency on a 133Mhz Pentium for starters and go down from there. And learn to use the term "deterministic" and I might raise an eyebrow. Make it POSIX 1003.1 compliant and someone will have a serious solution.
Programmers either need deterministic response in their applications or they don't. If they do, then Linux is not their OS. If they don't, then these half-baked solutions to reduce context switching time and interrupt latency are probably going to be fun to play with, but will cause nightmares in the long run.
This is quite funny from a social psyc perspective. Geeks have a superiority complex as is often seen here on /. Sometimes, you'll see a thread that goes down 60 deep, and it's just two guys arguing back and forth. Us geeks have a tendency to rail on and on about obscure things, showing off, telling each other we're wrong, etc. We do that because it makes us feel smarter and such. It's not very funny when you're in the midst of it, but when you step back, it's kind of amusing, really.
I used to have a severe problem with my machine becoming unresponsive and pausing for 10 seconds at a time while the buffers where synced. Then one day I was inspired to type
/dev/hda; hdparm -d 1 /dev/hda ; hdparm -t /dev/hda'
:) (Went from 2- MB/sec to 27+ MB/sec)
...but I'm not saying how long that realization took ;)
hdparm -t
Suddenly a dim bulb brightened and I saw the light
It's even more hilarious if you only knew how long I has unaware that the DMA/32bitIO/etc would never save of a reboot. Then how I never even thought about how slow my hard disk was working when I know that IDE can easily do 25+ MB, I say it's hilarious!