CANOGA PERKINS 9145E NID Software Version 4.10 - Manual (Page 68)

9145E NID Software User’s Manual Diagnostics
Network Performance
56
occurs when packets arrive later (or further apart) relative to previous intervals. The amount of
allowable Jitter depends in large part on the application (e.g., a best-effort data application, like
an email client, can tolerate much more jitter than a streaming video application).
4.6.1.3 Using Latency and Jitter Buckets
The Master NID is responsible for generating synthetic test traffic toward Slave NIDs,
accumulating the replies from the Slaves, and calculating the performance metrics. This could
mean that the NID would require a lot of storage if every performance calculation was saved in
memory.
Take as an example a Point-to-Point GigE service with 100 CoS Instances to be tested. Let’s say
the Service Provider was required to deliver an SLA Report to the customer once a month (T = 1
month) and the rate of synthetic test traffic generation was 1 second (∆t = 1 second). If every
test packet generation results in one calculation held in a 32-bit counter, the Master NID would be
required to store 260 Megabytes worth of data per month.
An alternative approach is to keep track of how many test results fall within a given range of
values. A bucket is a simple counter which represents a range of values. Each time a test result
is calculated to be within a range of value for a particular bucket, the bucket counter is
incremented and the test result value is discarded.
As an example, to measure Latency you might define nine buckets starting at intervals of 20ms,
500ms and 1000ms to capture the number of packets that fall into each interval, as shown in
Figure 4-13.
Figure 4-13 Latency Buckets
If a generated test packet results in a latency calculation of 13ms, then the result falls into the first
bucket in Figure 4-13 (that is, Bucket 1 counter is incremented). If a generated test packet
results in a latency calculation of 150ms, then the results falls into the sixth bucket in Figure 4-13
(i.e., Bucket 6 counter is incremented). In this way, the Master NID only has to keep track of a
small fixed set of bucket counters and can discard (no need to store) each individual test result.
Considering the original example of the Point-to-Point GigE service, the customer would only
need to store 36 bytes worth of bucket counters, instead of 260 Megabytes of test result data.