Firstly let me say thanks to Jeremy Grossmann (principal programmer for GNS3) for helping me finally get my head around this concept. I have to admit that I’d I had only a vague idea of what was happening when I wrote this post on the GNS3 forum, but recently I decided I had to nail it.

In a nutshell:

Without an Idle-PC set, dynamips attempts to emulate instructions one at a time as fast as it can, consuming up to 100% of the available CPU.
The Idle-PC is a guess at where the Program Counter might be pointing to an idle-loop in the emulated router.
When emulator has visits this PC value Idle-Max times, it suspends itself for Idle-Sleep ms to allow other processes to get on their tasks.

Details

To understand the dynamips/GNS3 Idle-PC concept, you have to start by looking at the way software operates.

A normal piece of software generally has one or more places in the code where the program just sits in an “idle” loop – say waiting for a key press. Or a message to arrive. Or for a timer to expire to remind it to send a message.

However dynamips is a different kind of program. It is an emulator. It takes a binary image of MIPS machine code and interprets each instruction one at a time and then executes that instruction on the host computer. The basic logic is something like this:

Set the program counter (PC) to 1
Repeat forever {
 Fetch MIPS instruction number PC
 Emulate it on the host computer
 Increment the Program Counter (PC++)
}

So there are no idle states – dynamips just screams through those instructions one at a time around and around – except that there will be many, many places where the instruction that is executed is one that changes the program counter, causing dynamips to extract the instructions in a non-linear sequence.

And some of those instructions will be be in little groups where the emulated router is sitting in an idle state – as in waiting for a packet to arrive or a key to be pressed at the console. The problem is, dynamips has no idea whether the current Program Counter (PC) is pointing to an instruction that is doing something important, or one that is just part of the few instructions that get repeated over and over in an idle loop.

Now if dynamips could somehow know that when the Program Counter (PC) was pointing to a certain pice of code that was just an idle loop, it could suspend itself for a while, so the logic would change to:

Repeat forever {
 Fetch MIPS instruction number PC
 Emulate it on the host computer
 Increment the Program Counter (PC++)
 IF the new PC is pointing to an idle loop {
   THEN have a sleep and let the host computer get on with something else
   ELSE continue
 }
}

But dynamips has no way of knowing “IF the new PC is pointing to an idle loop” – because dynamips cannot predict future instructions nor understand them. This makes it impossible to optimise the executed code like compilers do or to know if the instructions are worth being executed.

So we make some guesses at when the Program Counter MIGHT be executing an idle loop. We call this value the Idle-PC value.

If we guess at a place where the emulated router spends a lot of idle time, then the host computer gets lots of chances to get on with other stuff. If we guess a PC (remember PC=Program Counter) where the code is only executed rarely, then the host computer will spend 100% of its CPU executing the dynamips simple loop.

Since every Cisco router image has a different set of instructions, these idle lops will be in different places on different images. But once a good Idle-PC has been found for one image, it should be good for all emulations of that image – no matter whether you are running your dynamips on a Windows computer, and OS X Macintosh, a Linux box or an iPad :J

The only other issue then, is how long and low often should dynamips sleep for when it has found the PC for the idle loop? This is where the Idle-Max and Idle-Sleep values found under the Advanced settings of the GNS3 IOS images and hypervisors dialogue come in. (Note: This feature was added to GNS3 in version 0.8.4)

Dynamips doesn’t go to sleep EVERY time the PC hits the Idle-PC. It waits until it has hit the Idle-PC Idle-Max times before sleeping for Idle-Sleep ms. That way the router still gets a chance to do the things it needs to do between visits to the Idle-PC value. If you adjust the Idle-Max too low or the Idle-Sleep too high, your emulated routers will slow to a crawl, they will loose connections with their neighbours and bad things will happen. However some folk have had good success at playing with these numbers.

To summarise:

Without an Idle-PC set, dynamips attempts to emulate instructions one at a time as fast as it can, consuming up to 100% of the available CPU.
The Idle-PC is a guess at where the Program Counter might be pointing to an idle-loop in the emulated router.
When emulator has visits this PC value Idle-Max times, it suspends itself for Idle-Sleep ms to allow other processes to get on their tasks.

Remember, if you found this post helpful, you can make it easier for others to find by giving it a good rating, or by clicking on one of the sharing options.