Slashdot Mirror
Fiber On Your Motherboard...Soon!
km790816 writes: "In this post I joked about wanting an optical bus on my PC. In the last week I've seen two articles from The Register and EETimes discussing the real possibility. Both mention high bandwidth and lower heat and power usage. Sounds good to me."
how long this would take. Its getting cheaper to use fiber. The boards are getting tighter packed etc. I wonder if they will design a board that you don't have to swap the motherboard every time a new cpu/bus archetechure comes out.
Backplane anyone? the S100 had it - It was a good idea at the time.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
I love hearing that people are finally starting to publish intentions. I have been hearing rumors about this for a year or so now, since an EVP where I worked started talking about plugging a Fibre into the side of the microprocessor (and he wanted to own that connection)
As is normal, he missed completely thinking it would be a 10GbE fiber for networking, rather than a 40+GB connection to main memory...
The comments on working on the I/O side of the processor were right on (I read the EETimes article, rather than the Register article to get "real" facts ). For years Sun was known for having the slowest RISC processor in the business, however they had the fastest boxes. No one seemed to understand this, until they realized that they were running multiple 128 bit memory buses at rather good clock rates. That was better than 10 years ago, and just now we are starting to see memory busses approaching this level in their competitors hardware.
Right now the bus is one of the largest bottlenecks in the system.
problems for home use:
Video card
Buisness:
Networking
multiple controllers.
It's not that hard to saturate a bus and unfortunatly it happens a lot. There are several hackish ways companies are trying to fix that (multiple PCI busses AGP etc) but none really fix the underlying problem.
While most folks are correct in that the biggest latency source is the drives right now, there is a fair bottleneck on the RAM to CPU bus. I think it's up around a 8:1 ratio right now (4:1 if you have a 266 MHz FSB), which means that your CPU can spend a large portion of its time waiting for data from memory.
:)
True, that's what the L1 and L2 cache are supposed to prevent, but some apps (games, mostly) blow through that cache without even thinking about it. WWIIOnline, for instance, gets bitchy with only 256MB. It's only happy once you have 512MB. How long will even a 4 MB on-die cache last?
If we can increase the speed that we can toss bits between the CPU and RAM, we'll reduce one more sticking point (and RDRAM, expensive as it is, was meant to do that), and higher framerates for all!
The newer plastic ones don't shatter quite like that- they even bend almost like coax. You can't kink it, but you can bend it pretty sharply. The dust buildup is an issue, but is not that serious. For a consumer device we would probably see some sort of automatic cover (Picture a twist on bnc style cable that irises open a cover upon connection), which would reduce/eliminate dust problems.
Firstly, the length of the bus on a motherboard is so short that there are few real gains over a copper/gold track, and those gains that are made are outweighed by the encoders/decoders that do the photonelectron conversions.
Close, but not quite. What you're alluding to here is that the latency gains are negligable, or even negative. But there's another factor, which you mention later... bandwidth. A nice fiber optic wire has a lot more bandwidth than some gold or copper. And this really does eliminate "all these problems" (except latency).
Another poster mentioned Serial ATA. How is it possible, on first glance, that a serial protocol, sending a single bit at a time, is faster than a parallel one, sending bytes at a time? Simple! It sends a bit much more often. And you could do the same thing with fiberoptics. If a fiber gives you 10Gb/s bandwidth, then connecting your memory takes exactly ONE 'pin' if you want a 10Gb/s memory bus.
A wider bus gives more bandwidth, yes, and means more pins on the chip, but a much faster medium can, and in the case of fiber optics, does outweigh this effect.
I've had this sig for three days.
The reason that buses that uses photons as the data carriers are coming up is quite interesting. The good thing with light (photons) are that photons are 'bosons', which amongst other things means that they do not interact with other photons. Good for transporting data, since noise is not a problem.
Electrons, on the other hand are 'fermions', which means that they interact strongly with other electrons. That is good for logic (since the whole point is to interact..), but is a problem for transports. (Cross talk etc)
From a power consumption point of view, using currents/voltage in a wire to send a logic one ore zero has some really severe problems. The wire itself introduces a resistance, capacitance and inductance which are non neglectible, at least not for long wires (buses) or high frequencies. IIRC, R ~ sqrt(f) for high frequencies, which leads to signal distortion, power loss, and ultimately an upper limit to the data rate. This is probably one of the reasons that research and development is going on in this area.
The plus would be that you'd not need point-to-point optical cables or some sort of optical router. Put a device in the case, give it electricity and it could "see", directly or indirectly all of the other components.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
quote: "For years Sun was known for having the slowest RISC processor in the business, however they had the fastest boxes. No one seemed to understand this, until they realized that they were running multiple 128 bit memory buses at rather good clock rates."
w id th.html
Ummm, go take a look at STREAMs and tell me that Sun boxen have good CPU-to-Memory throughput:
http://www.cs.virginia.edu/stream/standard/Band
Gosh that Ultra-60 is almost half as fast as an Alpah or an Athlon. And just to rub a liberal dose of NaCl in that gaping wound; it's about 1/4 the speed of a *couch*P4*couch*.
The Blade-1000 (with its UltraIII CPU) is the first UltraSCHMUCK based system to anything like resonable bandwidth.
Maybe this has something to do with why Sun gets pounded in every single benchmark that stresses bandwidth... Like SAP, Oracle, and TPC. Hell they even get pounded in SPEC.
And what's this nonsense about running the buss "at rather good clock rates"?
Only in the land of the setting SUN could a 50, or 100, or 133 MHz bus be considered "rather good".
The use of fiber on motherboards and similar devices has some huge advantages. First board density would quadruple. With DWDM whole busses from chip to chip would be replaced with single fiber lines. This would increase the number of components drasticly and also reduce electrical feedback from bus crossovers. Imagine building boards where the only consideration is where to place things asthetically?
The downsides are of course that every chip will have to have fiber PHY built in? or at least have on for every chip. This could be an even worse problem in the long run.
Teamwork is a bunch of people doing what I tell them.
-- ;-)
Kuro5hin.org: where the good times never end.
how much of a bottleneck is the bus right now?
This info is a little out of date-- it comes from Practical Unix Programming by Robbins and Robbins, published in '96.
It's a table of access times, scaled so 10 ns is equal to 1 second.
Processor cycle: 1 second
Cache access: 3 seconds
Memory access: 20 seconds
Context switch: 166 minutes
Disk access: 11 days
Notice that this table doesn't discuss bus bandwidths. The reason is simple: latency is more important than bus bandwidth for these kinds of comparisons. It doesn't matter if you can suck in 800 MB per second from RAM to CPU if getting that first byte still takes many nanoseconds.
In short, for normal server or desktop tasks, bus bandwidth isn't a serious bottleneck at all. But for traditional HPC applications, where a processor takes a huge chunk of data (measured at least in 10s of megabytes) and operates on it serially, from front to back, your bus and memory bottlenecks start to show through.
It's kind of analogous to having a car with a top speed of 250 MPH and a 0-60 time of four minutes. On the highway, once you get up to speed, you'll cruise along nicely. (Think of that as big serial computations.) But in stop-and-go traffic in the city, you're sucking. (Typical branching programs that depend on user input.)
Machine ID ncpus COPY SCALE ADD TRIAD
Compaq_AlphaServer_GS320-1001 32 21176.5 21176.5 22657.4 23309.4
Sun_UE_10000_400 32 6933.0 3556.6 4312.8 4032.0
Ave for Alpha == 22,000
Ave for SUN == 4,700
22,000/4,700 == 4.7
Cool dude, the SUN's delivering five times lower bandwidth on a per-CPU basis.
And what makes you think that the UE1000-400 was built in 1990?
LOL, that was their top-of-the-line machine before last month.