Conference turris::digital_unix

9765.0. "Microsecond resolution from gettimeofday " by MAIL1::GHAHRAMANI () Fri May 09 1997 10:46

My customer, AT&T is setting up stations  to monitor IP traffic in their 
central offices (this is for the Worldnet division). They are using 
Alpha 500/400 workstation to do this.I received this note from AT&T who 
is trying to get mfine-grained timestamps when they  use tcpdump. He followed 
instructions in the FAQ from Digital that describes how to do this but 
has been unable to get it to work. 
He has performed the following:
	1> put this option in kernel and rebuild the kernel and reboot	
	    options MICRO_TIME

The customer's original note is attached.
Can you tell me if this will accomplish what the customer is trying to 
do on all Digital Unix 4.0x systems or whether they need to do the 
setup differently?


Thanks,

Forough

609-497-1773
NOTE, this is an important opportunity, in that if they can get this to 
work, they will use these workstations in all of their central offices.

>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
>
>My original message to Jeff
>
>    Is it possible to improve the resolution by  having the routine
>    that generates timestamps in the packetfilter look at the state of
>    the hardware counter in addition to the  system clock?  A colleague
>    of mine, R. Gopalkrishnan, has tinkered with doing this sort of
>    thing under Linux and is able to get much finer grained
>    measurements. (In Linux  pkts are timestamped by the device driver
>    in the ISR context)
>
>
>Jeff Mogul's reply
>
>    
>The Digital UNIX kernel actually has all the right stuff built
>in (including the fairly tricky support for using this on
>multiprocessors).  However, it is not enabled by default.
>
>This is described in the Digital UNIX FAQ, which is available at
>	http://ftp.digital.com/pub/Digital/dec-faq/Digital-UNIX
>
>where it says:
>
>    P9. How can I get microsecond resolution from gettimeofday(2)?
>    
>    Question: how does one get microsecond resolution from the
>    gettimeofday(2) system call?
>    
>    Answer: Normally, Digital UNIX updates its internal idea of the
>    current time once per clock tick (1024 Hz, or about once per
>    millisecond).  In Digital UNIX V4.0 and later, it is possible
>    to rebuild the kernel to support approximately microsecond
>    resolution from the gettimeofday(2) system call, and from the
>    various library routines that use this system call.
>    
>    To enable this option, add the following line to the kernel
>    configuration file and rebuild the kernel:
>    
>	    options MICRO_TIME
>    
>    The system clock (CLOCK_REALTIME) resolution as returned by
>    clock_getres(3) will not change.  Timer resolution remains the same.
>    However, the granularity of the time returned by gettimeofday(2) and
>    clock_gettime(3) will now be in microseconds. The time values returned
>    are SMP safe and monotonically increasing.
>    
>    The high-resolution clock can be used for timestamping and for
>    measuring durations on the order of microseconds, such as time spent in
>    some critical code path.
>
>It's also described somewhere in the Digital UNIX documentation,
>but I can never remember where.
>
>Note that (as far as I know) this affects the packet filter timestamps
>as well as gettimeofday().  I.e., reconfigure the kernel, reboot,
>and your tcpdump timestamps will be what you want.
>
>The actual timer probably has an accuracy of a few microseconds,
>because of the variability in the code-path length (reading the
>cycle counter via several procedure calls).  Note that since the
>packet filter mechanism timestamps the packets only after they
>have been removed from the interface queue, if there is any
>significant queueing in the interface buffers, the timestamps
>that you see will be shifted from the actual packet spacing
>on the wire.
>
>-Jeff
>
>
>
>
>


RFC-822-headers:
Received: from pkohub1.athena.pko.dec.com by gcpmpk.pko.dec.com
 (PMDF V5.1-8 #21006) with SMTP id <[email protected]> for
 [email protected]; Thu, 8 May 1997 17:15:13 EDT
Received: by pkohub1.athena.pko.dec.com with SMTP
 (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
 id <[email protected]>; Thu,
 08 May 1997 17:19:45 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63

    
    This is documented in the Release Notes for 4.0, page 1-24. Here is
    part of what is says:
    
    "The system clock (CLOCK_REALTIME) resolution as returned by
    clock_getres will not change. Timer resolution remains the same.
    However, time as returned by the clock_gettime routine will now be
    extrapolated between clock ticks. The granularity of the time will 
    now be in microseconds. The time values returned are SMP safe,
    monotonically increasing, and have 1 microsecond as the appraent
    resolution."
    
    Have they tried using clock_gettime(3) instead of gettimeofday ?
    If not, that's what I would suggest since I know that works as
    described above. 
    
    Hope this helps!
    
    Lee
     

    Just for the record, clock_gettime() simply calls gettimeofday()
    and turns tv_usecs into tv_nsecs. No magic there. I'd like to
    know what call packetfiler makes to get the time. Is this a
    user mode thing?

    I run this all the time and it works fine.
    
    Did they remember to move the new kernel to / before they
    rebooted?  It probably some little mistake like that causing
    the confusion..
    
    John
    

    
    John,
    
    That was the first thing I asked him.  He claims he followed all of the
    steps.
    
    I appreciate your feedback.
    
    Forough

    Check the running kernel via dbx
    
    # dbx -k /vmunix
    (dbx) px microsecond_time
    
    If it returns 0, they don't have the kernel with the MICROTIME
    configured in correctly.
    
    More information about the fine granularity time stamping is described
    in the "Guide to Writing Realtime Programming".  It is available on the
    DOC cd in the bookreader and postscript format.  It is being Webified
    now.
    
    - Vikas

    Here is the stupid program to check if your kernel is doing the time
    extrapolation.  Build and run this program and if the 5 timestamps are
    not monotonically increasing, your kernel is not doing the microtime.
    
    ----------------cut here--------------
#include <sys/timers.h>

#define LOOPCNT 5

int dummy() {}

main ()
{
  int i;

  struct timespec dummyspec[LOOPCNT];

  for (i=0; i < LOOPCNT; i++) {
    dummyspec[i].tv_sec = dummyspec[i].tv_nsec = 0L;
  }

  printf("Starting ...\n");
  for (i=0; i < LOOPCNT; i++) {
    getclock(TIMEOFDAY, &dummyspec[i]);
  }
  printf("... done!\n");

  for (i=0; i < LOOPCNT; i++) {
    printf("%2d :->  %ld Sec    %ld nS \n", 
           i, dummyspec[i].tv_sec, dummyspec[i].tv_nsec);
  }
}

Now that we have a customer using this, can you make a request to make this
option show up during the kernel configuration?  It would be an excellent
idea to remove the CDFS menu choice (make that mandatory) and replace that
line item with microsecond resolution.

- Vikas

    Vikas, shame on you for using the obsolete getclock function!
    
    >  for (i=0; i < LOOPCNT; i++) {
    >    getclock(TIMEOFDAY, &dummyspec[i]);
    >  }
    
    Folks, that should be gettimeofday() [UNIX95] or clock_gettime()
    [1003.1b, UNIX98].
    
    :^)
    

    
    
    Will this work on Digital Unix 3.2G as well?  Is the procedure the
    same?
    
    Thanks,
    
    Forough

    MICRO_TIME option isn't in V3.2G...  first release was v4.0.
    
    /jim
    

    
    Thanks for the information.  Is there a way the customer can get the
    granularity he needs in 3.2G as mentioned in .0 via other parameters?
    Or does he need to go to V4.0?
    
    Forough