Libelula rocket-powered helicopter backpack redefines danger

Sure, you can get yourself a personal helicopter or, if you're particularly daring, a jet pack, but what about those that crave yet more danger in short 30-second bursts? As in, rocket-propelled helicopter blades a few inches from your head-type danger. Thankfully, the folks at Tecnologia Aeroespacial Mexicana (makes of some of the aforementioned jet packs) have come to the rescue (so to speak), with their latest high-flying concept, the Libelula rocket-powered helicopter backpack. Apparently, the rockets on the tips of the blades are necessary to keep the whole rig counter-balanced, a job that would normally be done with a tail rotor on an ordinary helicopter. Of course, as you can no doubt surmise by the detailed illustration above, this one's still a ways away from getting its first test flight, but the folks at TAM do have a proven track record, so we wouldn't put it completely past 'em to get it off the drawing board sooner or later. [Via Tech Digest]

Conceptual artificial plant enables you to practice before slaying flora

C'mon, we know there are a few of you out there who couldn't keep a potted plant alive if a botanist was holding your hand, but there's hope for you all yet. At least, there is if QianJun Gao's masterpiece ever makes it past the drawing board. This eloquently dubbed Practice Plant features a trio of "flowers" that display barometric readings and turn colors depending on status, and the surrounding leaves will droop to signify their need for attention. Thankfully, even the brownest of thumbs could always restart this puppy and try again, and with enough trial runs, maybe one day those hanging baskets wouldn't sway out of your way as you waltz by.

[Via YankoDesign]

BAE Systems working on spider-bots, other ways to scare you to death

Do you enjoy gangs of tiny, spider-like robot insectoids swarming all over your house, car, or personage? If you answered "yes," you're going to love what BAE Systems is cooking up. The company recently received an infusion of $38 million from the US Army Research Lab to fund the Micro Autonomous Systems and Technology (MAST) consortium; a team of scientists and researchers hell-bent on developing an "autonomous, multifunctional collection of miniature intelligence-gathering robots that can operate in places too inaccessible or dangerous for humans." Sure, that description (and accompanying photos, straight from BAE) does give you the impression that whoever came up with this really liked Minority Report, but won't it make you feel safer at night knowing a swarm of metallic spiders are looking out for you? No? Huh, weird.

[Via The Register]

Everex Cloudbook MAX with WiMAX network

Debuting today at CTIA 2008, the Cloudbook MAX not only boasts an 8.9-inch WVGA (1,024 x 600) display, Windows Vista, 802.11b/g WiFi, Bluetooth, integrated GPS receiver, 2-megapixel webcam and a battery good for four hours, but it also features an 80GB HDD, 2GB of DDR2 RAM, audio in / out and an S-Video output. Beyond all that, this thing gets energized by a 1.6GHz VIA C7-M ULV processor coupled with the VX800 digital media IGP chipset, which touts full DirectX 9 support and video acceleration for MPEG-2, MPEG-4, WMV9, VC1 and DivX video formats (plus a VMR-capable HD video processor, among other things).

Lastly, the unit includes built-in support for Sprint's XOHM WiMAX network. Brimming with excitement yet? Start stocking that piggy bank -- this currently unpriced rig will be available in the latter half of this year across North America.

Snake-like robots

We'll be honest -- we've seen more snake-like robots than we care to count, but a new creature slithering out of the Norwegian University of Science and Technology is noticeably different than most. As you can see above, there's a distinct lack of treads, tracks or wheels on Aiko, as it actually pushes off foreign objects it encounters in order to creep forward. Additionally, researchers have created a "virtual double" of the critter in order to help guide the development of the actual robot, though we've yet to hear if it plans on joining Anna Konda in war on fire.

Robotic lawn mowers

Robotic lawn mowers have been keeping yards tidy for their masters for a good while now, but Husqvarna is looking to teach an old robot new tricks with its Automower. As expected, the grass muncher is ultra-quiet and outputs zero emissions, and you can even program it to take off and get to work whenever you please.

