s vermill wrote: > > John Neiberger wrote: What you're missing is the cluelessness of news reporters and the public maybe...
> > > > Here's a quote from something I just saw in the news: > > > > "Scientists at the Stanford Linear Accelerator Center used > > fiber-optic > > cables to transfer 6.7 gigabytes of data -- the equivalent of > > two DVD > > movies -- across 6,800 miles in less than a minute. Well, nobody actually watched the movies! Now a real feat would be to send it over in that time and have someone watching it. > > > > Pushing the tech envelope > > The team was able to transfer uncompressed data at 923 > megabits > > per > > second for 58 seconds from Sunnyvale, California, to > Amsterdam, > > Netherlands. That's about 3,500 times faster than a typical > > Internet > > broadband connection. " Whoopee! > > > > Okay, 923 Mbps is a speed record? An OC-48 is roughly 2.6 > > times faster > > and they're fairly common. What's the big deal about 923 > > Mbps? I > > realize that I must be missing something very obvious here but > > I don't > > understand the milestone they're claiming to have passed. > > > > Admittedly, I'm about to fall asleep in my chair but that's > par > > for the > > course with me. :-) > > > > So, what's the big deal? In a world of OC-192 and up, why is > > > earth shattering? > > > > John > > > > John, > > It clearly isn't a bandwidth record in terms of bps. I'm aware > of as many as a few hundred OC-192s being "DWDMed" onto a > single fiber. I suspect this has to do with the > control/reliability mechanisms associated with the file > transfer. I suspect that they ignored the control issues. :-) If they used FTP/TCP/IP, they probably started measuring after the control and data 3-way handshakes and set the TCP window as huge as possible?? They probably rolled their own transfer mechanism, I would guess, but maybe not. TCP could be pretty good for this.... Priscilla > I read the same article. Nothing was said about the > protocols involved (it was packaged for mass consuption > evidentally). It was likely FTP/TCP/IP or something along > those lines (although a negative ack approach would likely be > the most effective). I noticed that there were several > intermediate hops. Don't know if that was a ploy to reduce the > delay portion of the bandwidth*delay product between any two > points or if there were other reasons. > > Scott > > > > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=64792&t=64767 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
