The existing bandwidth between Asia and North America is crowded. Following FCC approval of a U.S.-China link last month, Google and five other companies have announced a Japan-U.S. link to be completed in early 2010.
The $300 million fiber-optic cable will stretch approximately 10,000 km (6,214 miles) under the Pacific. "Google's partners in the consortium, dubbed Unity, comprises Bharti Airtel, Global Transit, KDDI, Pacnet, and Singapore Telecommunications," Yahoo News reported.
Internet users in East Asia are familiar with sometimes sluggish speeds on transpacific transmissions. In my experience, connections are for some reason faster in Beijing than in Shanghai, but everywhere I've gone in China there's been some lag. (Speeds in Tokyo were very fast when I was there in late 2004 and 2005.)
The previously announced cable, dubbed the Trans-Pacific Express, is scheduled to be partially operational before the Beijing Olympics begin on August 8. It will be the first direct connection between the United States and China.
[h/t: Kaiser]
As it stands, there's almost twice as much bandwidth across the Atlantic as there is across the Pacific. But with new U.S. FCC approval for the first ever China-U.S. fiber link, this is all about to change.
The score right now: 5,547 to 2,726. That's the current Atlantic vs. Pacific bandwidth score in gigabits per second, according to TeleGeography. The Trans-Pacific Express "will initially provide capacity of up to 1.28 terabits per second, and the system will have a design capacity of up to 5.12Tbps to support future Internet growth and advanced applications such as video and e-commerce," writes ChinaTechNews.
Construction has been under way since September, and should be complete before the Olympics. Internet speeds in Beijing are generally pretty good in my experience, but further south in Shanghai, much of the transpacific traffic is terribly sluggish on a variety of connections. Perhaps this is a matter of higher demand there, but with the FCC's approval for the cable to land in Oregon, things should get better soon.
Listpic, the visual searching and browsing tool for Craigslist has been blocked from the service as of yesterday. Craigslist creator Craig Newmark posted on the Craigslist user forums to alert the community to the shutdown last night, citing bandwidth drains and Listpic's attempts to "monetize" Craigslist by piggybacking off its services and using its own advertising. Newmark claimed that so much bandwidth was being used by the third-party service that it was "making it harder for the vast bulk of people who visit our site."
Listpic users could sort through Craigslist classifieds with photo thumbnails.
(Credit: CNET Networks)Listpic provided its users with a fairly simple way to sort and browse through listings on Craiglist by displaying items as picture thumbnails as opposed to Craigslist's pages full of plain text links. The site also featured its own ads, which went against Craigslist's terms of service.
One of the most interesting tidbits that's come out of this is a vague mention of Craigslist potentially building its own visualization tool in this follow-up post by Newmark. Some of the most useful applications of Craigslist have been the ones that take the data and present it in different ways. One of the clearest examples of this are the house and apartment hunting mash-ups like MapsKreig and HousingMaps.com. Both let you browse for places to live by exploring a Google Map.
The saga continues to unfold over on this Craigslist forums thread.
[via DownloadSquad]
At last week's Interop shindig, Cisco Systems CEO John Chambers' annual walk-about keynote presentation focused on "Web 2.0 creep" and its impact on the network. According to Chambers, enterprises will adopt Web 2.0 tools like blogs, wikis and Web video and bring today's networks to their knees in the process.
While I believe that the enterprise Web 2.0 trend is in its early genesis phase, I tend to agree with Mr. Chambers' hypothesis.
John Chambers
Enterprise networks have grown organically over the past 15 years--a switch here, more port capacity over there, add a wireless access point, etc. The design criteria were simple: extend the network and move packets as quickly as possible. Any problem along the way was easily solved by adding more bandwidth.
This formula was effective in the old client/server days, but it doesn't cut it anymore. Why? Applications are designed across multiple loosely coupled tiers and delivered over IP-based protocols to users anywhere in the world. We've already seen the performance problems that poorly written applications can cause across WAN links. Large IT organizations now have "application delivery" departments, while A10 Networks, Citrix, F5 and Packeteer are making tons of money in the fast-growing WAN optimization market. Multiply today's problems with a whole bunch of rich content and everything could come to a grinding halt.
In effect, Chambers is saying that today's network architecture problems are just the tip of the iceberg and although Cisco stands to benefit greatly, his message isn't hype. Now that "the network is the computer," enterprises need to think long and hard about how those networks will accommodate a whole bunch of burgeoning services and applications.
More bandwidth is always beneficial, but it is no longer a networking panacea. If we want to add complex network-based applications, we better be ready with an appropriate network architecture.
- prev
- 1
- next
