Re: Can someone interpret this please? - an Update
I don't remember this thread, but I wanted to chime in. This one time (at band camp) we had a file server connected to a hub, but someone set the server to full duplex. This was wreaking all sorts of havoc on the LAN. I noticed the large number of late collisions but I didn't know what that indicated. Thanks to someone on this list, I checked the duplex settings and voila, that was it. I've read many times that late collisions are often caused by extra long ethernet cables, but I've never experienced that. I have, however, experienced the duplex-caused late collisions many times. I have to keep a close eye on the LAN guys around here. g "Kevin Wigle" [EMAIL PROTECTED] 2/26/01 12:59:01 PM Group, An update on that late-collision issue I brought to the list a while back. Finally got to talk to a tech with my ISP today and we worked through the circuit. It seems the half-duplex / full-duplex answer wins the prize. At first they tried to get me to verify my router's settings and as I have done many times before, a sh int e0/1 indicated that the interface was not full-duplex. But he wanted me to give a command to change it to half-duplex "just to see what happens". But I suggested he do it on his end first - "just to see what happens". In the meanwhile we were monitoring the router interface with sh int and observing console errors. The console was constantly spewing out transmit errors - late collision. The sniffer was seeing significant alignment errors. Anyway, he "does something" and immediately the console stops scrolling errors. amazing.. So, we're going to stress this circuit a bit before letting them close the ticket. It seems they paid more attention when we said we had a sniffer on the line. thanks for all the responses! Kevin Wigle _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Can someone interpret this please? - an Update
Hi All, When they refer to long they often mean 'real long'. I once looked at a faulty LAN in this case the servers were falling of the end. They got smmart moved the servers out of the computer room and into the middle of the physical LAN this helped slightly. Eventually the rang me and I had a look. Straight away I saw late collision type things (I picked up on the CRC's and Fragments). A cable scan showed 450+ meters on a 10Base2 segment. What had happened was someone tied two segments together with a bit of thin cable about 50 metres long. Also the site used AMP outlets and the spare fly leads were still inserted in the sockets. A repeater and removal of about 100 meters of cable fixed the issue. These days you won't see this type of problem. Teunis Hobart, Tasmania Australia On Monday, February 26, 2001 at 01:19:29 PM, John Neiberger wrote: I don't remember this thread, but I wanted to chime in. This one time (at band camp) we had a file server connected to a hub, but someone set the server to full duplex. This was wreaking all sorts of havoc on the LAN. I noticed the large number of late collisions but I didn't know what that indicated. Thanks to someone on this list, I checked the duplex settings and voila, that was it. I've read many times that late collisions are often caused by extra long ethernet cables, but I've never experienced that. I have, however, experienced the duplex-caused late collisions many times. I have to keep a close eye on the LAN guys around here. g "Kevin Wigle" [EMAIL PROTECTED] 2/26/01 12:59:01 PM Group, An update on that late-collision issue I brought to the list a while back. Finally got to talk to a tech with my ISP today and we worked through the circuit. It seems the half-duplex / full-duplex answer wins the prize. At first they tried to get me to verify my router's settings and as I have done many times before, a sh int e0/1 indicated that the interface was not full-duplex. But he wanted me to give a command to change it to half-duplex "just to see what happens". But I suggested he do it on his end first - "just to see what happens". In the meanwhile we were monitoring the router interface with sh int and observing console errors. The console was constantly spewing out transmit errors - late collision. The sniffer was seeing significant alignment errors. Anyway, he "does something" and immediately the console stops scrolling errors. amazing.. So, we're going to stress this circuit a bit before letting them close the ticket. It seems they paid more attention when we said we had a sniffer on the line. thanks for all the responses! Kevin Wigle _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] -- www.tasmail.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Can someone interpret this please?
On Mon, 12 Feb 2001, Kevin Wigle wrote: Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% The five second utilization numbers in the above line (44%/44%) represent two things. The first number is total processor utilization and the second is processor utilization due to interrupts. The difference in these two numbers would be the sum of 5sec utilization by all other processes. If utilization due to interrupts increases over time, it represents traffic growth. If it jumps alot in a short amount of time, it may be a DoS attack. You can verify the latter by turning on "ip route-cache flow" on suspected interfaces and then looking at the output of "sh ip cache flow". If the processor gets too high with legitimate traffic, you can use cef or dcef (ip route-cache cef, ip cef distributed). Failing that, you'll probably more beefy hardware. Regards, --phil _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Can someone interpret this please?
The CPU is being chewed up by fast switching, which doesn't show up in the output except for five-second utilization. The percentage after the "/" shows interrupt-level CPU usage. I had a similar problem when we were migrating from Netware 4 to Netware 5. A couple of different times we created routing loops and the processor usage on our 7513 went berserk. After we cleared IPX routes, the problem went away. HTH, John Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 1 43764 2491562 17 0.00% 0.00% 0.00% 0 Load Meter 2 11636 3222 0.24% 0.05% 0.01% 66 Virtual Exec 318930504 1542973 12268 0.00% 0.12% 0.11% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 51876 1047 1791 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun 8 0 1 0 0.00% 0.00% 0.00% 0 OIR Handler 9 22296414731 53 0.00% 0.00% 0.00% 0 Environmental mo 10 218428427878510 0.00% 0.00% 0.00% 0 ARP Input 11 0 2 0 0.00% 0.00% 0.00% 0 DDR Timers 12 0 2 0 0.00% 0.00% 0.00% 0 Dialer event 13 4 2 2000 0.00% 0.00% 0.00% 0 Entity MIB API 14 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 15 0 1 0 0.00% 0.00% 0.00% 0 Critical Bkgnd 16 1813952 1898284955 0.00% 0.01% 0.00% 0 Net Background 17 280 401698 0.00% 0.00% 0.00% 0 Logger 18 753540 12440407 60 0.00% 0.00% 0.00% 0 TTY Background 19 890280 12440425 71 0.00% 0.00% 0.00% 0 Per-Second Jobs 20 4 2 2000 0.00% 0.00% 0.00% 0 VNM DSPRM MAIN 21 418788 12440411 33 0.00% 0.00% 0.00% 0 Partition Check PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 Net Input 23 31676 2491564 12 0.00% 0.00% 0.00% 0 Compute load avg 24 6663988207365 32136 0.00% 0.03% 0.00% 0 Per-minute Jobs 25 271380 9070214 29 0.00% 0.00% 0.00% 0 NTP 26 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM Input 27 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM TIMER 28 376484 3755446100 0.00% 0.00% 0.00% 0 ATM Periodic 29 0 1 0 0.00% 0.00% 0.00% 0 ATM ARP INPUT 3041599556 18711784 2223 0.16% 0.33% 0.32% 0 IP Input 31 816012 1448197563 0.00% 0.00% 0.00% 0 CDP Protocol 32 0 1 0 0.00% 0.00% 0.00% 0 Asy FS Helper 33 4 1 4000 0.00% 0.00% 0.00% 0 PPP IP Add Route 34 684 20737 32 0.00% 0.00% 0.00% 0 MOP Protocols 35 0 1 0 0.00% 0.00% 0.00% 0 X.25 Encaps Mana 36 0 1 0 0.00% 0.00% 0.00% 0 MPC Router Proce 37 1579312207411 7614 0.00% 0.00% 0.00% 0 IP Background 38 728 1317552 0.00% 0.00% 0.00% 0 SSCOP Input 39 352 856411 0.00% 0.00% 0.00% 0 SSCOP Output 40 36792210450174 0.00% 0.00% 0.00% 0 SSCOP Timer 41 19659 3322 0.00% 0.00% 0.00% 0 ILMI Input 42 0 1 0 0.00% 0.00% 0.00% 0 SNMP Timers 43 518476167742 3090 0.00% 0.00% 0.00% 0 ILMI Request PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 44 43616205621212 0.00% 0.00% 0.00% 0 ILMI Response 45 610604 1171380521 0.00% 0.00% 0.00% 0 ILMI Timer Proce 46 36 3 12000 0.00% 0.00% 0.00% 0 ATM PVC Discover 47 0 2 0 0.00% 0.00% 0.00% 0 ATMSIG ILMI Time 48 443584 12441294 35 0.00% 0.00% 0.00% 0 ATMSIG Timer 49 224 429522 0.00% 0.00% 0.00% 0 ATMSIG Input 50 0 2 0 0.00% 0.00% 0.00% 0 ATMSIG Client 51 42576304189139 0.00% 0.01% 0.00% 0 TCP Timer 52 532 156 3410 0.00% 0.00% 0.00% 0 TCP Protocols 53 0 1 0 0.00% 0.00% 0.00% 0 Probe Input 54 0 1 0 0.00% 0.00% 0.00% 0 RARP Input 55
Re: Can someone interpret this please?
Bob, Phil - and the group. Thanks for the input, gives me more to think about. Some more history.. This router is a 3620 with OC3 and FastEthernet interfaces. It has 48 meg and is running 12.0(5)XK1. According to Cisco's docs, the 3620 should be able to handle around 20-40 kpps. However, the router shows only around 2.6 kpps almost evenly split in/out. I have been unable to verify exactly on CCO but I suspect that a 3620 cannot handle (very well) two high-speed interfaces - more specifically if one is OC3. I have found info where Cisco, when talking about the OC3 interface for the 3600 series stated: "Max two high-speed network modules in a Cisco 3640 (includes Fast Ethernet, ATM, HSSI)" Now the 3640 has a 100mhz processor and the 3620 has a 80 mhz processor. I'm wondering if the SAR process is overwhelming the 3620? I'm sure I read someplace that only one high-speed interface was recommended for the 3620 but I haven't found that info again. Considering the low level of traffic, what else could be keeping the cpu utilization up so high? Need more info. let me know! Kevin Wigle - Original Message - From: "Phillip Heller" [EMAIL PROTECTED] To: "Kevin Wigle" [EMAIL PROTECTED] Cc: "cisco" [EMAIL PROTECTED] Sent: Monday, February 12, 2001 2:12 PM Subject: Re: Can someone interpret this please? On Mon, 12 Feb 2001, Kevin Wigle wrote: Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% The five second utilization numbers in the above line (44%/44%) represent two things. The first number is total processor utilization and the second is processor utilization due to interrupts. The difference in these two numbers would be the sum of 5sec utilization by all other processes. If utilization due to interrupts increases over time, it represents traffic growth. If it jumps alot in a short amount of time, it may be a DoS attack. You can verify the latter by turning on "ip route-cache flow" on suspected interfaces and then looking at the output of "sh ip cache flow". If the processor gets too high with legitimate traffic, you can use cef or dcef (ip route-cache cef, ip cef distributed). Failing that, you'll probably more beefy hardware. Regards, --phil _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Can someone interpret this please?
As far as I understand... (standard disclaimer) The first number is the total CPU utilization... The second number (after the /) is the total utilization that is being used for interrupts. The difference between these 2 numbers is the amount the router uses for the processes listed below the line. In your case almost 100% of the CPU usage is for interrupts (fast switching is something that causes interrupts) and very little is being used for the various router (proccess switching is done via a proccess) processes. This is possibly good in the fact that all your traffic is being fast switched but bad in the fact that the router is getting overloaded on traffic at it's interfaces. The problem could be cuased by other things too but without more info it's hard to say Bob -Original Message- From: Kevin Wigle [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 10:24 AM To: cisco Subject: Can someone interpret this please? Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 1 43764 2491562 17 0.00% 0.00% 0.00% 0 Load Meter 2 11636 3222 0.24% 0.05% 0.01% 66 Virtual Exec 318930504 1542973 12268 0.00% 0.12% 0.11% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 51876 1047 1791 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun 8 0 1 0 0.00% 0.00% 0.00% 0 OIR Handler 9 22296414731 53 0.00% 0.00% 0.00% 0 Environmental mo 10 218428427878510 0.00% 0.00% 0.00% 0 ARP Input 11 0 2 0 0.00% 0.00% 0.00% 0 DDR Timers 12 0 2 0 0.00% 0.00% 0.00% 0 Dialer event 13 4 2 2000 0.00% 0.00% 0.00% 0 Entity MIB API 14 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 15 0 1 0 0.00% 0.00% 0.00% 0 Critical Bkgnd 16 1813952 1898284955 0.00% 0.01% 0.00% 0 Net Background 17 280 401698 0.00% 0.00% 0.00% 0 Logger 18 753540 12440407 60 0.00% 0.00% 0.00% 0 TTY Background 19 890280 12440425 71 0.00% 0.00% 0.00% 0 Per-Second Jobs 20 4 2 2000 0.00% 0.00% 0.00% 0 VNM DSPRM MAIN 21 418788 12440411 33 0.00% 0.00% 0.00% 0 Partition Check PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 Net Input 23 31676 2491564 12 0.00% 0.00% 0.00% 0 Compute load avg 24 6663988207365 32136 0.00% 0.03% 0.00% 0 Per-minute Jobs 25 271380 9070214 29 0.00% 0.00% 0.00% 0 NTP 26 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM Input 27 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM TIMER 28 376484 3755446100 0.00% 0.00% 0.00% 0 ATM Periodic 29 0 1 0 0.00% 0.00% 0.00% 0 ATM ARP INPUT 3041599556 18711784 2223 0.16% 0.33% 0.32% 0 IP Input 31 816012 1448197563 0.00% 0.00% 0.00% 0 CDP Protocol 32 0 1 0 0.00% 0.00% 0.00% 0 Asy FS Helper 33 4 1 4000 0.00% 0.00% 0.00% 0 PPP IP Add Route 34 684 20737 32 0.00% 0.00% 0.00% 0 MOP Protocols 35 0 1 0 0.00% 0.00% 0.00% 0 X.25 Encaps Mana 36 0 1 0 0.00% 0.00% 0.00% 0 MPC Router Proce 37 1579312207411 7614 0.00% 0.00% 0.00% 0 IP Background 38 728 1317552 0.00% 0.00% 0.00% 0 SSCOP Input 39 352 856411 0.00% 0.00% 0.00% 0 SSCOP Output 40 36792210450174 0.00% 0.00% 0.00% 0 SSCOP Timer 41 19659 3322 0.00% 0.00% 0.00% 0 ILMI Input 42 0 1 0 0.00% 0.00% 0.00% 0 SNMP Timers 43 518476167742 3090 0.00% 0.00% 0.00% 0 ILMI Request PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 44 43616205621212 0.00% 0.00% 0.00% 0 ILMI Response 45 610604 1171380521 0.00% 0.00% 0.00% 0 ILMI Timer Proce 46 36 3 12000 0.00% 0.00% 0.00% 0 ATM PVC Discover 47 0 2 0 0.00% 0.00% 0.00% 0 ATMSIG ILMI Time 48 443584 12441294 35 0.00% 0.00% 0.00%
Re: Can someone interpret this please?
I just checked CCO and there are so many CPU-related bugs in 12.0(5) that I stopped counting after a while. You might want to upgrade, if feasible. Also, try doing a show align to see if you're getting spurious memory access errors. One of the bugs mentioned a high CPU usage due to these. HTH, John Bob, Phil - and the group. Thanks for the input, gives me more to think about. Some more history.. This router is a 3620 with OC3 and FastEthernet interfaces. It has 48 meg and is running 12.0(5)XK1. According to Cisco's docs, the 3620 should be able to handle around 20-40 kpps. However, the router shows only around 2.6 kpps almost evenly split in/out. I have been unable to verify exactly on CCO but I suspect that a 3620 cannot handle (very well) two high-speed interfaces - more specifically if one is OC3. I have found info where Cisco, when talking about the OC3 interface for the 3600 series stated: "Max two high-speed network modules in a Cisco 3640 (includes Fast Ethernet, ATM, HSSI)" Now the 3640 has a 100mhz processor and the 3620 has a 80 mhz processor. I'm wondering if the SAR process is overwhelming the 3620? I'm sure I read someplace that only one high-speed interface was recommended for the 3620 but I haven't found that info again. Considering the low level of traffic, what else could be keeping the cpu utilization up so high? Need more info. let me know! Kevin Wigle - Original Message - From: "Phillip Heller" [EMAIL PROTECTED] To: "Kevin Wigle" [EMAIL PROTECTED] Cc: "cisco" [EMAIL PROTECTED] Sent: Monday, February 12, 2001 2:12 PM Subject: Re: Can someone interpret this please? On Mon, 12 Feb 2001, Kevin Wigle wrote: Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% The five second utilization numbers in the above line (44%/44%) represent two things. The first number is total processor utilization and the second is processor utilization due to interrupts. The difference in these two numbers would be the sum of 5sec utilization by all other processes. If utilization due to interrupts increases over time, it represents traffic growth. If it jumps alot in a short amount of time, it may be a DoS attack. You can verify the latter by turning on "ip route-cache flow" on suspected interfaces and then looking at the output of "sh ip cache flow". If the processor gets too high with legitimate traffic, you can use cef or dcef (ip route-cache cef, ip cef distributed). Failing that, you'll probably more beefy hardware. Regards, --phil _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com _ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Can someone interpret this please?
Kevin and John, A note about the "memory access errors". If the router in question is using a MIPS CPU for example, interrupt processing CPU utlization can also run higher than normal due to an error called an alignment error. Alignment errors occur when the program running on the CPU attempts to access a memory value at an address that violates the memory alignment requirements of the CPU. On MIPS CPUs, 16 bit values must begin at a memory address divisible by 2. 32 bit values must begin at a memory address divisible by 4, and so on. If IOS attempts to access data at an address that violates these restrictions, the CPU generates an exception and calls a special IOS function that retreives the data in segments that don't violate the restrictions. This exception funcation adds MANY more instructions and more CPU time to an otherwise simple operation of accessing a data item. For this reason, alignment errors can have a significant negative impact on performance by consuming extra CPU cycles. You can check the alignment errors by doing a show align from the CLI. - raj ""Kevin Wigle"" [EMAIL PROTECTED] wrote in message 010d01c09520$ff4b7040$[EMAIL PROTECTED]">news:010d01c09520$ff4b7040$[EMAIL PROTECTED]... Dear group, Investigating a router that is starting to loaded down. When I do a sh proc cpu I get 50% or cpu utilization but the stats don't seem to add up to 50%. Is there another way to try and see where the 50% is coming from? sh proc cpu CPU utilization for five seconds: 44%/44%; one minute: 50%; five minutes: 52% PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 1 43764 2491562 17 0.00% 0.00% 0.00% 0 Load Meter 2 11636 3222 0.24% 0.05% 0.01% 66 Virtual Exec 318930504 1542973 12268 0.00% 0.12% 0.11% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 51876 1047 1791 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun 8 0 1 0 0.00% 0.00% 0.00% 0 OIR Handler 9 22296414731 53 0.00% 0.00% 0.00% 0 Environmental mo 10 218428427878510 0.00% 0.00% 0.00% 0 ARP Input 11 0 2 0 0.00% 0.00% 0.00% 0 DDR Timers 12 0 2 0 0.00% 0.00% 0.00% 0 Dialer event 13 4 2 2000 0.00% 0.00% 0.00% 0 Entity MIB API 14 0 1 0 0.00% 0.00% 0.00% 0 SERIAL A'detect 15 0 1 0 0.00% 0.00% 0.00% 0 Critical Bkgnd 16 1813952 1898284955 0.00% 0.01% 0.00% 0 Net Background 17 280 401698 0.00% 0.00% 0.00% 0 Logger 18 753540 12440407 60 0.00% 0.00% 0.00% 0 TTY Background 19 890280 12440425 71 0.00% 0.00% 0.00% 0 Per-Second Jobs 20 4 2 2000 0.00% 0.00% 0.00% 0 VNM DSPRM MAIN 21 418788 12440411 33 0.00% 0.00% 0.00% 0 Partition Check PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 22 0 1 0 0.00% 0.00% 0.00% 0 Net Input 23 31676 2491564 12 0.00% 0.00% 0.00% 0 Compute load avg 24 6663988207365 32136 0.00% 0.03% 0.00% 0 Per-minute Jobs 25 271380 9070214 29 0.00% 0.00% 0.00% 0 NTP 26 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM Input 27 0 2 0 0.00% 0.00% 0.00% 0 ATM OAM TIMER 28 376484 3755446100 0.00% 0.00% 0.00% 0 ATM Periodic 29 0 1 0 0.00% 0.00% 0.00% 0 ATM ARP INPUT 3041599556 18711784 2223 0.16% 0.33% 0.32% 0 IP Input 31 816012 1448197563 0.00% 0.00% 0.00% 0 CDP Protocol 32 0 1 0 0.00% 0.00% 0.00% 0 Asy FS Helper 33 4 1 4000 0.00% 0.00% 0.00% 0 PPP IP Add Route 34 684 20737 32 0.00% 0.00% 0.00% 0 MOP Protocols 35 0 1 0 0.00% 0.00% 0.00% 0 X.25 Encaps Mana 36 0 1 0 0.00% 0.00% 0.00% 0 MPC Router Proce 37 1579312207411 7614 0.00% 0.00% 0.00% 0 IP Background 38 728 1317552 0.00% 0.00% 0.00% 0 SSCOP Input 39 352 856411 0.00% 0.00% 0.00% 0 SSCOP Output 40 36792210450174 0.00% 0.00% 0.00% 0 SSCOP Timer 41 19659 3322 0.00% 0.00% 0.00% 0 ILMI Input 42 0 1 0 0.00% 0.00% 0.00% 0 SNMP Timers 43 518476167742 3090 0.00% 0.00% 0.00% 0 ILMI Request PID Runtime(ms) Invoked uSecs5Sec 1Min 5Min TTY Process 44 43616205621212
