From WrightJeffreyM at JohnDeere.com  Sun May  1 18:07:37 2011
From: WrightJeffreyM at JohnDeere.com (Wright Jeffrey M)
Date: Sun, 1 May 2011 11:07:37 -0500
Subject: [smokeping-users] Smokeping IPv6 Support
Message-ID: <F559B5215A585F4CA50725F0890C2C6801FA71F82E@edxmb25.jdnet.deere.com>

Does Smokeping support IPv6?

Thank You,
Jeff Wright


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110501/3dac04a5/attachment.htm 

From tobi at oetiker.ch  Mon May  2 09:26:13 2011
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Mon, 2 May 2011 09:26:13 +0200 (CEST)
Subject: [smokeping-users] Smokeping IPv6 Support
In-Reply-To: <F559B5215A585F4CA50725F0890C2C6801FA71F82E@edxmb25.jdnet.deere.com>
References: <F559B5215A585F4CA50725F0890C2C6801FA71F82E@edxmb25.jdnet.deere.com>
Message-ID: <alpine.DEB.2.00.1105020925090.21955@sebohet.brgvxre.pu>

Hi Jeffrey,

Yesterday Wright Jeffrey M wrote:

> Does Smokeping support IPv6?

it has not been tested with v6 by me, but since there is no general
ip magic inside, I would imagine fixes to the be limited or even
unnecessary.

cheers
tobi
>
> Thank You,
> Jeff Wright
>
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900


From Ralf.Hildebrandt at charite.de  Mon May  2 09:53:34 2011
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Mon, 2 May 2011 09:53:34 +0200
Subject: [smokeping-users] Smokeping IPv6 Support
In-Reply-To: <alpine.DEB.2.00.1105020925090.21955@sebohet.brgvxre.pu>
References: <F559B5215A585F4CA50725F0890C2C6801FA71F82E@edxmb25.jdnet.deere.com>
	<alpine.DEB.2.00.1105020925090.21955@sebohet.brgvxre.pu>
Message-ID: <20110502075334.GH10891@charite.de>

* Tobias Oetiker <tobi at oetiker.ch>:
> Hi Jeffrey,
> 
> Yesterday Wright Jeffrey M wrote:
> 
> > Does Smokeping support IPv6?
> 
> it has not been tested with v6 by me, but since there is no general
> ip magic inside, I would imagine fixes to the be limited or even
> unnecessary.

I'm using it with IPv6. What is your concern?
Right now I'm monitoring my ipv6 enabled machines (at home) from my
server, both using ping and SMTP.

-- 
Ralf Hildebrandt
  Gesch?ftsbereich IT | Abteilung Netzwerk
  Charit? - Universit?tsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebrandt at charite.de | http://www.charite.de
	    


From hahn at berkom.de  Mon May  2 14:33:36 2011
From: hahn at berkom.de (Christian Hahn)
Date: Mon, 02 May 2011 14:33:36 +0200
Subject: [smokeping-users] IPv6 address as target for EchoPingHttp not
	working
Message-ID: <4DBEA4A0.3000906@berkom.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

don't know if this is known limitation, but want to bring this to your attention.
I just discovered that one cannot use an IPv6 address as target for
EchoPingHttp. The plug-in gives a warning and the graph is empty:

smokeping 2.003006
echoping 6.0.2

smokeping[8577]: EchoPingHttp: WARNING: "/usr/bin/echoping -p 6 -t 1 -w 1 -6 -h
/ -A -a -R -n 5 2001:db8:x:x:x:x:x:x:80" exited with status 1 - output follows
smokeping[8577]: EchoPingHttp:          getaddrinfo error for host: 2001 Address
family for hostname not supported

Problem is that the plugin automatically appends the port number to the IPv6
address. The result is a not valid IPv6 literal "2001:db8:x:x:x:x:x:x:80".
Embedding the IPv6 address in "[]" helps, as the resulting IPv6 literal with
port appended "[2001:db8:x:x:x:x:x:x]:80" works well with echoping in the shell.
Should be easy for an educated programmer to fix this.

Since this is fixed you should only use FQDN as targets for EchoPingHttp (I
would assume the same is true for EchoPingHttps).

