• cisco RSP1 (R4700) processor with 65536K/2072K bytes of memory.
  R4700 CPU at 100Mhz, Implementation 33, Rev 1.0
• 1 ATM network interface, VIP2 R5K controller
• 1 FastEthernet/IEEE 802.3 interface, VIP2 controller
• IOS (tm) RSP Software (RSP-JSV-M), Version 12.0(7)T, RELEASE SOFTWARE (fc2)

Test Description

1. Topology
   The two FastEthernet (duplex) intrfaces of the SmartBits are connected back-to-back to the FastEthernet interfaces of the C7500 and C7200
   The ATM connection between the routers is UBR (155 Mbps) and not shared with other sources of traffic
2. Parameters:
   • variable num of CAR instances: [1, 30]
   • 1 acl per CAR instance, 1 line per ACL
   • CPU utilization: monitored through command:

     show controller vip  tech
     	

   • match position of a CAR instance
3. Stream profile:
   • variable traffic load: [9000, 30000] pack/sec (from 305 to 95% of CPU utilization)
   • packet size: constant, 64 bytes
   • 1 stream, UDP; generated by the SmartBits
4. Router configurations:
   • C7500, 5 CAR
   • C7500, 10 CAR
   • C7500, 20 CAR
   • C7500, 30 CAR
5. Metrics:

Comments:

• Figure 1 shows that the CAR overhead is more evident on the left-hand side of the graphs, when the CPU is not saturated.
  By comparing the light blu curve - corresponding to no CAR instances - with the green curve - 1 CAR - we see that even the smallest rate in use (9000 pack/sec) the increase in CPU utilization is up to 12%.
  
  Fig.1: CPU utilization of the FastEth interface (VIP2, C7500) vs packet rate for different numbers of CAR instances

• While in the test of Fig.1 we assumed that each CAR instance is matched by a given stream, in this test we verify the influence of the match position on CPU. We define match position the sequence number of the CAR instance whose corresponding ACL is matched by the CAR statement. We compared two cases:
  1. All the CAR instances configured on the FastEth interface are matched by 1 stream
  2. None of the CAR instances is matched by a packet: this implies that for each packet the whole list of CAR instances has to be scanned.
  
  (Note: in the two cases the overall packet rate is maintained constant - 9000 pack/sec -, the packet size in use is always 64 by. In addition in the no match case, ony a single flow is generated by the SmartBits, but its rate is equal to the rate of the with match case.)

  In Figure 2 for 10 CAR statements or more, the difference between two corresponding points in the curves is the overhead introduced by the need to scan the whole CAR list, which is up to 20% of the CPU cycles.
  With 5 CAR statments the two cases are equivalent, while with just 1 CAR instance since the scan overhead is the same, we can assume that the difference is the overhead introduced by the marking action, which does not apply in the no match case.

  
  
  Fig.2: impact of the match position on CPU utilization

• We have verified the impact of the CPU overhead introduced by CAR on both one-way delay and IPDV, whose average values for different CPU overhead values are plotted in Figure 3. Results show that the influence on one-way delay and IPDV is very small: only additional 30 microsec in delay and 1 microsec in IPDV for a CPU increase of 42%.
  
  
  Fig.3: (a) average one-way delay and (b) average IPDV for different numbers of CAR instances (i.e. different CAR overhead values)
  Figures 4 and 5 confirm the results on delay and IPDV illustrated in Figures 3.
  
  Fig.4: (a) one-way delay frequency distribution and (b) its corresponding complementary prob. density funct. for different numbers of CAR instances (i.e. different CAR overhead values)
  
  Fig.5: IPDV frequency distribution without CAR and with 30 CAR instances

  Figures in larger format:

  • Fig 3(a) and Fig 3(b)
  • Fig 4(a) and Fig 4(b)