[smokeping-users] rtt alert granularity

Thomas Klein smokeping at thomas-klein.de
Tue Jan 19 15:13:04 CET 2010

This looks like the related code in sub check_alerts:
                my $rtt = "rtt: ".join ", ",map {defined $_ ? (/^\d/ ? 
sprintf "%.0fms", $_*1000 :$_):"U" } @{$x->{rtt}};

I have changed sprintf "%.0fms" to sprintf "%.3fms" and do now get 
results lke
rtt: 0.260ms
as needed.

Will this change have any unwished side effects?


Thomas Klein wrote:
> The measurements are already done with the right granularity and they do 
> also show up fine in the graphs. E.g. median rtt: 665.5 us avg   696.8 
> us max ....
> They are only not send out with the measured granularity in the alarm 
> messages. So my question is how to fix this presentation issue.
> Greetings,
> Thomas
> G.W. Haywood wrote:
>> Hi there,
>> On Tue, 19 Jan 2010, Thomas Klein wrote:
>>> i have now setup alerts but do not get the needed granularity logged.
>>> ...
>>> What can i do to get the measured rtt with microsecond granularity?
>> I thought I'd explained that to you in my mail of 15 January.  Under
>> some circumstances, some implementations of the timing functions give
>> granularities of the order of several milliseconds.  You will need to
>> check first of all that your 'ping' for example is capable of giving
>> reasonable results.  On a dual Opteron server here, the Debian kernel
>> installation was fine until I upgraded the kernel one day and then it
>> started to give RTTs in integer multiples of 4ms.  After quite a lot
>> of messing around I found that the good folks at Debian had changed a
>> part of the kernel configuration.  I had to use a kernel boot command
>> clock=tsc
>> to get the gettimeofday() C library function to return more reasonable
>> values.  Note that I still do not know much about the accuracy of the
>> values, and there still could be something horribly wrong, but for the
>> moment if there is something wrong it doesn't seem to be hurting me so
>> I've moved on.  I have no reason to believe that the problems I've had
>> with the Opteron machine are the same as the problems you have now.
>> Here's a random example of the sort of thing you need to worry about
>> if you take time measurements on computers seriously:
>> http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
>> http://lkml.indiana.edu/hypermail/linux/kernel/0411.1/2135.htm
>> --
>> 73,
>> Ged.
> _______________________________________________
> smokeping-users mailing list
> smokeping-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users

More information about the smokeping-users mailing list