Nortel gets 6.4 Terabits on a Single Fibre
GFD writes " Nortel claims to be able to do 80 gbits/sec in a single wavelength. Using their current top of the line DWDM equipment which handles 80 wavelengths on a single fibre they get 6.4 terabits per second.
What's scary about this is that future DWDM products are claimed to aim for 400 wavelengths per fibre. That fibre would be able to carry over 21 million T1 channels! "
SCSI and parallel ports aren't, but USB is, I think FireWire is, modems are, etc. Since comm is bit at a time, bit speeds make sense.
Storage is almost byte oriented. Actually, disk drives are sector / block oriented, but that differs from drive to drive, making byte the common denominator.
--
Infuriate left and right
Actually, if you talk to a memory designer, they will talk about bits, not bytes. The sizes of RAM parts are all in bits; same when packaged onto a DIMM (which may be 8Mx64 for a 64 megabyte DIMM). However, the computer it is put into will be sold as having 64 megabyte of RAM.
It is really only computer (as opposed to electronics/optonics) people who uses bytes. At the hardware level, after all, everything is bits, after all.
On transmission systems it is even more confusing, since low-level framing protocols (below the software-visible level) are often bit- rather than byte-oriented; on RS-232, for example, it typically takes 10 bit intervals to transmit an 8-bit byte. Therefore, an RS232 serial port talking at 57600 bps can transmit 5760 bytes per second, not 7200 as you might think.
It gets worse. Certain modulation schemes transmit multiple bits per state transition. If you have a 32-point QAM constellation, for example, you will transmit 5 bits per state transition (5 bps per baud.) This gets awkward really quickly if you in addition have to worry about 8 bits per byte!
ph43drus drooled:
>Think of all the PORN you could download!
The bandwithrequirements of one person surfing for porn is not a problem even with current technology.
The truly mindblowing possibility is HOSTING a pornsite. You could have every man, woman, child and dog in the world wanking off to pictures from YOUR site, and still have bandwidth to spare.
So 15 fibers would be enough to carry one T1 channel per person in the USA. Distribution is left as an exercise for the reader.
In other words, they do transmit 80*80gbits/sec of data, but the actual information they transmit is (merely?) 80gbits/sec. So, unfortunately these setups are far from the real thing, but maybe someday...
Oh, and the high-bandwidth transmitters and receivers do work better in stable conditions such as a research laboratory. Try that in an actual environment and be surprised. Lasers and PIN-diodes are temperature-dependent and chirp becomes a problem in high-bandwith lasing. (Chirp = a change in laser wavelength when laser diode's current changes.) The bright side is, that at least these things are under intense research.
No apologies for any misspellings, this ain't my best language. :)
At this years Hannover show, I saw Fujitsu's latest speed demon, the 320Gig. WFDM, I remember being very impressed. being a Telco Engineer. However as I was looking (drooling) over this new sparkling toy the following occured to me.
a) These things do get faster every year or so. No biggy there. So what. CPU's speed up Harddrives get bigger/faster cheaper. Is anyone really surprised by this ? The numbers ar big and very fast - but it *was* a lab.
b) These things are horrendously expensive to put into the ground. The only people that can actually afford to use them are Telco's (think Baby Bells AT&T and MCI Worldcom/Sprint )
So what does this gain us. Nothing. We won't see any increase in internet backbone because of this. The Telcos' have to much capital investiture to pull all those gloriously expensive CBR services out and replace them with something innovative like POS ( Packet over Sonet ) or ATM.
The ITU has only really ratified OC-192 ( STM-64 ) 9953.28 Mbit/s ( 10Gig ) fairly recently. These new multipliers are not yet part of the standard. Traditionally we have seen steps of 4X over the last signal speed.
STM1 = 155 M
STM4 = 622 M
STM16 = 2488 M
STM64 = 9953 M
etc.
I'm not sure that these actually fit cleanly into the current SONET / SDH infrusture. Which is fine for point to point comunications, within the one company or Country. But it you needed to interconnect one of these to another vendor's bit of kit, unless they follow the same technology tree with FWDM 80 Gig Steps, it would mean that you would have to step this bad boy down to a level in the standards to actually get something out of it. That could mean a lot ( a real lot ) of 10 Gig boxes stepping down across lines of demarkation ( or POI's )
And just on the side. Nortel's track record of just keeping 1X ( Their name for an STM1 box) running is really not so good. How are they going to support 6 Tera if they *really* can't get the basics right ??
MRo
Would we have then reached the final/ultimate speed limit?
Before that happens, we need to concentrate on our algorythems and develop better compression. Sure people are getting rid of compression just cause there is mode bandwith.
You're doing the same thing that a lot of the general populace does, and getting latency mixed up with bandwidth.
Latency is how long it takes for an individual packet of data to get from one place to another.
Bandwidth is the total amount of data you can get from one place to another.
A little comparison: if you had a large plane that had a top flight speed of about 300 mph (mach 0.4) and could carry 1000 passengers and you also had a jet fighter that could travel at just over mach 4 (3000 mph) and transport a single passenger. Most people would agree that the jet fighter was "faster" in a very real sense than the large plane (by a factor of 10). However, with two cities 1000 miles apart, (ignoring time spent loading, unloading, refueling, etc.) the large plane could transport 2000 passengers in 10 hours (3.3 hours per one-way trip) while the jet fighter could transport 15 passengers. With vehicles, carrying capacity (bandwidth) and speed (low latency) don't get confused. Yet, somehow, when you replace planes with modems, the average consumer gets confused and thinks that speed means something completely different than it means in any other context. Speed is how long it takes to get from here to there (miles per hour, for instance).
Very luckily, however, for big expensive products that aren't aimed at the average consumer, latency is considered very important.
When you compress data that is being sent live, you actually have to slow things down in order to do it. (look above at explanation of what speed means, if you're unclear already) This is because you can't effectively compress a single bit or a single byte, so in order to compress you'd hold onto the data for a little bit before sending it off.
With your average consumer modem, compression slows things down by 15ms or however long it takes to receive a large enough block to send from the user (whichever happens first). With a normal home modem, though, you've already got something like 100ms that's wasted going across that link, so in most instances another 15ms isn't much, and is a good tradeoff for the slight boost in bandwidth.
When you've got a DSL line, however, you've got much lower latency than a normal modem would get, so something like 15ms tacked onto it would be doubling your latency. Double (or worse) latency in exchange for a small increase in bandwidth simply isn't worth it. It would just slow down your overall experience. (The only thing where you might want high bandwidth more than low latency is, basically, if you're downloading a lot of large files (like porn or software), and those are usually already compressed (JPEG, GNU zip, ZIP, etc.))
Improving switching and routing speed is much more important and useful. Adding compression to high-speed lines is a bad idea.
Also, electrical impulses already travel at about 2/3rds the speed of light -- outside of your CPU the speed of light over the speed of electric impulses isn't too much of an issue...
The scary thing is that the thing you typed is exactly what I saw... I've become all Matrix-like in my viewing of control characters. Ugh. Time to step away from the computer and get some sleep.
-Chris
People are flexing their technical knowledge at you and not answering your question. Data carriers always talk about bits because bits are the most fundmental unit of information. No matter how that information is grouped into larger structures, you can always reduce it to bits, the lowest unit of information.
Sometimes a stream of data is NOT bytes. Consider sending a series of octal digits. Each octal digit is three bits. If you send that data out in a stream of 6 octal digits, you have 18 bits of data. Now, if, at the other end, you happen to be reading in bytes, you get two bytes and two bits left over. The transport medium still carried 18-bits.
Modern computers defintely have a bias towards 8-bit bytes. That's because Latin alphabets and symbols can be well represented by 7 or 8 bits. Prior to the adoption of EBCDIC and ASCII coding, a five bit protocol was used for radio teletype equipment. They used an encoding scheme called Baudot. So, what are you sending? 3-bit octal numbers? 5-bit Baudot RTTY characters? 7-bit ASCII, or 8-bit extended ASCII?
Doesn't matter to the data carrier. It's all bits.
There's another source for the prejudice. There are two major styles of data interface. Serial and Parallel. In paralell, you have one data line per bit in the "word" (a word being the "chunk" size of the data -- again, typically 8-bits, either 7-bit ASCII with parity, or 8-bit extended ASCII) and then you have control lines (STROBE) that signal when a "word" is ready to read on the lines. Paralell interfaces tend to be local, because running many wires over long distances is obviously more difficult and expensive than running one (or a pair).
This leads to "serial" communications. Serial communications uses one wire to carry data, one bit at a time. The first such protocols were the radio teletypes I mentioned earlier (RTTY).
An antenna sticking in the air carries one signal, and that signal has three states. One state is idle, not doing anything. The others are called MARK and SPACE, or 0 and 1.
The teletypes had a rotating cam that would move past five levers. A lever could be set (pressed) or clear (not pressed). The seetings of the lever would determine which hammer would be pressed forward when the carriage would move at the end of the cam's rotation, thus determining which letter (or symbol) would be printed on the paper.
So, a sending teletype operator would press a local key, this would set the levers and make the matching hammer hit the local paper. The local cam would rotate, reading the lever settings, and would send a MARK (for a set lever) or a SPACE (for a cleared lever). The receiving teletype's cam would be likewise rotating, and it would set and clear levers as the MARKs and SPACEs were received.
You should be seeing an obvious problem here. What if the cams were not in the same position? The wrong levers would be set and the wrong characters would be printed. They first tried to solve this problem with "synchronous" protocols. A sender would send a specific pattern of marks and spaces as fast as it could. The other end would speed up or slow down it's cam until it came to "top" at the beginning of the synch pattern. Then they would start with the data. Trouble is, this system tended to drift, and the text would become gibberish requiring a re-synch.
The next invention helped solve that. Called "asynchronous" serial communication, it added the concept of a "start bit" and a stop bit. The idea was that each character would begin with a start bit (a MARK) and end with one or more stop bits (SPACEs). The receivers cam would be locked at the top and when a start bit was received, it would release, go around once, and lock until it saw the next start bit. This isn't really "asynchronous," in fact it is re-synching on every letter!
This basic protocol is still in use today right in your serial port and modem. You send one start bit, an 8-bit character, and a stop bit. That's why a 2400 baud modem can send 240 cps instead of the 300 cps it ought to be able to send if it were 8 bits per character.
I chose 2400 baud, because as other posts point out, protocols get a great deal more complicated at higher speeds.
Still, the RTTY and the rotating cam idea are the reason serial communications exist, and they are the basic origins for their mechanics.
The high speed technologies discussed here are not simple serial asynchronous systems, but complex frame-based systems. Nonetheless, those frame elements are there to do the same sort of jobs that start-bits and stop-bits were meant to do: Allow a bunch of hardware to watch a "wiggling" electrical signal and figure out how to draw the intended information from it.
All of this adds up to why they talk about bits per second. The data carrier does not care how the bits are oragnized into units of meaning. No matter how they are grouped, they are just streams of bits.
Phew! Sorry for such a long post...
I just want to be sure I understand you. You see compression as useful any time you have multiple threads of data that must be passed through a single interface? In other words, where even if everything is operating at nearly maximum signaling rate, we still have more bandwidth in the "processor box" than we have in the data communications interface because there is more than one processor moving data at the maximum signaling rate?
;-)
I guess I'd have to admit that does offer an exception to my purely theortical objection. Holy dog chow, though! I hope never to see world where we all need that kind of bandwidth.
I can imagine myself needing several Gigs, but I can't imagine personally needing that kind of bandwidth (although, obviously when we have Gigs in our homes, someone is going to need Terabits). While I'm conceeding points, I also remember my first 10M hard drive (in my CP/M 1.4 days) and thinking "I'll never fill this thing!"
How much bandiwdth would a transporter use, anyways?