Reportedly, a fully charged battery can get about 40 minutes of cutting done, and best of all, the unit will automatically return to its charging base to juice back up if the sun isn't out. Still, with a price tag of around £2,000 ($3,971), you may just be better off paying that punk kid down the street to handle your mowing needs.

The growth of the Internet

Every conduit can take a 144-fiber cable

Thanks to the virtually infinite bandwidth of fiber—or rather, the empty tubes that can hold multi-fiber cables—the Internet has continued to get faster for almost four decades, with congestion only proving a temporary condition. But now, it's again uncertain if the routers that sit at the ends of these fibers will be able to keep up with the growth of the Internet.

Most of us take it on faith that if a computer creates an IP packet and sends it out with the right IP address in the "destination" field, the packet will get delivered to the computer holding that address. Anyone who's ever used the traceroute program ("tracert" on Windows) can attest to the fact that there are usually a good number of routers between any source and destination connected by the Internet.

So how do these routers know which path any given packet should take? Unsurprisingly, routers keep a list of which address block needs to be sent where; it's called the routing table. As with all things Internet-related, these routing tables have been growing steadily, and even multiply in accordance with Moore's Law in the coming years. Unfortunately, in engineering, it's often the case that something that works well on a small scale doesn't work on a (much) larger scale. So "scalability" is always a concern—doubly so for anything related to the Internet with its unprecedented growth rates.

Building routing tables with BGP

Conduits waiting to be put in the ground

First, a little background. When a router starts up at first, it only has local destinations in its routing table. With the help of routing protocols, though, routers are able to build a complete table so that they know where to send packets to all possible destinations.

There are several routing protocols that organizations can use locally in their own networks, but only one that spans networks that belong to different organizations. This is BGP, the Border Gateway Protocol. Back in the day, "gateway" was a term used for what we now call a router, which makes BGP "the protocol that runs between routers on both sides of the border between neighboring networks."

Currently, nearly a quarter million address blocks are injected into BGP. This means that the large routers at the core of the Internet must search through at least a quarter million address blocks for every single packet that they forward. This can easily reach one or two million packets per second for each 10 Gigabit Ethernet interface in such a router, given the Internet's average packet size of around 500 bytes.

Overcoming DRAM slowness

Internet routers maintain two (sometimes more) distinct tables: the RIB and the FIB. The Routing Information Base contains the information exchanged through BGP. In most cases, there are several ways to get to a certain destination, and the RIB tends to hold several of these pathways for each address block, along with the information that is necessary to suppress routing loops. This table is kept in DRAM and maintained by a regular CPU running software.

The Forwarding Information Base is a table that's highly optimized for looking up the next hop for a destination during the forwarding process. A routing table lookup needs at least a couple of memory cycles, which are highly unpredictable from one packet to the next—bad for caching—so in order to work at 10Gbps speeds, the FIB needs to be held in faster and more expensive SRAM. Alternatively, routers may use Content Addressable Memory (CAM) to quickly find information in the FIB. However, CAMs, traditionally used in Ethernet switches, are notoriously power-hungry at high speeds.

Scaling to larger and larger routing tables

For some time now, the community of "inter-domain routing" operators has been concerned about the growth in both the size of the global routing table and the growth in the number of routing updates that routers must process.

This has happened before: in the early 1990s, the number of class B address blocks (with 65,536 addresses each) started running out, so organizations started using a number of class C blocks (256 addresses each). However, this meant that every new organization that connected to the Internet needed four to sixteen routing table slots—one for each class C block—rather than a single one for a class B block.

The routers of the time could only handle a few thousand routes, which quickly became a problem. In 1993, the main router vendors were just implementing a new version of BGP, which doesn't look at the traditional class A/B/C addressing model but can carry address blocks that are any even power of two in size.

Around 1997, there were again problems as buggy BGP implementations caused "flapping" where BGP sessions kept going down and coming back up, using up CPU time in routers around the world. Back then, "flap damping" saved the day.