cheers,
Christian
- ------------------
gpg fingerprint:
31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk2+pJ4ACgkQ6kMW7HW8622kYACfVoFycQAqpJ7Etd5zXFsIYAbQ
kYoAoIUz7c1ShR6DRNQLsGMGHHZK/Rbk
=Mm82
-----END PGP SIGNATURE-----


From ntyni+smokeping-users at mappi.helsinki.fi  Mon May  2 14:47:18 2011
From: ntyni+smokeping-users at mappi.helsinki.fi (Niko Tyni)
Date: Mon, 2 May 2011 15:47:18 +0300
Subject: [smokeping-users] IPv6 address as target for EchoPingHttp not
 working
In-Reply-To: <4DBEA4A0.3000906@berkom.de>
References: <4DBEA4A0.3000906@berkom.de>
Message-ID: <20110502124718.GA3634@madeleine.local.invalid>

On Mon, May 02, 2011 at 02:33:36PM +0200, Christian Hahn wrote:
 
> smokeping[8577]: EchoPingHttp: WARNING: "/usr/bin/echoping -p 6 -t 1 -w 1 -6 -h
> / -A -a -R -n 5 2001:db8:x:x:x:x:x:x:80" exited with status 1 - output follows
> smokeping[8577]: EchoPingHttp:          getaddrinfo error for host: 2001 Address
> family for hostname not supported
> 
> Problem is that the plugin automatically appends the port number to the IPv6
> address. The result is a not valid IPv6 literal "2001:db8:x:x:x:x:x:x:80".
> Embedding the IPv6 address in "[]" helps, as the resulting IPv6 literal with
> port appended "[2001:db8:x:x:x:x:x:x]:80" works well with echoping in the shell.

Yeah, I see. Thanks for the report. I'll look at fixing this.
-- 
Niko Tyni   ntyni at debian.org


From dayton at voxter.ca  Wed May  4 01:36:21 2011
From: dayton at voxter.ca (Dayton Turner)
Date: Tue, 3 May 2011 23:36:21 +0000
Subject: [smokeping-users] RTT Alerts - In Percentages?
Message-ID: <B4EE7D52-49B1-4379-9058-987C810066C3@voxter.ca>

Hello list,

Im curious if I can use percentage operators on the RTT alert type?

For instance, some of my monitored links are less than 15 ms, and should never exceed 60ms, and some links are 100ms and should never exceed 400.  Instead of configuring alert types for each of these varying kinds of hosts, i'd like to build an alerting pattern that allows me to say:

If rtt increases by 50%, then goes back to normal, then increases by 50% again, raise an alert.  Basically I am looking for a condition to identify jitter, when i dont know what "normal" RTT is in milliseconds.

Thanks for any input!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4221 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110503/2165cadf/attachment.bin 

From alter3d at alter3d.ca  Wed May  4 02:02:24 2011
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Tue, 03 May 2011 20:02:24 -0400
Subject: [smokeping-users] RTT Alerts - In Percentages?
In-Reply-To: <B4EE7D52-49B1-4379-9058-987C810066C3@voxter.ca>
References: <B4EE7D52-49B1-4379-9058-987C810066C3@voxter.ca>
Message-ID: <4DC09790.3000300@alter3d.ca>

  Unfortunately, there's no way native to Smokeping that you could do 
this.  Currently there are exactly 2 ways to trigger alerts:  hardcoded 
RTT values, and loss percentage.

It would almost certainly be possible to hack this functionality in, 
though.  If you ever get around to it, I'm sure Tobi would appreciate a 
patch.  :)

- Peter



On 5/3/2011 7:36 PM, Dayton Turner wrote:
> Hello list,
>
> Im curious if I can use percentage operators on the RTT alert type?
>
> For instance, some of my monitored links are less than 15 ms, and should never exceed 60ms, and some links are 100ms and should never exceed 400.  Instead of configuring alert types for each of these varying kinds of hosts, i'd like to build an alerting pattern that allows me to say:
>
> If rtt increases by 50%, then goes back to normal, then increases by 50% again, raise an alert.  Basically I am looking for a condition to identify jitter, when i dont know what "normal" RTT is in milliseconds.
>
> Thanks for any input!
>
>
> _______________________________________________
> smokeping-users mailing list
> smokeping-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110503/d526a0c4/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6014 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110503/d526a0c4/attachment-0001.bin 

