What you are seeing is going to be normal. The numbers you quote are from the following document:
http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf
The only thing this document is good for is to compare platform performance to eachother. For example a 2851 should be roughly twice as fast as a 2801 under the same conditions. The first paragraph tries to illustrate this:
"Numbers are given with 64 byte packet size, IP only, and are only an indication of raw switching performance. These are testing numbers, usually with FE to FE, GigE to GigE or POS to POS, no services enabled. As you add ACL's, encryption, compression, etc - performance will decline significantly from the given numbers, unless it is a hardware-assisted platform, such as the ASR 1000, 7600 or 12000, which process QoS, ACL's, and other features in hardware (or when a hardware assist is installed, for instance an AIM-VPN in a 3745 will offload the encryption from the CPU). Every situation is different - please simulate the true environment to get applicable performance values.
Knowing the performance for a specific router platform is not a good indication of how well a specific feature will perform. If a feature is supported in the CEF path, for instance, and we know the feature-free CEF throughput in a specific configuration, then we only know the platform's "never-to-exceed" performance but we do not know the actual performance of any given feature, which will always be less."
For these software forwarding platforms everything is a factor. If the packet size used in the tests of that document were larger the throughput would be higher, but we might not see as many packets per second. The router has to do roughly the same amount of work per packet when forwarding for most features regardless of its size. So for the same packet rate the throughput of 1000 byte packets will be significantly more than 100 byte packets yet the cpu usage will be similar.
In your example we are not process switching. High cpu under interrupt is the router forwarding packets in the fast path. When a router is process switching the packets are not forwarded under interrupt, but are instead given to a process called IP Input. If the cpu due to the IP Input process is not high then the cause is not process switching of traffic.
For every feature enabled in the forwarding path there will be a reduction in the forwarding performance of the router. QOS, ACLs, Netflow, NAT, FW, etc will all cause some sort of impact due to the extra work the cpu has to do to provide that feature. Some features are also more cpu intensive than others. There is no possible way to give a performance scenario for all conditions. A better document would be to look at a Miercom report. Typically these are tests with a lot of common features turned on with a mix of traffic. If you do not use some of the same features then it would be reasonable to expect some improvement to performance.
Overall though it sounds like this rotuer is undersized for the amount of traffic and features you are using. When you try with another platform I would still expect to see the CPU usage due to interrupts. Either the cpu will still be high because even more traffic is being forwarded by the router or the cpu usage will be lower.
