Slashdot Mirror
Juggling Molecules with Linux
An anonymous reader writes "This article at LinuxDevices.com describes an interesting project at the University of Vermont in which researchers use real-time Linux to build a laser trap that manipulates individual molecules by means of a computer-controlled laser beam. The project makes use of RTLinux, a real-time enhanced version of Linux that allows the system to process interrupts every 50 microsecond, sample new data, and timeshare the laser beam position. 'If the computer failed to respond, for even a millisecond, then we would drop the balls,' explained one of the researchers. Gives a whole new meaning to BSOD, eh?"
When it's juggling a molecule, a bowling ball, and a chainsaw, then I'll be impressed;-)
If brevity is the soul of wit, then how does one explain Twitter?
Because this is Slashdot.
The slam on Microsoft is compulsory.
____
~ |rip/\/\aster /\/\onkey
I know several researchers who have been using realtime Linux on the desktop while performing studies regarding the user experience of systems with minimal latency. Their preliminary findings are that users much prefer the instantaneous response that a realtime system offers, even if the system does not perform as well when it comes to raw data crunching. For future desktop systems, heavily multithreaded, realtime apps are the way to go.
Cyric Zndovzny at your service.
yes, and TFA is wrong they're actually using MS Linux which includes the BSOD feature. Also all the operators are clad in blue body paint and if the molecule is dropped a huge blue screen falls from the sky and crushes them to death.
air and light and time and space
I was under the impression that the whole idea of a laser trap is that you CAN'T drop the ball. Small particles get trapped in the beam due to photon pressure, if the particle shifts away from the center of the beam, it automatically is recentered. Then you can move the beam to manipulate the particle which is attached to a molecule. They use these to fold and unfold proteins, lipid layers, DNA, etc.
I mean, it's great that they're using a realtime kernel, but they really shouldn't NEED it.
-- sometimes AND gates turn me on.
[note to mods: If you don't get the joke you should read the other headlines on today's index]
;-)
Should read:
"World's fastest Linux-based laser trap"
Fedore Core 3 comes with an application for juggling molecules. It's called "katomic". It actually allows one to assemble molecules from its constituent atoms. The miracles of modern science never cease to amaze me.
The lunix is on the grass
The lunix is on the grass
Remembering games and daisy chains and laughs
Got to keep the lunix on the path
-- Fink Ployd.
Oh well, what the hell...
For a 200MHz Pentium (this is an old review), the testers tried sending one billion interrupts with a latency check. When they required 8 microsecond latency, they missed one interrupt in a billion. When they only needed 10ms latency, they didn't lose any.
Comparable figures are available for various real-time Linux systems. Note that these figures are for a 650MHz CPU. The times are slightly better than for QNX, but the CPU is 3x faster.
Bear in mind that "RTLinux" programs aren't running under Linux. They're running below Linux. They can't make most system calls, for example. QNX programs are ordinary programs, and can make system calls.
The Linux 2.6 kernel isn't bad, though. Running real-time with millisecond response as high-priority Linux threads can actually work in 2.6. In 2.4, no way. You have to be very careful not to load any high-latency drivers, though.
I don't dispute your friends' findings, but I'm wondering why a RT based OS would really improve the user experience?
Here's why I ask: A RT system is typically real time for some dedicated purpose. Not all pieces of the system have to be RT; just the important bits. Now, an average user PC is NOT a specialized device at all. It can be running a number of applications and, except for cases where a given process has a higher priority, all the processes typically get an opportunity for equal time from the CPU. A desktop system with a RT OS would also fit this description too, right?
Now, given that: where's the RT aspect in all of this? What's actually RT in this situation? The pre-emptive multitasking loop? The UI event/response loop? The IO loop (assuming you could describe it that way)? The video update loop? What about this would give the user a better experience?
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
If you ever had to perform real time processing using Microsoft Windows you would regard the comment as kind. Windows employs a constant blizzard of interupts which makes response times unpredictable at this scale.
Actually the BSOD is the least of the problems, with lags and leads being the primary problem.
Yes 1 millisecond is pretty slow. On the Atari 2600 we used to meet a .84 microsecond timing requirement with a 1.19 MHz processor.
In any case I don't think many people on Slashdot understand that tough, classical real-time software can't really run on a PC (or Pentium processors for that matter) no matter what OS is used.
The key to real-time software isn't speed, it's deterministic timing. Once you have a cache involved, it's pretty much game over. Unless, of course, your timing requirements are several orders of magnitude slower than the time it takes the processor to execute an instruction. In that case the non-deterministic behavior may be swallowed up by the large gaps between real-time events.
Nevertheless there may still be the possiblity of memory management accessing the disk and blowing your timing away.
How interesting. I just saw a lecture by one of the men that won a nobel prize for this very thing, Steven Chu. What is being done here is essentially what is called Optical Tweezers.
The way this works is that the laser is fired, in timed pulses at a molecule. When the laser hits it from an opposing direction, it starts to cancel out the kinetic energy that the molecule has, and therefore cooling it. (I think it was something to the order of 2.0 × 10^-06 degrees above absolute zero).
In a nutshell, this is what is going on:
-SteveAlmost Absolute Zero == Essentially No Movement == Essentially "Frozen" Object