From hajar.laklaai at gmail.com  Wed May  4 10:08:42 2011
From: hajar.laklaai at gmail.com (hajar laklaai)
Date: Wed, 4 May 2011 10:08:42 +0200
Subject: [smokeping-users] explanations about the calculation of tops of RTT,
	deviation...
Message-ID: <BANLkTi=Hd+o4xDs8rC2Ujx04psX0J0UnjQ@mail.gmail.com>

 Hi,
As you can notice in the picture the value of Max RTT in the title (value
n?1) doesn't match with the maximum value displayed in the line median RTT
(figure n?2) .Can you provide me an explanation for this difference, because
I don't understand how Smokeping caluclates the figure of maximum RTT ,
deviation... which are displayed in the titles.

I'm also wondering about the meaning of %f that I find in the following
script:


++ max

sorter = Max(entries=>5)

title = Top Max Roundtrip Time

menu = by Max

format = Max Roundtrip Time %f seconds.



Thank you for your help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110504/e8f118c9/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: max RTT issue.JPG
Type: image/jpeg
Size: 46988 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110504/e8f118c9/attachment-0001.jpeg 

From darren at victoriajd.com  Wed May  4 13:50:26 2011
From: darren at victoriajd.com (Darren Murphy)
Date: Wed, 4 May 2011 19:50:26 +0800
Subject: [smokeping-users] Smokeping Alerts
In-Reply-To: <BANLkTik0Q+HB5YEUfJs2XutD-JawJc7kWQ@mail.gmail.com>
References: <BANLkTik0Q+HB5YEUfJs2XutD-JawJc7kWQ@mail.gmail.com>
Message-ID: <BANLkTineQgNnbOk4=rxj4rvOo1Ew_Z4nrQ@mail.gmail.com>

On 25 April 2011 22:44, Alexandre COLONNA <alex.colonna at bjtmail.com> wrote:
> Hi,
> I'm running smokeping 2.4.2 on Centos 5.4 and i have some issues with
> alerts and sending mail.
> In fact, i've configure my smokeping config file like as below and i
> don't receive any email.
> In other hand I can see some Alerts notification in /var/log/messages.

1. Have you specified values for either 'sendmail' or 'mailhost' in
your config file?
2. If yes, have you looked in your local mail log (typically
/var/log/maillog) to see if emails are being sent?

hope this helps,
Darren


From chris-smokeping at skipnote.org  Thu May  5 12:56:21 2011
From: chris-smokeping at skipnote.org (Chris Edwards)
Date: Thu, 5 May 2011 11:56:21 +0100 (BST)
Subject: [smokeping-users] understanding the overview graph
Message-ID: <Pine.SOC.4.64.1105051148400.26164@bowling.cent.gla.ac.uk>

Hi,

So I hopefully understand the "Detail" graph, how the smoke elegantly 
shows the variation in response times, and why most smoke is above the 
median line.

But I'm struggling to understand the "Overview" (and also Multihost) 
graphs, where there is a coloured area around the main lines.  And unlike 
the Detail graph, this Overview coloured area always seems to be equal in 
height both above and below the line.  I can't see how it relates to the 
smoke info on the Detail graph.

Can anyone tell me what this coloured area in the Overview graph means ?

Sorry for being thick!

Chris





From hajar.laklaai at gmail.com  Fri May  6 10:49:56 2011
From: hajar.laklaai at gmail.com (hajar laklaai)
Date: Fri, 6 May 2011 10:49:56 +0200
Subject: [smokeping-users] explanations about the calculation of tops
Message-ID: <BANLkTinRWzA42Tzc=KQKyDXFh2JOV4TVtQ@mail.gmail.com>

Hi,
In the section Top Max RTT the value of Max RoundTrip Time in the title
doesn't match with the maximum value displayed in the line median RTT (in
the key of the image).Can you provide me an explanation for this difference,
because I don't understand how Smokeping caluclates the figure of maximum
RTT , deviation... which are displayed in the titles.

I'm also wondering about the meaning of %f that I find in the following
script:

++ max
sorter = Max(entries=>5)
title = Top Max Roundtrip Time
menu = by Max
format = Max Roundtrip Time %f seconds.

