Re: comments on draft-dcbench-def-00 (part 1)
David Newman <[email protected]>
| Newsgroups | gmane.ietf.bmwg |
|---|---|
| Organization | Network Test Inc. |
| Message-ID | <[email protected]> |
On 7/30/13 4:39 AM, MORTON JR., ALFRED C (AL) wrote: > the absolute value function used in 4689 > colapses the positive and negative inter-packet delays together, > and sometimes these have different meanings or causes. Both the RFC 3393 and 4689 definitions use absolute values. 3393 gives two methods of measuring jitter. One references RFC 2598, the other references RFC 1889, and both of these absolute values. RFC 3393 explicitly mentions the use of absolute values for both methods. Thus, this is not really a meaningful differentiator between the 3393 and 4689 jitter definitions. Indeed, it would be very problematic *not* to use absolute numbers. Without them, the mean of a uniform distribution of positive and negative values around some midpoint would give us -- zero. Given Lucien's stated goal of "how to make jitter a simple term for datacenter engineers to understand and to measure" (presumably by representing it as a single number, the mean), and given his examples of 5% and 50% variance, it's unclear how a metric that is typically zero would describe that variance in any simple way. > If, for example, they wish to know the overall jitter from a path > with ten DUTs in series, we can estimate that value but we have to > measure the right metric at the start to do it Also unclear, given the bmwg's black-box approach to measurement, why the number of elements within a single SUT would matter. Agreed that the key question here is what constitutes the "right metric" regardless of whether we measure jitter for one box or lots of boxes as a system. dn