Today's and tomorrow's problems

A little over a year ago, the Internet Architecture Board (IAB), which guards the architectural underpinnings of the IETF's work, organized a workshop about this topic: the routing and addressing workshop (RAWS). Earlier this year, the report from the workshop was published as RFC 4984. Let me quote a bit:

One surprising outcome of the workshop was the observation made by Tony Li about the relationship between "Moore's Law" [ML] and our ability to build cost-effective, high-performance routers. "Moore's Law" is the empirical observation that the transistor density of integrated circuits, with respect to minimum component cost, doubles roughly every 24 months. A commonly held wisdom is that Moore's law would save the day by ensuring that technology will continue to scale at historical rates that surpass the growth rate of routing information handled by core router hardware. However, Li pointed out that Moore's Law does not apply to building high-end routers as far as the cost is concerned.

However, Moore's law has increased the amount of transistors companies like AMD and Intel can put on a CPU die so much that it's now more efficient to put the cache there as well, so fast SRAMs are no longer a commodity that goes into every PC. Those SRAMs are now a specialty product that isn't particularly cheap or developed particularly fast. So rather than buy commodity chips on the open market, router vendors are now forced to bankroll the development of hardware that supports faster FIB lookups. With the jump to 40Gbps and 100Gbps coming in the next years, this will be a challenge—a challenge that the biggest router vendors can probably meet, though the resulting products won't be cheap.

In the meantime, the RIB is having some trouble of its own. Not only are there many network operators that inject more prefixes (BGP lingo for address blocks) into the global routing system than are strictly necessary, but there are also a few that insist on sending huge numbers of updates every day. Apparently, their links keep going up and down and up again and down again all day.

The design of BGP is such that when this happens on one remote corner of the planet, every other BGP router in the world has to process these updates. Both the size of the table and the number of updates grow at healthy rates, while at the same time DRAM speeds only increase marginally every year. This means that at some point, the route processors can no longer get at the RIB fast enough to perform all the updates in real time.

But didn't we have flap damping for that? Yes and no. It turns out that flap damping can actually be harmful if it's deployed in an uncoordinated fashion. And if there's one thing that's hard to do, it's coordinating (herding cats, in IETF parlance) the network operations people that are in charge of global inter-domain routing.

The source of the problem

It's not entirely clear where the growth of the global routing table comes from. If you dust off your telnet client and connect to route-views.oregon-ix.net, you can log in to a publicly-available Cisco router that gets copies of the BGP data from a large number of ISPs, which you can inspect using the command "show ip bgp." (Also try "show ip bgp

".)

If you do that, you'll often see consecutive address blocks with identical properties, which could just as easily be expressed as a smaller number of larger blocks. So apparently, a large part of the size of the Internet's routing table is essentially pollution from people who can't be bothered to clean up after themselves. In other cases, the blocks ultimately lead to the same destination, but through different intermediate networks. In those cases, the destination in question is doing "traffic engineering," balancing the flow of traffic over the available links towards the Internet that are most favorable.

ISPs tend to inject a number of different blocks into the global routing system because, as they grow, they obtain new address space. However, the number of ISPs is stable or even declining.

There are also organizations that aren't ISPs who have their own presence in BGP. Normally, end-users ride along on the BGP advertisements from their ISPs, but "multihomers," organizations that connect to the 'Net through two or more ISPs, have to do this themselves.

Finally, some organizations are present in BGP just because they can. This way, they get to take their IP addresses with them when they switch ISPs, and avoid the hassles and costs involved with renumbering their network. Both traffic engineering and multihoming are often cited as primary reasons the global routing table keeps growing, but it's anybody's guess to what degree both of these will contribute to future growth.

Solving the problem