Thank you for your help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110506/e84d74a9/attachment.htm 

From mlp_folder at yahoo.com  Sun May 15 14:55:08 2011
From: mlp_folder at yahoo.com (monloi perez)
Date: Sun, 15 May 2011 05:55:08 -0700 (PDT)
Subject: [smokeping-users] First installation of Smokeping
Message-ID: <748435.23709.qm@web162007.mail.bf1.yahoo.com>

Hi All,

I just installed smokeping on FC 13 and got this error when opening 
/smokeping/sm.cgi.
RRDs::info /var/lib/smokeping/rrd/Ping/DocsFedoraprojectOrg.rrd: ERROR: 
'/var/lib/smokeping/rrd/Ping/DocsFedoraprojectOrg.rrd' is too small (should be 
2986672 bytes) at /usr/share/smokeping/lib/Smokeping/RRDtools.pm line 113.
Any idea on how to fix this.
Thanks,
Mon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110515/523f286b/attachment.htm 

From tim at seoss.co.uk  Thu May 19 10:18:39 2011
From: tim at seoss.co.uk (Tim Small)
Date: Thu, 19 May 2011 09:18:39 +0100
Subject: [smokeping-users] Master slave configuration
Message-ID: <4DD4D25F.1070702@seoss.co.uk>

Hi,

Is there a reasonably easy way to have the master both collect data
itself, and also present data pushed to it by a slave?

Thanks,

Tim.

-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309


From ged at jubileegroup.co.uk  Thu May 19 11:49:33 2011
From: ged at jubileegroup.co.uk (G.W. Haywood)
Date: Thu, 19 May 2011 10:49:33 +0100 (BST)
Subject: [smokeping-users] Master slave configuration
In-Reply-To: <4DD4D25F.1070702@seoss.co.uk>
References: <4DD4D25F.1070702@seoss.co.uk>
Message-ID: <Pine.LNX.4.58.1105191048550.19930@mail3.jubileegroup.co.uk>

Hi there,

On Thu, 19 May 2011, Tim Small wrote:

> Is there a reasonably easy way to have the master both collect data
> itself, and also present data pushed to it by a slave?

Am I missing something?  That's what it does by default...

--

73,
Ged.


From tim at seoss.co.uk  Thu May 19 12:45:57 2011
From: tim at seoss.co.uk (Tim Small)
Date: Thu, 19 May 2011 11:45:57 +0100
Subject: [smokeping-users] Master slave configuration
In-Reply-To: <Pine.LNX.4.58.1105191048550.19930@mail3.jubileegroup.co.uk>
References: <4DD4D25F.1070702@seoss.co.uk>
	<Pine.LNX.4.58.1105191048550.19930@mail3.jubileegroup.co.uk>
Message-ID: <4DD4F4E5.1050405@seoss.co.uk>

On 19/05/11 10:49, G.W. Haywood wrote:
> Is there a reasonably easy way to have the master both collect data
>> itself, and also present data pushed to it by a slave?
>>     
> Am I missing something?  That's what it does by default...
>   

Err, yes you appear to be right - at least it is now (the only thing I
think I changed was to deleted all the RRDs and let it start collecting
again).  The behaviour I saw before was that as soon as I configured a
slave as well, the master stopped collecting data itself.  Hmm, not a
very auspicious first post.  Sorry for the noise...

Tim.

-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.  
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309


From chawkinson at cenic.org  Thu May 19 14:45:40 2011
From: chawkinson at cenic.org (Chris Hawkinson)
Date: Thu, 19 May 2011 05:45:40 -0700
Subject: [smokeping-users] Master slave configuration
In-Reply-To: <4DD4D25F.1070702@seoss.co.uk>
References: <4DD4D25F.1070702@seoss.co.uk>
Message-ID: <4DD510F4.3050306@cenic.org>

Hi Tim,

I've setup a Master with 2 Slave machines. Set the configuration so each 
Slave pings several targets.

With this config, the graphs show both the Slave generated results AND 
the Master's results to the same target.

I actually have a need to turn this "feature" off, but haven't spent a 
lot of time looking into it yet.

Bottom line... I think you are OK without doing anything special.

Chris


