Welcome to Netcordia Connection Sign in | Join | Help
in Search

Determining Broadcast % - Interface Performance

Last post 03-13-2008 9:36 AM by mgriffin. 0 replies.
Page 1 of 1 (1 items)
Sort Posts: Previous Next
  • 03-13-2008 9:36 AM

    Determining Broadcast % - Interface Performance

    This example directly refers to the attached spreadsheet file - Example_Interface-Performance_CSV-Data.xls

     

    The Data:

    1:00AM - Link Utilization = 1.33% - Broadcast Rate = 107/pps - Broadcast Percent = 42% 

    9:00PM - Link Utilization = 0.0769% - Broadcast Rate = 107/pps - Broadcast Percent = 10.5%

     

    The Question:

    How can a BroadcastRate of 107/s be 42% of higher 1.33% Total Line Utilization, than similar Broadcast Rate of 107/s on 0.0769%  Total Line  Utilization that shows 10.5% Broadcast Percent?  

    Shouldn't the 107/s Broadcast Rate be a higher percent, on a link that has a lower total traffic utilization, than one with a higher percent - if same Broadcast Rate?

     

    The Answer: 

    First, let's cover utilization percentage vs packet percentage.

    If the packet size increases and the ratio of broadcasts to unicasts is the same and the total number of packets is the same, then the percentage of broadcast packets is unchanged, but the link utilization increases.  In this example, the packet size increased and the number of unicast packets declined by a big amount while the number of broadcasts remained nearly unchanged.  So utilization went up and the % broadcasts also went up.

    This is why the link being reported had a big change in broadcast percentage vs utilization.  For that time interval, the packet size changed to 6664 bytes per packet.  The prior hour's sample was 588 bytes per packet and successive packet sizes were less than 180 bytes per packet.  So that was a big jump in link utilization while the total number of packets was half that of the prior hour.

    -So the packet size increased, the total number of packets decreased, but the broadcast rate remained constant, so the ratios made it standout.

    A big data transfer job may have started sometime after midnight and that the system doing it was using jumbo packets (9K bytes each), driving up the utilization while using fewer packets.  To figure out why the total number of packets dropped so much when compared to the prior hour - we'd have to understand the apps running over the link to know more. 

Page 1 of 1 (1 items)