So what's an Internet engineer to do when her tables grow by 16 percent a year while RAM speed only grows by 10 percent annually? Two things, mostly: either complain that the previous generation of engineers didn't do a good job, or (if she's part of that generation herself) point out that she proposed the perfect solution a decade ago but nobody listened. That's probably a bit unfair, but it's not without a kernel of truth.

However, both the IETF and its research-focused sibling the Internet Research Task Force have studied the problem as a whole or certain aspects of it over the past decade. When IPv6 was developed, this was seen by many as an opportunity to fix the routing scalability problem as well. However, the argument that you can only make so many changes at once won out—along with the fact that back then there was no easy way to solve the routing issue, either. A few years later, Mike O'Dell wrote up the famous "8+8" or GSE proposal. The idea behind it is to allow routers to rewrite the upper 8 bytes of the 16-byte IPv6 address and hosts only look at the lower 8 bytes. This addresses multihoming, traffic engineering, and provider independent addressing. However, the proposal was never developed any further and suffers from a number of issues.

Early this century, the IETF started the "multi6" working group that was chartered to look at scalable multihoming for IPv6. The fear was that with the increased IPv6 address space, multihoming could become a big problem. The job of multi6 was to explore ways to do multihoming that don't tax the routing system. After many years and numerous proposals, this led to the shim6 working group, which is now about to publish specifications that allow a "shim" layer in the TCP/IP stack to dynamically move ongoing communication from one address to another. Under this plan, a computer might have an address from ISP A and an address from ISP B. When it's communicating over ISP A, but that ISP goes down, shim6 simply moves the communication session to the address from ISP B. Shim6 could be useful for home networks and small offices, but operators of larger networks don't see much to like in this approach.

Currently, the IRTF's Routing Research Group (RRG) is evaluating a number of proposals, with most of them falling under the "jack up" moniker. The jack up class of approaches basically takes all the addresses used by end-users and removes them from the current inter-domain routing system. These addresses are then tunneled through the core of the Internet; devices that sit close to the user/ISP boundary encapsulate packets to provider independent addresses into another IP packet. This IP packet is then sent to an equivalent device close to the user/ISP boundary at the destination's end, where the original packet is decapsulated and sent on to its intended destination.

By hiding the addresses that the users see from the big core routers in this way, it's possible to make those core routers faster and cheaper. However, it does mean it's necessary to deploy encapsulation/decapsulation devices at the edges of ISP networks (or even in end-user networks) everywhere. This would be the first big change in Internet routing in a decade and a half. But if it doesn't work, perhaps some more cat herding will do the trick.

Intel's x86 ISA grows down: today laptops, tomorrow the iPhone

In spite of its astounding commercial success, x86 is almost certainly the world's most-maligned instruction set architecture (ISA). Predicting the death of x86 used to be a favorite pastime of everyone from bearded mainframe geeks to Mac-using AOLpersons (especially the latter). But like various bad 80s fashions, x86 may be ugly, but it just keeps coming back.

These days, I don't field nearly the volume of "When do you think x86 will finally roll over and die?" questions that I used to. Indeed, it has been over nine months since I last faced this particular question, in a radio interview for a program called GeekSpeak—this has to be some kind of record for me. Perhaps the public is finally catching on to the fact that x86 isn't going anywhere. If so, then that's progress, but here's the next reality that x86's (technically justified) detractors will have to deal with: not only is x86 not going anywhere, but in 2008, it's going everywhere.

Mark my words: in 2008, you'll see x86 processors win the first few major battles in a multiyear war to displace the likes of ARM, PowerPC, and MIPS in the pockets, purses, and briefcases of everyone from corporate executives to mall-hopping Paris Hilton wannabes. 2008 will be the year of the must-have x86-based ultramobile PC (UMPC) and mobile Internet device (MID), and from there it's a straight march into a future iteration of the iPhone.

No, I'm not just mindlessly regurgitating Intel marketing materials; this prediction is a matter of physics and economics. The 45nm process node that Intel has brought online and will soon begin ramping up marks an important milestone in the evolution of the world's most commercially successful (and most perpetually "old and busted") instruction set architecture. This is the point at which the bulky and bloated x86 ISA elbows its way into the embedded space like a 250-pound man squeezing into coach class, carrying with it the billions of lines of legacy code that give it such powerful economic and technological inertia. With a 45nm x86 processor, you can boot decades' worth of Windows software without a recompile on a device that fits comfortably in the palm of your hand and boasts a four- to six-hour battery life. This makes 45nm the point at which things will get really, really interesting on the mobile front.

Of course, it has been possible for some time now to squeeze an x86-based PC into an ultramobile form factor, but it hasn't been cheap or attractive. Intel may yet find some success with its 90nm, Pentium M-derived "McCaslin" UMPC platform, which just recently launched, but the party won't really get started until McCaslin's 45nm successor, Menlow, arrives in 2008. Menlow and its successor, Moorestown, will fundamentally change the complex cost/power/thermals/compatibility equation that dictates what kind of hardware goes into a commercially viable pocket-sized widget.

Menlow: UMPC and MID

The first major step on the road to a truly portable x86-based device is the "Menlow" platform that Intel touted at the most recent IDF. Menlow, which pairs Intel's 45nm mobile "Silverthorne" CPU with a special ultramobile chipset called "Poulsbo," will feature support for 802.11n and WiMAX, so that the whole Menlow package can deliver a full wireless Internet experience by running standard (x86) Linux and Windows browsers.

Speaking of operating systems, Intel is pretty aggressively showcasing Linux as the OS of choice for the UMPC. Nonetheless, Microsoft is working on something for the devices, which will support Direct3D 9ex and WMV9. The iPhone has shown that interface is key—no one should ever have to manipulate a tiny scrollbar with a stylus—and the Linux software that Intel showed me on a Menlow demo unit back at Research@Intel Day looked remarkably iPhone-like. So we'll see what Redmond comes up with on that front.

The UI for the Mobile Linux Internet Project. Source: Moblin.org

The Menlow slides that Intel was showing at IDF are variations on a slide deck that has been around at least since May of this year and IDF Beijing. One of the slides compares the king of hearts to a similarly sized Menlow motherboard, to show that Intel can now fit an x86 PC in an area not much bigger than a playing card. One of the major factors behind this high level of integration is Silverthorne.

The Silverthorne CPU. Source: Intel

Menlow's Silverthorne CPU as miniscule as you might expect of a 45nm single-core design. The whole package for this CPU, which will also power some of Intel's notebook offerings, is smaller than a penny. In spite of its small size, however, the processor will pack more horsepower than a similarly-clocked Core Solo (that is, if it's a Penryn variant, and I believe it is), which is more than enough performance to give a full Web experience using the same binaries of Firefox, Internet Explorer (and Safari?) that run on x86 desktops.

Menlow

CPU	45nm Silverthorne
CPU features	1-2GHz, 64-bit, HyperThreading
Chipset	Poulsbo
GPU	Probably PowerVR sgx
3D support	D3D9ex, OLG 2.0
Memory	DDR2 400MHz/533MHz
Networking/IO	802.11n, WiMAX, GPS, BlueTooth
Form factor	UMPC and MIDs with 4"-6" screens
Storage	NAND flash
Battery life	6 hours of usage, 10 hours standby
Arrives	First half of 2008

Intel will follow Menlow in the second half of 2008 with a new mobile platform called "Moorestown." We don't know as much about Moorestown as we do about Menlow, but what we do know is pretty tantalizing.

A slide from Anand Chandrasekher's IDF keynote, slightly modified for clarity. Source: Intel

For starters, the heart of Moorestown is an as-yet unnamed system-on-a-chip (SoC) processor that includes one or two processor cores, a GPU, video encoding and decoding hardware, and a DDR3 memory controller. Note that this processor does not appear to share any DNA with Tolapai, the Pentium M-derived 65nm SoC that Intel will aim at the embedded networking space.

Given Moorestown will launch in the same timeframe as Nehalem (Intel's first microarchitecture designed specifically for the 45nm node), it's very likely that its processor is simply a Nehalem variant. Indeed, Nehalem is made to be modular, so that Intel can easily produce different processors containing different numbers and mixes of general-purpose processor cores and special-purpose functional blocks (e.g., graphics, video, cryptography) for different market segments. This being the case, it's easy to envision the Moorestown CPU as a Nehalem variant with one CPU core, one GPU core, the standard on-die memory controller that Nehalem products will feature, and a block containing video encode and decode hardware.

If Moorestown's CPU turns out to be a Nehalem flavor, then by the end of 2008 we'll have reached the truly remarkable state where a smartphone and a supercomputer cluster can be built on the same processor base and can run the same OS kernel (Linux) binaries for everything from instant messaging to nuclear blast simulation.

The big question about Moorestown is its integrated GPU. Even at 45nm, there won't be nearly enough transistors available on an SoC die to add a GPU that performs anything like a discrete GPU. Rather, we can expect performance that's something like Intel's integrated graphics processors. Real 3D rendering horsepower will be confined to dedicated, discrete GPUs for the foreseeable future.

Even if it's short on 3D rendering power, Moorestown marks the point at which an x86 processor can feasibly fit into a smartphone-class product. Chandrasekher showed off a device, pictured in the slide below, that looks remarkably like an iPhone.

A slide from Anad Chandrasekher's IDF keynote. Source: Intel

If Intel does meet its design goals with Moorestown, then we won't have to wait for the 32nm node to see a generation of phones that run the same OS binaries as a desktop PC. At that point, it would take a lot less of an investment of programmer time for Apple to fully incorporate the iPhone as a target in its Xcode toolset, enabling developers of third-party OS X apps to easily make mobile versions of their products.

Moorestown

CPU	Unnamed (probably Nehalem-based) 45nm SoC
CPU features	Single- and dual-core. 50 percent less power than Menlow. Includes an on-die GPU, video encode and decode blocks, and a DDR3 memory controller
Chipset	Integrated northbridge, discrete I/O controller with storage and communication hardware
GPU	Integrated onto CPU die
Memory	DDR3
Networking	802.11n and WiMAX
Storage	NAND flash
Battery life	"All day"
Arrives	Second half of 2008

Postscript: the threshold of inferiority

Over the years, I've attempted with varying degrees of seriousness to coin a number of laws, rules, lemmas, and corollaries, but at this point I've given up and am content to repeat laws with other peoples' names on them. But if I were to give a name to the following law, I'd call it "Hannibal's Law of x86 Inevitability." The "law" goes something like this:

The moment an x86 processor becomes available that you can squeeze into your implementation's design parameters (cost, performance, features, power, thermals, etc.), then the x86 legacy code base makes that processor the optimal choice for your implementation.

Note that an x86 solution does not have to outperform (by whatever metric is important to you) the non-x86 competition in your application niche for it to be the overwhelming choice. Rather, x86's legacy code base makes it compelling when the degree to which is inferior to the competition narrows beyond some threshold, due to the cost and feature advantages of running the x86 software stack.

I firmly believe that this law applies to almost every niche in computing, from embedded to GPUs to high-performance computing. You may think x86 is old and busted, but what you or I think about ISA design doesn't really matter. Or, you may be a code geek with lots of experience in your particular niche who believes that some combination of cross-platform development tools and binary translation is good enough to make ISA irrelevant to any hardware design decision, but you are wrong, wrong, wrong. (At this point, you can imagine me banging my shoe on the table like Khrushchev at the UN, promising that x86 will bury you... except that Khrushchev was ultimately mistaken, and I am not.) The moment that someone makes an x86 solution that can compete in your niche, then the Invisible Hand of the Market will seize the x86 legacy code base and bludgeon the competition with it.

I've seen this law in operation for almost a decade now, and I expect to see it in operation for another decade. In fact, I'll end this article by going out on a limb to assert something that many people whose opinions I respect will consider ludicrous: the coming decade will end with the dominance of x86 in the embedded, GPU, and high-performance computing niches. Count on it.