×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Juggling Molecules with Linux

CmdrTaco posted more than 9 years ago | from the look-ma-no-hands dept.

Operating Systems 111

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?"

Sorry! There are no comments related to the filter you selected.

omg omgomgomgfriiirst possst!! (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12759256)

winnnnna

Why do we have this statement? (1)

bogaboga (793279) | more than 9 years ago | (#12759266)

[...] Gives a whole new meaning to BSOD, eh?

I do not see why.

Re:Why do we have this statement? (1)

Changa_MC (827317) | more than 9 years ago | (#12759279)

Well, is it a blue laser?

Re:Why do we have this statement? (4, Funny)

PopeAlien (164869) | more than 9 years ago | (#12759364)

yes, and TFA is wrong they're actually using MS Linux [mslinux.org] 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.

Re:Why do we have this statement? (3, Funny)

TripMaster Monkey (862126) | more than 9 years ago | (#12759283)


Because this is Slashdot.

The slam on Microsoft is compulsory.

Re:Why do we have this statement? (2, Insightful)

MarkByers (770551) | more than 9 years ago | (#12759386)

I don't think it's paticularly a 'slam on Microsoft'. Imagine if the system crashed while a moecule was half-constructed and you had to reboot and start all over. Use the right tool for the right job.

There's nothing wrong with Windows as a games machine and for light word processing, but it's not suitable for everything. Maybe the submitter could have expressed themselves better.

Re:Why do we have this statement? (1)

aardwolf64 (160070) | more than 9 years ago | (#12759482)

Yes, but what on earth does Microsoft have to do with this story? TFA doesn't even mention Microsoft... The commenter you replied to had it right. This is Slashdot, so any bashing of Microsoft in your post submission increases the chance that it will be posted.

Microsoft oppose Linux (1)

MarkByers (770551) | more than 9 years ago | (#12760293)

I think he was trying to say to the Slashdot audience, 'Stop saying Microsoft is x times better than Linux and therefore Linux should die. Look here! Here's something that we need Linux for, we could not have done this with Microsoft.'

In other words, it is good that Linux exists for specialist projects and any attempt to ban Linux (eg. by patenting algorithms used in the Linux kernel and making it illegal to distribute) would have harmful effects on society, making these sort of experiments much more difficult/impossible.

Allow alternatives to Microsoft exist. Oppose efforts to make Linux illegal (via software patents for example). Do this even if you think personally Linux sucks. Other people will thank you.

Welcome to our reality (1)

ClosedSource (238333) | more than 9 years ago | (#12762189)

Is it really true in your reality that Slashdotters say that "Microsoft is x times better than Linux"? Or is x less than 1?

Mod Parent Up (1)

MyLongNickName (822545) | more than 9 years ago | (#12759402)

+100 Insightful

Re:Why do we have this statement? (4, Informative)

monopole (44023) | more than 9 years ago | (#12759858)

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.

Re:Why do we have this statement? (1)

Kiryat Malachi (177258) | more than 9 years ago | (#12760499)

Of course, vanilla Linux isn't really any better at doing well-timed interrupts.

Re:Why do we have this statement? (1)

Mr2cents (323101) | more than 9 years ago | (#12759996)

Are you saying we Slashdotters have a reflex to bash MS even if there's no real cause? That sound almost as stupid as Clippy's nonsense! Because, you have to agree on this, Clippy is pretty stupid.

Re:Why do we have this statement? (0)

Anonymous Coward | more than 9 years ago | (#12759431)

Simple. The molecules that they're moving around are made of jumbonium, an element so heavy that one nanogram of it weighs a hundred million tons.

Don't want to drop it. :)

Re:Why do we have this statement? (0)

Anonymous Coward | more than 9 years ago | (#12760049)

...an element so heavy that one nanogram of it weighs a hundred million tons. wouldn't a nanogram weigh... a nanogram? :P

Re:Why do we have this statement? (2, Funny)

maxwell demon (590494) | more than 9 years ago | (#12759720)

BSOD = Ball Shouldn't Occasionally Drop. I've never seen this meaning before, so it's new. Of course it has nothing to do with Windows (you didn't think it had, did you?) ;-)

Re:Why do we have this statement? (1)

bogaboga (793279) | more than 9 years ago | (#12759788)

Of course it has nothing to do with Windows (you didn't think it had, did you?) ;-)

Of course I thought it's the infamous Windows native Blue Screen of Death! Any query among computer users on this will support me on what BSOD stands for.

Re:Why do we have this statement? (2, Funny)

maxwell demon (590494) | more than 9 years ago | (#12760056)

Of course I thought it's the infamous Windows native Blue Screen of Death!

But that wouldn't have been a whole new meaning!

Re:Why do we have this statement? (0)

Anonymous Coward | more than 9 years ago | (#12760021)

obligatory dean scream
yeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah

Re:Why do we have this statement? (1)

eno2001 (527078) | more than 9 years ago | (#12760998)

You're right. It should be a kernel oops. Or more likely a nucleic oops. (Not Nukyelaeic as you "nukyelar" idiots should be saying)

Finally Linux... (3, Funny)

PlancksCnst (877593) | more than 9 years ago | (#12759269)

...is doing something useful. Just kidding! Don't kill me. Mod Flaimbait, please

DOS (1)

goombah99 (560566) | more than 9 years ago | (#12759362)

Why not just use DOS or mac OS 8. Seriously. For instrument control you want your program running and screw everything else. Modern OS are the bane of instrument control, even so-called RT systems. They just seem to go out to lunch every now and then.

Re:DOS (1)

over_exposed (623791) | more than 9 years ago | (#12759555)

If you had read the summary you would have answered your own question. RT linux handles interrupts much faster than any other OS. If they lose control of the laser, they have to start over.

Re:DOS (0)

Anonymous Coward | more than 9 years ago | (#12759614)

And if you understood goombah's post, you'd shut your useless yap when you have nothing to contribute.

Re:DOS (1)

RWerp (798951) | more than 9 years ago | (#12760835)

I know that many people who program computers to run their laboratory hardware do it with DOS. It's easy and efficient. I imagine these guys had a reason to switch to Linux, maybe the efficiency was too low or they needed modern development tools.

Meh (5, Funny)

Shadow Wrought (586631) | more than 9 years ago | (#12759275)

When it's juggling a molecule, a bowling ball, and a chainsaw, then I'll be impressed;-)

Re:Meh (0)

Anonymous Coward | more than 9 years ago | (#12759393)

Dear sir,

Your weak attempt at humor is factually inaccurate.
It is a well-known given in the juggling trade, or "juggling" as we like to call it, that it is impossible to juggle things of widely disparate sizes. So although a bowling ball and a chainsaw are on the same order of magnitude in size & weight, obviously a single atom is not. (Of course you have to account for whether the chainsaw is running or not.)

So, in conclusion, I would like to leave you with the following thought:

YU0 FA1L 1T!

Re:Meh (0)

Anonymous Coward | more than 9 years ago | (#12759782)

Hell, I've seen someone juggle a bowling ball and a bowl of flour at the same time. And about three other things.

Granted, they had m4d sk33ls. But still.

Re:Meh (1)

null etc. (524767) | more than 9 years ago | (#12760416)

Hell, I've seen someone juggle a bowling ball and a bowl of flour at the same time. And about three other things.

That wasn't flour, it was cocaine! Why do you think he was doing it?

It's a trap! (0)

Anonymous Coward | more than 9 years ago | (#12759277)

move the fleet away from the death star!

Lunix! (0)

Anonymous Coward | more than 9 years ago | (#12759287)

we would drop the balls

Holding the balls. The perfect job for Lunix. It's the Lunix Gay Conspiracy all over again!

Re:Lunix! (0, Troll)

pocketfullofshells (722066) | more than 9 years ago | (#12759376)

Lunix? Sounds like a terrible disease that rots off your testicles.

Re:Lunix! (0)

Anonymous Coward | more than 9 years ago | (#12759412)

Well, in all fairness, the balls only drop if it stops responding every 50 M$ bashes.

Re:Lunix! (1)

50000BTU_barbecue (588132) | more than 9 years ago | (#12759631)

I certainly hope not! [sourceforge.net]

The Lunix are on the grass! (3, Funny)

HermanAB (661181) | more than 9 years ago | (#12759616)

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.

Still not modded down? (1)

Enoch Lockwood (889602) | more than 9 years ago | (#12761822)

Uh. "Lunix"?

Are you sure you're on the right site, buddy?

Re:Lunix! (1)

wmorrow (16909) | more than 9 years ago | (#12762693)

Reminds me of the radio sports guy describing our quarterback in last night's game: It was beuatiful, how his balls fly around the field with a tight spiral.

Incomplete quote (1)

IO ERROR (128968) | more than 9 years ago | (#12759289)

RTLinuxPro [fsmlabs.com] is used to control the laser beam positions, as well as to sample the output of measuring devices. At the core of the software is a kernel-side module that interrupts every 50 microsecond, samples new data, and timeshares the laser beam position. "If the computer failed to respond, for even a millisecond, then we would 'drop' the balls," explained Warshaw [uvm.edu] , "but RTLinuxPro is rock solid."

Not really... (1, Funny)

avalys (221114) | more than 9 years ago | (#12759304)

I think it gives a whole new meaning to the phrase: "don't drop the ball!"

Re:Not really... (1)

TheFlamingoKing (603674) | more than 9 years ago | (#12759591)

I think it gives a whole new meaning to the phrase: "My balls just dropped!"

Dr. Torvalds... (2, Funny)

Tackhead (54550) | more than 9 years ago | (#12759315)

> 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

Dr. Torvalds: You know, I have one simple request... and that is to have penguins with frickin' laser beams attached to their heads. Now evidently, my megaloptic Naval colleage informs me that IT'S A TRAP!

/one ticket to hell please.

Realtime Linux on the desktop. (5, Interesting)

CyricZ (887944) | more than 9 years ago | (#12759331)

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.

Re:Realtime Linux on the desktop. (3, Informative)

akozakie (633875) | more than 9 years ago | (#12759450)

That's also the main selling point for desktop dual-core chips - without a realtime OS the second processor keeps the GUI running smoothly even under load. I sometimes use my friend's old dual Pentium 300, and under load it actually feels marginally faster than my (way faster) single chip Athlon. If the price, noise and energy consumption weren't so high I'd buy one for home use - and dual core may be the solution to those problems (plus, dual-core notebooks are a possibility, dual-chip - hardly). I also worked with QNX - nice...

In short - I want realtime Linux on my desktop NOW! I wish I wasn't that lazy and would actually do something about it...

Re:Realtime Linux on the desktop. (0)

Anonymous Coward | more than 9 years ago | (#12759549)

This is where highly multi threaded chips will come into play in the future. Like IBM's Cell and Sun's Niagara.

Re:Realtime Linux on the desktop. (2, Interesting)

Anonymous Coward | more than 9 years ago | (#12759617)

http://www.love-sources.org/news.php [love-sources.org]

Linux 2.6 kernel with RT patches amongst other low-latency desktop improvements.

Re:Realtime Linux on the desktop. (0)

Anonymous Coward | more than 9 years ago | (#12759652)

. Their preliminary findings are that users much prefer the instantaneous response that a realtime system offers,

What? Users like fast systems? What a breakthrough study!

Re:Realtime Linux on the desktop. (3, Insightful)

digidave (259925) | more than 9 years ago | (#12759690)

"What? Users like fast systems? What a breakthrough study!"

No, it turns out that users actually prefer trading off calculation speed for a quicker GUI. So even if doing a major spreadsheet export takes a few seconds longer, it's the speed of the menu, resizing windows, etc that makes a difference to them.

Not sure about this.. (4, Interesting)

Da VinMan (7669) | more than 9 years ago | (#12759805)

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?

Re:Not sure about this.. (1)

ClosedSource (238333) | more than 9 years ago | (#12760078)

I think people are confusing real-time with "as fast as a bunny".

A truly real-time system can actually be slower because even if it's ready to respond, it still has to wait until the appropriate time to do so. It like batting in baseball: swinging too early is just as bad as swinging too late.

Re:Not sure about this.. (2, Insightful)

BGA (28170) | more than 9 years ago | (#12760101)

Being RT means it has predictable response times. If some specific operation is said to take 10 ms to complete you can count that as being always true and this is what makes RT systems special. That's why it would be *VERY* difficult to have a "partial" RT system like what you decribe. Either it is RT or it is not.

That said, recently we had some flexibility on the Rt definition and we ended up with definitions for systems that are "hard RT" and "soft RT". The first case is what I described (QNX is hard RT, for instance). The second one is a system that provides extremelly low latency times but they are not really predictable, although the average time is (BeOS - now Zeta - is said to be soft RT).

Re:Not sure about this.. (1)

Dan D. (10998) | more than 9 years ago | (#12760424)

the UI event loop. On the process in focus (or wherever the mouse goes so that when you click there is zero perceived time between when you clicked and when the action takes effect.)

For everything else, standard latencies are more than enough (like if you're watching a video in a window in the upper right corner, that's probably not going to skip just because the UI event loop is kicking in, and if it did the user still prefers to get the fast action response because that's where his/her attention is.)

Re:Not sure about this.. (0)

Anonymous Coward | more than 9 years ago | (#12761189)

Well, the amiga UI always had instant visual feedback. That was most important, to prevent users hammer-clicking. A button IMMEDIATELY (well next 1/50th sec frame update) became "pressed", and stayed pressed until the action it initiated completed or failed.) EVERY OTHER GUI IN THE WORLD I'VE EVER SEEN gets this wrong.

Re:Not sure about this.. (1)

Kafteinn (542563) | more than 9 years ago | (#12761989)

If it is possible I would love to be able to somehow choose which parts of the OS have RT priority. So I could for example choose to only give the parallel port or specific applications RT priority and control servo motors on my desktop, make a crude oscilloscope or Real Time Halflife :) does anyone know if this is possible?

Re:Not sure about this.. (0)

Anonymous Coward | more than 9 years ago | (#12762733)

renice -20 12345

Still waiting for ... (1)

guyfromindia (812078) | more than 9 years ago | (#12759336)

Linux based sharks with frickin' laser beams on their heads....

Re:Still waiting for ... (1)

guyfromindia (812078) | more than 9 years ago | (#12759365)

Oh! Well.. redundant... somebody beat me! :-)

Re:Still waiting for ... (0)

Anonymous Coward | more than 9 years ago | (#12759447)

I thought redundancy was a good thing?

confuzed :0

(& slightly bored)

For stories, Yes. For comments, No (0)

Anonymous Coward | more than 9 years ago | (#12762113)

It is the way of the Slashdot.

Re:Still waiting for ... (1)

The_Wilschon (782534) | more than 9 years ago | (#12762659)

Linux based sharks with frickin' laser beams on their heads....

Riding on elephants' backs! Just trampling, eating, outcomputing, and laserifying everything they see!

Vanilla & Chocolate (1)

pcnetworx1 (873075) | more than 9 years ago | (#12759355)

From the article: Graphical user interfaces, mouse driven operator interfaces, and data storage are all "vanilla" Linux applications. The laser control program, by contrast, is a relatively straightforward piece of code that collects positioning data and adjusts the laser.

So I guess the laser juggler program would be a "chocolate" Linux application. Mmmm

Victor Yodaiken if a Patenting Pest (2, Informative)

Anonymous Coward | more than 9 years ago | (#12759380)

Victor Yodaiken (who wrote TFA) is the clown who patented his technique for implementing RTLinux. I much prefer RTAI for real-time linux, both because it is IMO a superior implementation, a better license, and it doesn't give support or credibility to Yodaiken.

rtlinux (1)

w98 (831730) | more than 9 years ago | (#12759385)

huh, another contender ... I'll have to check it out. I used to work at QNX [qnx.com] who also make a real-time posix-compliant OS, but it's geared more for embedded systems than desktop use (although it *can* be used on a desktop)

Laser Traps (4, Interesting)

richardmilhousnixon (515595) | more than 9 years ago | (#12759398)

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.

Re:Laser Traps (1)

imsabbel (611519) | more than 9 years ago | (#12759688)

Its not that easy.
Just for your information: the classical picture of a laser trap always presented actually is only a so called optical molasse, it will slow down molecules, but cannot trap them. (its actually quite obvious, think about the balance of force on the particle as its speed aproaches 0... it can be descriped by a modification of the stokes formula for objects in fluids)
For real confinement, you need futher stuff, for example quadrupol coils for a penning type trap, ect.
I dont know what exactly they have working, but its quite possible that they have some kind of feedback loop for their coil management or something like that...

Re:Laser Traps (2, Funny)

kccricket (217833) | more than 9 years ago | (#12759804)

I dunno. I think they'd get better results if they reversed the polarity on their trap coil couplers.

Re:Laser Traps (1)

Phanatic1a (413374) | more than 9 years ago | (#12759709)

ObRTFA: RTFA.

They're timeslicing, using one laser to build multiple traps. So they trap one sphere, then switch to another, then back to the first before it drops.

Re:Laser Traps (2, Informative)

ZagNuts (789429) | more than 9 years ago | (#12759732)

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

From the article:
"In other experiments, researchers use the laser beam to apply minute forces to the beads and to the connected myosin molecule."

They need real time feedback in order to compensate for motion caused by applied forces that might push the molecule out of the focal point of the laser.

They may also be using realtime feedback to continually focus the laser since very small variations can cause changes large enough to drop the molecule (although I believe many of these systems use purely electronic/optical means to do this).

delay tolerance? (1)

moz25 (262020) | more than 9 years ago | (#12759433)

I've made some use of RTLinux myself - one aspect that we got to wonder about is to which extent you can move the controller outside of the computer and into its own embedded device. In this case, it seems that it's the diversity of experiments that is the deciding factor for using the computer.

It is a little odd that they talk about 1 millisecond, when the time between interrupts is 50 microseconds. To miss for "even" 1 millisecond would mean missing 20 interrupts! That's just some hype, IMHO. What I find more interesting (but can't find in TFA) is the tolerance for delay per interrupt: if the interrupts are 50 microseconds apart on average, but sometimes 20 apart and sometimes 70, what is the result for the experiment? I think that that's where you're going to see the real test for RT Linux.

Re:delay tolerance? (3, Informative)

ClosedSource (238333) | more than 9 years ago | (#12759964)

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.

Re:delay tolerance? (1)

RWerp (798951) | more than 9 years ago | (#12760902)

How about turning the cache off?

Re:delay tolerance? (1)

ClosedSource (238333) | more than 9 years ago | (#12762084)

If the processor cache can be turned off, then that is at least one less hurdle. What about processor pipelines, bus locking, etc.? Can they all be disabled?

Any non-deterministic behavior (or deterministic behavior too complex to be considered in a real-time software design) will still trip you up.

Woah! (0)

Anonymous Coward | more than 9 years ago | (#12759443)

Imagine a Beowulf cluster of these things! Anyone up for some 80's style disco dancing with laser beams?

Why use any OS? (1)

cosinezero (833532) | more than 9 years ago | (#12759448)

Sooo... basically they're using an operating system to do what they should have an FPGA perform?

I mean, rah-rah-go-linux... but sounds like a dramatic over-use of power. Why one would use a modern OS to perform tasks that should be handled by dedicated hardware ... is beyond me.

Re:Why use any OS? (1)

HermanAB (661181) | more than 9 years ago | (#12759642)

'Cause its cheaper, 'cause its fun, 'cause they have a shed load of forlorn PCs doing something unspeakable in a dark corner of the lab...

Re:Why use any OS? (0)

Anonymous Coward | more than 9 years ago | (#12759694)

Dude. If your software tools and existing hardware can handle the problem, why waste your time making a special purpose hardware solution (which would also be much less flexible?)

Especially if you know how to work with software and do not know how to work with hardware.

Software is much easier to work with and fix quickly.

Re:Why use any OS? (1)

ArsonSmith (13997) | more than 9 years ago | (#12759960)

One word

"CASH!!"

Software = Cheap/flexable.
Hardware = expensive/rigid even FPPGA.

Wrong title (5, Funny)

Spy der Mann (805235) | more than 9 years ago | (#12759485)

[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" ;-)

RT Linux fast enough for a juggler... (2, Funny)

Anonymous Coward | more than 9 years ago | (#12759521)

...but does it have enough horsepower to generate a mime trapped in a box? I doubt it.

Re:RT Linux fast enough for a juggler... (1)

RM6f9 (825298) | more than 9 years ago | (#12761122)

Next dupe/"follow-up" article on Slashdot: "RTLinux used to laser-trap mimes in boxes"
"Finally, a valid use for Linux" a certain well-known OS development rival group was heard to say - apparently beleaguered by mimes performing outside their Redmond HQ for spare change, the possibilities of trapping mimes in boxes using lasers controlled by RTLinux has intrigued ...(read more)

molecule juggling available with FC3 (3, Funny)

pomakis (323200) | more than 9 years ago | (#12759525)

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.

What if it crashes? (2, Funny)

rice_burners_suck (243660) | more than 9 years ago | (#12759560)

Gives a whole new meaning to BSOD, eh?

You want a BSOD, eh? How about this: You build a gun that has an actuator attached to the serial port of a computer running Windows NT. The computer sends, via the serial port, a watchdog-style "keep alive" signal, say, every 100 microseconds. The actuator is designed such that once powered on, if the watchdog timer skips a single beat or delivers it too late, the gun is fired.

At this time, a volunteer (say, Gill Bates) would be tied to a chair and placed in front of this gun, while the Windows NT system runs Exchange and IIS, and while a user browses pr0n sites via Internet Explorer. This is, actually, quite a safe experiment, as we all know that Windows NT never crashes.

Re:What if it crashes? (1)

HermanAB (661181) | more than 9 years ago | (#12759685)

Some rhetorical questions: Will you use Windows to manage a heart-lung machine? No? So why do you use it to run an Aircraft Carrier? Actually, since I'm not American, I think the US military and the whole government, should use MS Windows exclusively, for everything...

Re:What if it crashes? (0)

Anonymous Coward | more than 9 years ago | (#12760047)

To be a true *BSOD* wouldn't you need to get a Bolian? Or at the very least a member of the Blue Man Group/smurf?

QNX - for really low latency (4, Informative)

Animats (122034) | more than 9 years ago | (#12759628)

Here's what comparable numbers look like for QNX: QNX [ddjembedded.com] .

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. [linuxdevices.com] 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.

Re:QNX - for really low latency (2, Interesting)

imsabbel (611519) | more than 9 years ago | (#12759821)

One question: Typing error on your side? Do you mean 10ms or 10 us?
Because 10ms is hardly a latency to brag about... for any os...

Re:QNX - for really low latency (2, Interesting)

Animats (122034) | more than 9 years ago | (#12759977)

Sorry, 10us.

Re:QNX - for really low latency (1)

brain_not_ticking (722737) | more than 9 years ago | (#12760177)

There's a HUGE difference between 8 microseconds and 10 milliseconds. Do you mean that when they only needed 10 microseconds latency, they didn't lose any?

Re:QNX - for really low latency (2, Interesting)

Animats (122034) | more than 9 years ago | (#12760345)

Yes. When they only needed 10us latency, they didn't lose any. And that was on a 200MHz CPU.

heavy duty research (0)

Anonymous Coward | more than 9 years ago | (#12759639)

"Hey Bob.. over at the University of Vermont we were able to juggle molecules with lasers! Isn't that GREAT?" "Wow, that's awesome Jim.. all my team is working on is that boring old CURE FOR CANCER. Have fun with the laser-linux circus."

I juggle molecules all the time! (1, Funny)

Anonymous Coward | more than 9 years ago | (#12759736)

I juggle molecules all the time - In fact, I never juggle anything EXCEPT molecules.

Of course, I usually juggle lots of them at once.

Rah Rah (0)

Anonymous Coward | more than 9 years ago | (#12759846)

Is Slashdot nothing but a Rah Rah site for Linux then? They could have just as easily used QNX, Windows CE or even Embedded XP.

Yes, CE has very good real-time response.

Read, if you dare:
http://www.windowsfordevices.com/articles/AT676103 9286.html [windowsfordevices.com]

And QNX kicks RTLinux ass in almost every respect for this type of work. In short, the people that chose to use RTLinux were probbly just idiots that didn't know any better :(

Juggling molecules eh? (1)

mrjb (547783) | more than 9 years ago | (#12759949)

...and the article is written by Victor YODAiken. Coincidence? I think not...

Random Amiga sour-grapes (1)

Jhan (542783) | more than 9 years ago | (#12759983)

The Amiga had CPU clock-cycle-precise interrupts. IE, the very slowest 1985 Amigas (A1000) could throw interrupts every 1/7.16MHz seconds, or about 140 nanoseconds. 2005 Linux has an interrupt precision of 50 microseconds.

Way to go, RTLinux! You are now only 2800 times slower than a 20 year old box. Not that any other system is better...

Re:Random Amiga sour-grapes (1)

RWerp (798951) | more than 9 years ago | (#12760929)

The slowest (and the oldest) Amigas were A500, not A1000. How accurate was the CPU clock?

YOU ARE WRONG (0)

Anonymous Coward | more than 9 years ago | (#12761178)

The A1000 came before the A500. They both had the 7.something MHz clock.

Obligatory Doc. Evil ref (1)

hal200 (181875) | more than 9 years ago | (#12760100)

Bah! Come back to me when you can do it with sharks with frickin' lasers on their heads!

Tetris with micro beads. (2, Interesting)

ezzzD55J (697465) | more than 9 years ago | (#12760489)

A friend of mine implemented tetris using a laser to trap 1 mirometre glass beads. Short story + picture + video here [nat.vu.nl] . More explanation here [nat.vu.nl] .

Foreget Linux, Lets Hear it for Physics! (3, Interesting)

frenchs (42465) | more than 9 years ago | (#12761259)

How interesting. I just saw a lecture by one of the men that won a nobel prize [nobelprize.org] for this very thing, Steven Chu [stanford.edu] . What is being done here is essentially what is called Optical Tweezers [stanford.edu] .

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:
Almost Absolute Zero == Essentially No Movement == Essentially "Frozen" Object

-Steve

unigg4 (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#12761712)

New core is 6Oing you can. When the Java IRC client brilliant plan
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?