AnswerJim Warner says: A microburst is a burst of frames too short to be measured by polling.At its genesis in 1990, SNMP designers went to great pains to keep the front end data collection agent as simple as possible. SNMP started with zero market share. If the client was not light weight, it would have been relegated to the dust bin of ideas that were too expensive for the real world. That required a polling model. Agent gets a question; agent answers question. No state retained. Polling is inefficient. And that really comes home when you attempt to run the poll rate up high enough to improve time resolution to see short events. ----------------------------------------------------------- Nice paper with empirical data on bursts in the data center. http://research.microsoft.com/pubs/136788/wren09.pdf ----------------------------------------------------------- Arista has an article on microbursts written in response to a Miercom test report that they did not like. They also published a white paper explaining microbursts. Dale Shaw dale.shaw+cisco-nsp at gmail.com Fri Apr 24 00:38:01 EDT 2009 Next message: [c-nsp] The dreaded microburst - definition and troubleshooting Hi all, Is there a universally agreed upon definition for a 'microburst'? Is there a defined time measurement - i.e. 5ms, 10ms, 50ms, 100ms, 1000ms - during which a certain bps or pps threshold must be met/exceeded? Does anyone have any tips for troubleshooting microbursts, particularly in relation to the c7200 platform exhibiting "no buff" drops? We're going to capture some data (w/SPAN on an adjacent switch) but it would be nice to be able to look at the data and somehow marry it up with incrementing drop counters on the affected c7200 interface. It would be nice to be able to explain such drops like "within the measurement window, we saw traffic at bps/pps rate x, and we know that anything beyond bps/pps rate y will result in drops". I suppose it's platform-specific, but how does one come up with an accurate benchmark? Is such precision just wishful thinking in the murky world of microbursts? :-) cheers, Dale ================================================= Ian Cox icox at cisco.com Fri Apr 24 12:56:21 EDT 2009 Previous message: [c-nsp] The dreaded microburst - definition and troubleshooting The definition I generally use is this: [snip] A microburst is when packet drops occur when there is not sustained or noticeable congestion upon a link or device. Example: The 1 minute utilization of a link is 20% and packet drops are occurring. Microbursts happen in every packet based network where flow control is not extended end to end in all types of switches both blocking and non-blocking. [end snip] I principally work on high end switching and the 4 main ways we see it occur: - Speed Mismatch (10G into 1G, 10G into 10M) More extreme the speed mismatch the more dramatic the issue. - Network Oversubscription, Example 20 1G hosts using 1x10G uplink - L2 Unicast Flood - Synchronization of flood from multiple hosts - L2 Multicast - Synchronization of multicast from multiple hosts in large any to any multicast environments. Microbursts are how packet networks work that do not have end to end flow control. (End to end flow control is no panacea, you then have to create ways to prevent deadlock situations) You can use larger buffers to mask the issue, but that increases the latency and causes jitter. You can end up with the situation of packets arriving in extreme cases tens of seconds latter. Dropping packets is not the end of the world, it puts a limit on how large the latency and jitter can grow. Ian cisco-nsp mailing list cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ |