The following is based off of work I did with a customer recently. They really wanted to test QoS to the Nth degree. The idea was to give them the techniques for testing each aspect of the system separately, then try and combine some things (but we never got to that). But it certainly helped understand what each of the Histograms can be used for. This also helps understand why you might use the different results modes like Basic vs. Forwarding Performance vs. Histogram, etc. You can use the Interarrival Time Histogram versus Jitter mode for measuring how periodic your traffic is. Note that the Interarrival Time Histogram works for non-test traffic too; and/or if using to measure Jitter (the old way), you need a periodic source with no frame loss. However, the only true way to measure Jitter is to use the Jitter Histogram mode, because Inter-arrival time uses just the delta time between frames, whereas Jitter is the difference in delay of two frames. Using the Frame Length Histogram versus using the Analyzer Filter on IP total bits. The former gives you a better understanding frame size ratios in real time, but the latter can track every frame size (remember Histograms are limited to 16 buckets). Note that both works for non-test traffic too. Also, since "automatic mode" only works with the Latency Histogram, you need to set up the Frame Length Histogram buckets manually. I usually set for specific bucket sizes as follows: for undersized frame tracking Make sure that the first bucket is set to: x < 64 for 64 byte frame tracking: 64 <= x <65) for 576 byte frame tracking: 576 <= x <577) for 1500 byte frame tracking: 1500 <= x <1501) for oversized frame tracking make sure the last bucket is set to: x > 1500 and remaining buckets in-between these to account for random size frames You can use Sequence Run Length Histogram to determine the number consecutive frames that arrived where current sequence number is exactly 1 greater then the previous (thinking in terms of "next expected" as it was with SmartBits or Basic Sequence Tracking with Spirent TestCenter). In any case though our sequence does not start with zero (just a random number instead). Here is an example of it usage: For testing WFQ, use the Sequence Run Length Histogram to see bursts of smaller frames. Use two Stream Blocks, one with small frames and one with large. Use Analyzer filters to combine them into one histogram (i.e., turn off the 32 bit filter over the stream ID). In that condition the Sequence Run Length will allow you to see that bursts of smaller frames is occurring (or at least that one or the other being favored). You can use the Sequence Diff Check Histogram to determine exact 1-to-1 queue scheduling. The set up is sending traffic from 2 ports to 1, no congestion so the rate is below 50%. Now how do you measure if the switch forwards the packets between them exactly as received in the ingress ports. First, use the Analyzer Filter on the Rx port to aggregate the two streams into one record (i.e., turn off the 32 bit filter over the stream ID). Then using Sequence Diff Check and you should see that "only" one bucket increments; a larger bucket considering the seq #s for the two different streams are far off to begin with. However, if the smallest bucket "<2" is also incrementing, it means the one or the other stream are receiving consecutive frames.
Course: Spirent TestCenter Continuing Education course Series: Essentials of Courses
Please view the attachment too