[Scamper-dev] DW's code review

[Duane Wessels]

On Wed, 21 May 2003, Matthew Luckie wrote:

> i've put a new version of scamper up at
> http://voodoo.cs.waikato.ac.nz/~mjl12/scamper-0.9.tar.gz
>
 the biggest flaw in the code that i see - one of the last points in this
> code review - is the use of real time when the clock jumps forward or
> back, to figure out
>
>   when to send another probe
>
>   the time elapsed between sending a probe and receiving an ICMP response
>
> this could be fixed if i could figure out a way to get the uptime of a
> machine.  the method used in /usr/src/usr.bin/w/w.c is flawed.  I could
> write a kernel syscall module to allow me access to getnanouptime(9), but
> that's not very portable, if that is a concern.

Here's an approach:

Instead of setting 'nextprobe' before the while loop and
incrementing it inside the loop, you can try setting
'nextprobe' to the current time inside the loop.  For example

    while (...) {
        gettimeofday_wrap(&tv);
	if (timeval_cmp(&tv, &nextprobe) >= 0) {
	    /* time to send a packet */
	    ...
	    /* update nextprobe time */
	    nextprobe = tv;
	    timeval_add(&nextprobe, wait_between);
	}
        ...
	to = get_timeout(&nextprobe);
	select(..., &to);
    }

This sort of solves one problem (sending packets too fast/slow) in
the event of a jump.  (since you only send one packet each time
through the loop).

It doesn't solve the problem of getting a bogus measurement if the
clock is stepped between the time you send and recieve.  To deal
with that you could have some sanity checks.  If the delta time is
negative its obviously bogus.  If its greater than some value (5
sec?), its very likely bogus.

An annoyance with this technique is that scamper probably wont send
packets out at exactly 'wait_between' intervals, but it should be
pretty close.


<hr>

Another way to address this problem (or to not address it) is to assume
that the clock is never stepped.  You can make ntpd always slew the clock.
I've done that in some of my testing and its a little frustrating because
you want to make sure the clock gets set accurately at boot time
(or before the app runs), and that doesn't always happen.

Duane W.