[smokeping-users] rtt alert granularity

[Thomas Klein]

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