[smokeping-users] Less smoke.
Josh Luthman
josh at imaginenetworksllc.com
Fri May 23 23:54:18 CEST 2008
Honestly I did not even think about going that deep into it.
I know for my Smokeping installation I would rather include the first
big RTT. For example, if the first ping request fails to respond
within the timeout because of this "first ping delay" I want to know
about it.
If you're willing to go into it, I would advise making it a
configuration option. Some people want it, others won't.
I have to say I'm very surprised to see you're so passionate about
this project. I absolutely love it =)
On Fri, May 23, 2008 at 5:40 PM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> Hi Josh,
>
> so in essence what you are saying is that the first ping is special
> and might be worth preserving but it should not be mixed in with
> the others ...
>
> So loosing it in the smoke is good but keeping it as a spearate
> piece of information might be worth doing ...
>
> cheers
> tobi
>
> Today Josh Luthman wrote:
>
>> I want to say thank you very much for publishing this! This is really
>> good information.
>>
>> I do also want to comment that with the ARP cache populating and all
>> that noise on the first ping, I personally would like to have that in
>> my data. This way I can judge if ARP is being way too slow upon new
>> connections. Just personal preference at this point.
>>
>> I do have to give you my compliments, though. Great job!
>>
>> On Fri, May 23, 2008 at 2:29 PM, Tobias Oetiker <tobi at oetiker.ch> wrote:
>> > Hi Ged,
>> >
>> > cool stuff ... thanks for the patch
>> >
>> > tobi
>> > Today G.W. Haywood wrote:
>> >
>> >> Hi there,
>> >>
>> >> It's very common for the RTT of the first ping in a series to be much
>> >> greater than those subsequent. This is easily explained because there
>> >> may be much more work for the routers etc. along the way to do for the
>> >> first packet, they have to populate ARP caches for example.
>> >>
>> >> However this can give very misleading statistics in some cases. I've
>> >> modified my copy of FPing.pm to send one more ping than requested, and
>> >> then to discard the first returned RTT value.
>> >>
>> >> 8<----------------------------------------------------------------------
>> >> *** FPing.pm.original 2008-05-23 15:02:39.000000000 +0100
>> >> --- FPing.pm 2008-05-23 15:08:15.000000000 +0100
>> >> ***************
>> >> *** 32,37 ****
>> >> --- 32,40 ----
>> >>
>> >> The (optional) B<packetsize> option lets you configure the packetsize for the pings sent.
>> >>
>> >> + This version of FPing sends one more ping than requested, and discards
>> >> + the first RTT value returned as it's likely to be an outlier.
>> >> +
>> >> The FPing manpage has the following to say on this topic:
>> >>
>> >> Number of bytes of ping data to send. The minimum size (normally 12) allows
>> >> ***************
>> >> *** 121,127 ****
>> >>
>> >> my @cmd = (
>> >> $self->binary,
>> >> ! '-C', $self->pings, '-q','-B1','-r1',
>> >> @params,
>> >> @{$self->addresses});
>> >> $self->do_debug("Executing @cmd");
>> >> --- 124,130 ----
>> >>
>> >> my @cmd = (
>> >> $self->binary,
>> >> ! '-C', ($self->pings)+1, '-q','-B1','-r1', # Add an extra ping
>> >> @params,
>> >> @{$self->addresses});
>> >> $self->do_debug("Executing @cmd");
>> >> ***************
>> >> *** 134,140 ****
>> >> my @times = split /\s+/;
>> >> my $ip = shift @times;
>> >> next unless ':' eq shift @times; #drop the colon
>> >> !
>> >> @times = map {sprintf "%.10e", $_ / $self->{pingfactor}} sort {$a <=> $b} grep /^\d/, @times;
>> >> map { $self->{rtts}{$_} = [@times] } @{$self->{addrlookup}{$ip}} ;
>> >> }
>> >> --- 137,143 ----
>> >> my @times = split /\s+/;
>> >> my $ip = shift @times;
>> >> next unless ':' eq shift @times; #drop the colon
>> >> ! shift @times; # Junk the first result.
>> >> @times = map {sprintf "%.10e", $_ / $self->{pingfactor}} sort {$a <=> $b} grep /^\d/, @times;
>> >> map { $self->{rtts}{$_} = [@times] } @{$self->{addrlookup}{$ip}} ;
>> >> }
>> >>
>> >> 8<----------------------------------------------------------------------
>> >>
>> >> In some circumstances, the results can be striking:
>> >>
>> >> http://www.jubileegroup.co.uk/JOS/misc/less_smoke.png
>> >>
>> >> --
>> >>
>> >> 73,
>> >> Ged.
>> >>
>> >> _______________________________________________
>> >> smokeping-users mailing list
>> >> smokeping-users at lists.oetiker.ch
>> >> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
>> >>
>> >>
>> >
>> > --
>> > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
>> > http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902
>> >
>> > _______________________________________________
>> > smokeping-users mailing list
>> > smokeping-users at lists.oetiker.ch
>> > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
>> >
>>
>>
>>
>>
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten
> http://it.oetiker.ch tobi at oetiker.ch ++41 62 213 9902
>
--
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
Those who don't understand UNIX are condemned to reinvent it, poorly.
--- Henry Spencer
More information about the smokeping-users
mailing list