On 5/19/2011 1:18 AM, Tim Small wrote:
> Hi,
>
> Is there a reasonably easy way to have the master both collect data
> itself, and also present data pushed to it by a slave?
>
> Thanks,
>
> Tim.
>


From tverrall at gmail.com  Thu May 26 22:58:58 2011
From: tverrall at gmail.com (Tim Verrall)
Date: Thu, 26 May 2011 13:58:58 -0700
Subject: [smokeping-users]  CiscoRTTMonEchoICMP probe and SNMP errors
Message-ID: <BANLkTi=HzbjND0dD0vHWQhHRjZA8wOG2CA@mail.gmail.com>

Hi
New to the group as far as posting goes.
I am having some failures with specific routers running IOS 15.0. Initially
I had used info posted by *Mateusz Blaszczyk* to solve the IOS 15.0 failures
*. *
I changed,

my $pingtimeout =5;

And
>               timeout => {
>                    _re => '\d+',
>                    _example => 15,
>                    _default => $pingtimeout+10,
>                    _doc => "How long a single RTTMonEcho ICMP 'ping' take
at maximum
> plus 10 seconds to spare. Since we control our own timeout the only
purpose of
> this is to not have us killed by the ping method from basefork.",

and this seemed to fix just about all the routers.

However I still have some that are not good. Mostly ASR routers running 15.1
- This is the SNMP debug I get.

May 25 23:38:37.399 UTC: SNMP: Packet sent via UDP to 192.168.91.26
May 25 23:38:37.423 UTC: SNMP: Packet received via UDP from 192.168.91.26 on
GigabitEthernet0/0/0
May 25 23:38:37.424 UTC: SNMP: Set request, reqid 829034108, errstat 0,
erridx 0
 rttMonCtrlAdminStatus.10862 = 5
 rttMonCtrlAdminRttType.10862 = 1
 rttMonEchoAdminProtocol.10862 = 2
 rttMonEchoAdminTargetAddress.10862 = 0A 81  0A 69
 rttMonCtrlAdminTimeout.10862 = 2000
 rttMonCtrlAdminFrequency.10862 = 2
 rttMonHistoryAdminNumBuckets.10862 = 20
 rttMonHistoryAdminNumLives.10862 = 1
 rttMonHistoryAdminFilter.10862 = 2
 rttMonEchoAdminPktDataRequestSize.10862 = 452
 rttMonScheduleAdminRttStartTime.10862 = 1
 rttMonScheduleAdminRttLife.10862 = 70
 rttMonScheduleAdminConceptRowAgeout.10862 = 60
 rttMonEchoAdminTOS.10862 = 184
 rttMonCtrlAdminNvgen.10862 = 2
 rttMonEchoAdminSourceAddress.10862 = 0A 81  06 1E
May 25 23:38:37.451 UTC: SNMP: Response, reqid 829034108, errstat 5, erridx
1
 rttMonCtrlAdminStatus.10862 = 5
 rttMonCtrlAdminRttType.10862 = 1
 rttMonEchoAdminProtocol.10862 = 2
 rttMonEchoAdminTargetAddress.10862 = 0A 81  0A 69
 rttMonCtrlAdminTimeout.10862 = 2000
 rttMonCtrlAdminFrequency.10862 = 2
 rttMonHistoryAdminNumBuckets.10862 = 20
 rttMonHistoryAdminNumLives.10862 = 1
 rttMonHistoryAdminFilter.10862 = 2
 rttMonEchoAdminPktDataRequestSize.10862 = 452
 rttMonScheduleAdminRttStartTime.10862 = 1
 rttMonScheduleAdminRttLife.10862 = 70
 rttMonScheduleAdminConceptRowAgeout.10862 = 60
 rttMonEchoAdminTOS.10862 = 184
 rttMonCtrlAdminNvgen.10862 = 2
 rttMonEchoAdminSourceAddress.10862 = 0A 81  06 1E

Anyone with any bright ideas on this ?

Thanks
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110526/42be7d54/attachment-0001.htm 

From smokeping at adamspiers.org  Fri May 27 16:26:59 2011
From: smokeping at adamspiers.org (Adam Spiers)
Date: Fri, 27 May 2011 15:26:59 +0100
Subject: [smokeping-users] continuous pinging revisited
Message-ID: <BANLkTim4ySTFCE22AhX5xSAChPpG4wzBUg@mail.gmail.com>

Hi all,

Firstly thanks for this very useful software.

I'm trying to set up smokeping to run pings continuously, or as close
as possible to continuous.  I see this has been attempted or at least
considered before:

  http://thread.gmane.org/gmane.network.smokeping.user/4202

My motivation is the same as the original poster there - I need to
capture every single second where there might be network issues.
Therefore I was very surprised to discover that it seems smokeping
does not support this use case.

I found the --nosleep parameter which is mentioned very briefly in the
docs as being "for debugging".  Looking at the main while loop in
Smokeping.pm it seems that this option eliminates all sleeps, so it's
not possible to have certain probes running continuously whilst others
sleep as normal.

Then I looked at setting the 'step' configuration parameter value to
the duration of the probe.  The docs describe this parameter as
follows:

  Duration of the base operation interval of SmokePing in
  seconds. SmokePing will venture out every step seconds to ping your
  target hosts.

Looking at the source code, I see that the intention is that "every
step seconds" includes the runtime of the probe.  For example, if you
have step=60 and pings=10, the probes are launched every 60 seconds,
not every 70 seconds.  For continuous pinging, one might think that
setting step=10 and pings=10 would yield the desired results.
However, there are two problems with this.  Firstly, the code in
question is:

    my $sleeptime = $step - (time-$offset) % $step;
    [...]
    sleep $sleeptime;

so if the probe takes even a fraction over 10 seconds, it ends up
sleeping for nearly another 10 seconds until the next 10 second
boundary.  This means the pings are only happening roughly 50% of the
time, not continuously.  A hack might be to set pings=9, but then the
pings are only happening 90% of the time.  It's possible to get
arbitrarily close to 100% by making both values very high,
e.g. step=1000 and pings=999, but then you lose the granularity of RRD
results.

The second issue is that there is a hardcoded expectation that the
probe runtime will be less than 80% of the polling cycle:

    elsif ($runtime > $step * 0.8) {
        my $warn = "NOTE: smokeping took $runtime seconds to complete
1 round of polling. ".
        "This is over 80% of the max time available for a polling
cycle ($step seconds).\n";
        if (defined $myprobe) {
            $probes->{$myprobe}->do_log($warn);
        } else {
            do_log($warn);
        }
    }

So if you choose continuous pinging, which seems to me (and presumably
the original poster) to be a perfectly reasonable use case, your
logfiles get spammed with messages.

My workaround for now is as follows:

1. Configure steps=10 and pings=10
2. Comment out the lines causing warnings above
3. Invoke with --nosleep

I had a couple of other minor questions:

1. I see mentions of an svn repository on the mailing list, but
   nothing is published.  Where is the latest code available, and
   what's the standard procedure for submitting patches?

2. Why does --debug exit immediately after the first iteration?
   What if you want to debug the sleep cycle?

Many thanks!
Adam


From tobi at oetiker.ch  Fri May 27 17:50:57 2011
From: tobi at oetiker.ch (Tobias Oetiker)
Date: Fri, 27 May 2011 17:50:57 +0200 (CEST)
Subject: [smokeping-users] continuous pinging revisited
In-Reply-To: <BANLkTim4ySTFCE22AhX5xSAChPpG4wzBUg@mail.gmail.com>
References: <BANLkTim4ySTFCE22AhX5xSAChPpG4wzBUg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1105271748050.27002@sebohet.brgvxre.pu>

Hi Adam,

send your patches to the mailinglist ...

the subversion repo is on

https://svn.oetiker.ch/smokeping/

debugging the sleep cycle was just no issue until now ...

cheers
tobi


Today Adam Spiers wrote:

> Hi all,
>
> Firstly thanks for this very useful software.
>
> I'm trying to set up smokeping to run pings continuously, or as close
> as possible to continuous.  I see this has been attempted or at least
> considered before:
>
>   http://thread.gmane.org/gmane.network.smokeping.user/4202
>
> My motivation is the same as the original poster there - I need to
> capture every single second where there might be network issues.
> Therefore I was very surprised to discover that it seems smokeping
> does not support this use case.
>
> I found the --nosleep parameter which is mentioned very briefly in the
> docs as being "for debugging".  Looking at the main while loop in
> Smokeping.pm it seems that this option eliminates all sleeps, so it's
> not possible to have certain probes running continuously whilst others
> sleep as normal.
>
> Then I looked at setting the 'step' configuration parameter value to
> the duration of the probe.  The docs describe this parameter as
> follows:
>
>   Duration of the base operation interval of SmokePing in
>   seconds. SmokePing will venture out every step seconds to ping your
>   target hosts.
>
> Looking at the source code, I see that the intention is that "every
> step seconds" includes the runtime of the probe.  For example, if you
> have step=60 and pings=10, the probes are launched every 60 seconds,
> not every 70 seconds.  For continuous pinging, one might think that
> setting step=10 and pings=10 would yield the desired results.
> However, there are two problems with this.  Firstly, the code in
> question is:
>
>     my $sleeptime = $step - (time-$offset) % $step;
>     [...]
>     sleep $sleeptime;
>
> so if the probe takes even a fraction over 10 seconds, it ends up
> sleeping for nearly another 10 seconds until the next 10 second
> boundary.  This means the pings are only happening roughly 50% of the
> time, not continuously.  A hack might be to set pings=9, but then the
> pings are only happening 90% of the time.  It's possible to get
> arbitrarily close to 100% by making both values very high,
> e.g. step=1000 and pings=999, but then you lose the granularity of RRD
> results.
>
> The second issue is that there is a hardcoded expectation that the
> probe runtime will be less than 80% of the polling cycle:
>
>     elsif ($runtime > $step * 0.8) {
>         my $warn = "NOTE: smokeping took $runtime seconds to complete
> 1 round of polling. ".
>         "This is over 80% of the max time available for a polling
> cycle ($step seconds).\n";
>         if (defined $myprobe) {
>             $probes->{$myprobe}->do_log($warn);
>         } else {
>             do_log($warn);
>         }
>     }
>
> So if you choose continuous pinging, which seems to me (and presumably
> the original poster) to be a perfectly reasonable use case, your
> logfiles get spammed with messages.
>
> My workaround for now is as follows:
>
> 1. Configure steps=10 and pings=10
> 2. Comment out the lines causing warnings above
> 3. Invoke with --nosleep
>
> I had a couple of other minor questions:
>
> 1. I see mentions of an svn repository on the mailing list, but
>    nothing is published.  Where is the latest code available, and
>    what's the standard procedure for submitting patches?
>
> 2. Why does --debug exit immediately after the first iteration?
>    What if you want to debug the sleep cycle?
>
> Many thanks!
> Adam
>
> _______________________________________________
> 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, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900


From ktdreyer at ktdreyer.com  Fri May 27 20:24:44 2011
From: ktdreyer at ktdreyer.com (Ken Dreyer)
Date: Fri, 27 May 2011 12:24:44 -0600
Subject: [smokeping-users] continuous pinging revisited
In-Reply-To: <alpine.DEB.2.00.1105271748050.27002@sebohet.brgvxre.pu>
References: <BANLkTim4ySTFCE22AhX5xSAChPpG4wzBUg@mail.gmail.com>
	<alpine.DEB.2.00.1105271748050.27002@sebohet.brgvxre.pu>
Message-ID: <BANLkTi=6=75Yja7K787uiu1zLoDyFuGCwQ@mail.gmail.com>

On Fri, May 27, 2011 at 9:50 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
> send your patches to the mailinglist ...
>
> the subversion repo is on
>
> https://svn.oetiker.ch/smokeping/

Tobi,

Could you please put this information into a "HACKING" or
"README.DEVEL" file at, say,
http://oss.oetiker.ch/smokeping/pub/trunk/ ?

- Ken


From tim at buttersideup.com  Wed May 18 23:29:30 2011
From: tim at buttersideup.com (Tim Small)
Date: Wed, 18 May 2011 21:29:30 -0000
Subject: [smokeping-users] Master slave configuration
Message-ID: <4DD4350B.9020604@buttersideup.com>

Hi,

Is there a reasonably easy way to have the master both collect data
itself, and also use data from a slave?

Thanks,

Tim.

-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.  
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309