[smokeping-users] rtt alert granularity

[Thomas Klein]

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?

Greetings,
Thomas

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
>
>