Slashdot Mirror
Optical Fiber Storage
TypeCast writes "When you've got Canada's elbow room, perhaps you can squeeze in a 'disk drive' 5,000 miles in diameter. But the plan by Canada's CANARIE researchers for a Wavelength Disk Drive (WDD) within optical networks suggests all of Universal Music's library would still make for a tight squeeze as light-speed storage. Here's a white paper on the WDD for those who aren't afraid of MS Word documents."
Our friendly geek is once again in a state court...
[judge] So does your controversial web page reside in California?
[geek] It resides in California 15 milliseconds every 350 milliseconds, your honor.
[judge] Pardon me?
[geek] My web page is served on optical fiber storage. It goes around the country in a big circle.
[judge] B-but it's stored somewhere in California, r-right?
[geek] No sir, it's encoded in photons travelling at the speed of light, you honor.
[judge] [thinking for a few seconds] Goodness, I'd rather be put on a simple divorce case.
This has been done before, but not with light. With sound! That's right, back in the 1950's they actually made memories from long mercury-filled tubes conducting sound impulses. The impulses would be amplified and "squared-up" each time around. They could only store a few thousand bits that way, but you could always have several of them running in parallel.
The concept is absolutely not new. Every FDDI ring topology could be used for/with this. Whereas Token ring only allows one single packet to circulate within the ring, this "new" concept allows, no, requires the ring to be filled up.
The "new" idea was not the ring as network topology nor the storage itself (has been done acoustically as stated above), but to coordinate client-server clusters with this. But clusters organized in ring-topology are not new either.
In the proposed topology the master server just injects "to-be-done" packets into the ring. The clients pick up (and remove) one packet from the ring each time they want to start crunching the next work packet. The other packets will be circulating the ring until solved.
Main problem is that one will be either wasting a lot of transmission capacity for idle data circulation - or be running into capacity problems. There is a reason why most detail work when designing clusters goes into designing the optimum network architecture for the specific problem...
Get the document in html.
I remember seeing an article about nano-motors that used vaporised water to move a piston that made a shaft rotate. A friend pointed out it was a steam engine. Just very small.
Now people are talking about fibre optic delay lines as storage devices. Some of the earliest computers stored data as sound waves in mercury and
nickel wires. A speaker injected sound in one end, it was picked up my a microphone at the other, re-shaped and squirted back in.
Same idea, different medium.
Oh, you're worried about a hundred years from now? Become a teacher. More education reduces population growth rates.
You multiplied the number of square miles times 5,280, the number of feet in a mile. But that's only the number of square feet along a one-foot-wide strip of a square mile.
266,807 square miles times 5,280 feet (one side of a square mile) times 5,280 feet (the number of one-foot strips in a square mile) is 7,438,152,268,800 square feet. Now do the division by the number of people. 1,213 square feet per person.
And here is the HTML version kindly genereated by freviewer.
Be careful. People in masks cannot be trusted.
That's the speed of light in vacuum. In solid materials, it travels quite a bit slower.
- 1) if the next in sequence packet is in the cache put it into the stream next. (move to next packet)
- 2) if the next in sequence packet is in the stream repeat it in its place in the stream. (next)
- 3) if the cache is full (this packet is out of sequence) repeat this packet in its place (next)
- 4) if there's space for this packet (out of seq) in the cache, chache it for being put in sequence.
after a few loops, everything will be in sequence. Of course with access of the whole loop taking only 100ms it might be okay to just cache the sequence you're looking for and you'll have a worst case of 100ms access. This approach would be bad though for application accross the whole network.-Daniel
But they aren't planning to store anything long-term on it! It's only intended for very short-term data, such as which computer is working on what part of a large job, or the results of one piece of the job that finished running.
They only will have 10GB for the whole ring; that wouldn't be much for all of Canada if people try to store MP3 files on it!
And anyway, if you are going to make a peer-to-peer, massively parallel computer, you need to make the system robust. Forget the backhoe; suppose a power failure takes out an entire town's worth of computers all at once?
P.S. It would be serious overkill, but I keep picturing this being used to release Linux kernel 2.6! 10:00, it ships; 10:01, every computer in Canada has a copy...
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
SETI@home works in client-server fashion: your desktop computer asks the main server for a chunk of data, then chews on the data and talks to the server again. This is massively parallel computation, but it isn't peer-to-peer, it's client/server.
When you put data on this fiber ring, within a very short time all the computers on the ring have seen the data. So if you want a bunch of computers to cooperate on a job, this would be a great way for them to update each other on what they are doing. If you did it right, you would have massively parallel distributed processing: all the computers in Canada tied into a single InterComputer. And just as Napster can spread popular songs around where a single FTP server would be hammered, an InterComputer potentially could handle truly large computations that any single computer (or even Beowulf cluster) couldn't.
Multicast data packets aren't new; that's why they said it takes only a few changes to try out their ideas. Multicast packets are currently designed to die fairly quickly so they can't clog a network up too much; these guys want the packets to go all the way around the ring.
P.S. That joke about the backhoe chopping the fiber was only a little bit funny, and then only the first time. When a backhoe hits a cable today, half of Canada does not lose Internet service! It isn't a trivial ring; it has some redundancy redundancy.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
You can download it here:
Cheers,Wavedisk White Paper (PDF)
Chase
[ a directive occured while processing this error ]
I guess that's one way to use up all of that empty space Canada's got lying around...
Help save the critically endangered Blue Iguana
that the data access time is comparable to RAM.
So shared data between processes executing in multiple computers from vancouver to halifax can be quickly accessed and updated.
The speed increase over requesting the data from ether over it being in some computer's cache depends on how fast that computer's connection is to a backbone's router.
Although now that I do some quick calcs, the max latency turns out to be, 180000(k/s)/8000(km) = 1/23rd of a second = 45ms, and avg latency 22ms, which is slower than HD.
You'd be saving 5ms to 10ms maybe over getting the data from a cpu behind a router, so the applications are indeed pretty narrow, but not non-existant.
But the point is that the memory already exists, and (I believe) the buffers are often separate from the routing tables. In one buffer, out another. As long as the router can route at full wire speed, there is no problem. You're just using memory that wasn't fully used before.
I wonder what kind of redundency is built into the system? It would not be very neat to have your data flying across the fiber and run smack into a severed line cut by some poor guy's backhoe. If not redundency, will they be backing this stuff up somewhere?
The glass just seems a little fragile...
Just scanned their whitepaper (thx for the PDF version). They quickly mention router memory is not used. But then they go on without explaining what does store the data. It has to be stored somewhere. It can not be in the light signal.
.027 secs. To put 10GB of data in that ring, you got .027 sec. You would need a speed of 375 GBytes / sec, divided over 8 wavelengths this would be 375 Gbits/sec per wavelength. Good luck! So the light signal alone simply can not store 10 GB.
.1 sec instead of .027. This latency is introduced because of routers. Since the ring itself can only store .027 secs worth of data, the other .1 - .027 = .073 secs have to be stored somewhere else. And that can be in no other place than in the routers memory.
Look at it this way. If there were no delays in the network, only optical repeaters, no routers, the signal would travel at the speed of light, and travel the 8000 km. in
Now, this ring has a latency of
(Or have they invented optical repeaters that delay the speed of light and have a memory of their own?)
You could also buy 20 routers, hook them up with ethernet in a circle, pump around data through it as fast as you can, and enjoy an 'ethernet' drive at home. Be sure to buy routers with large buffers for increased storage!
My karma ran over your dogma