Subject: Ping MIB - rfc2925

From: Paul Fraley <[email-masked]>
Date: Mon, 22 Jan 2001 14:06:01 -0800

I posted a request about the arhive of this mailing list advertised
to be at: ftp://ftp.peer.com/pub/disman/archives.  I can't seem to
get to anything at peer.com.

So, I'll apologize in advance if these issues have already been
discussed.  I have some questions about the Ping MIB of rfc2925.
Please let me know if this is not appropriate for the list.

Thanks

Paul
[email-masked]

Question 1.
- the results are given in millisec (ms).  I'm curious why
  that choice was made and not microsecs (us).  I lose all
  precision on a reasonably fast (local) network using ms units.

  Of all the variables that have ms for units in the Ping
  Mib, pingResultsRttSumOfSquares will have the biggest 
  numeric value.  If pingResultsRttSumOfSquares is
  0xFFFFFFFF and pingCtlProbeCount is 15, I believe the
  max value for pingProbeHistoryResponse (rtt) is
  15 * x^2 = 0xFFFFFFFF,  x =  sqrt(0xFFFFFFFF/15),
  x =~ 17000    If the units is ms, this is ok.  If they
  are in us, then that is only 17ms.

  So, if you had a test of 15 probes that took 20ms
  (a reasonable value) you come up with 6 billion for the
  sum of squares, which is more than can be represented in
  a 32 bit u_int.

  To get the microsec resolution, either:
    - the size of the time variables have to be 64bit
    - report the stddev as opposed to the sum of squares
      in the MIB

Question 2.
- pingCtlTimeOut is ambiguous.  From the rfc, I understand
  this variable to represent both:
        - the interval which I send pings out
        - the timeout for any given ping
  such that, I don't ever have more than one outstanding
  ping for any given test.  In other words, I send a ping,
  I wait pingCtlTimeOut, at that point I
        - mark that probe as being timed out
        - send the next probe
  If a probe comes back after I have waited for it, I
  ignore it.

  Is this the intention?

---

From: "Kenneth White" <[email-masked]>
Date: Wed, 24 Jan 2001 04:12:02 -0800

Paul,

>Please let me know if this is not appropriate for the list.

This is the right place to bring up any questions. I did get your
earlier note but am in the middle of changing jobs within my
company and didn't get a chance to reply until now. In any case
its best to ask the questions on the disman list.

>  precision on a reasonably fast (local) network using ms units.

Milliseconds was used since this is typically what these tools
return. Typically, these tools are used to detect problems or
validate service level agreements. Its debatable whether the
additional precision between milliseconds versus microseconds
is worth the cost of adding 64 bit counters.

>    - report the stddev as opposed to the sum of squares

The sum of squares object looks to be adequate if the current
millisecond precision is not changed.

>  Is this the intention?

Yes.

Regards, Ken