Re: rrdtool: update fails on negative timestamp

Hi Tobi,

On Fri, Apr 10, 2009 at 09:57:30PM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > On Tue, Apr 07, 2009 at 10:11:57PM +0200, Sebastian Harl wrote:
> > > On Tue, Apr 07, 2009 at 07:35:30PM +0200, Tobias Oetiker wrote:
> > > > Today Sebastian Harl wrote:
> > > > >   $ rrdtool update file.rrd -t ds -- -5:42 && date
> > > > >   ERROR: file.rrd: illegal attempt to update using time -5 when last update
> > > > >   time is 1239115940 (minimum one second step)
> > > > >   1239116951
> > > > >
> > > > > Apparently, this feature got lost somewhere on the way.
[...]
> > The rrdupdate(1) manpage states the following:
> >
> >   N|timestamp:value[:value...]
> >
> >   The data used for updating the RRD was acquired at a certain time.
> >   This time can either be defined in seconds since 1970-01-01 or by
> >   using the letter ?N?, in which case the update time is set to be the
> >   current time. Negative time values are subtracted from the current
> >   time. [...]
> >
> > So, I'd expect the following to happen:
> >
> > When using N:<values>, RRDtool calls time() to get the current time (in
> > seconds since the epoch) and uses that as timestamp when storing the
> > values. That works fine.
> >

Re: rrdtool: update fails on negative timestamp

Hi Sebastian,

I have included the following patch:

Index: src/rrd_update.c
===================================================================
--- src/rrd_update.c    (revision 1808)
+++ src/rrd_update.c    (working copy)
 <at>  <at>  -972,6 +972,11  <at>  <at> 
             return -1;
         };
         setlocale(LC_NUMERIC, old_locale);
+        if (tmp < 0.0){
+            gettimeofday(&tmp_time, 0);
+            tmp = (double)tmp_time.tv_sec + (double)tmp_time.tv_usec * 1e-6f + tmp;
+        }
+
         *current_time = floor(tmp);
         *current_time_usec = (long) ((tmp - (double) *current_time) * 1e6f);
     }

this should take care of the problem ...

cheers
tobi

Today Sebastian Harl wrote:

> Hi Tobi,
>

[PATCH] rrdupdate(1): Mention that negative time values should be separated by '--'.

---
 program/doc/rrdupdate.pod |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/program/doc/rrdupdate.pod b/program/doc/rrdupdate.pod
index cc0b452..49eb8fe 100644
--- a/program/doc/rrdupdate.pod
+++ b/program/doc/rrdupdate.pod
 <at>  <at>  -5,7 +5,7  <at>  <at>  rrdupdate - Store a new set of values into the RRD
 =head1 SYNOPSIS

 B<rrdtool> {B<update> | B<updatev>} I<filename>
-S<[B<--template>|B<-t> I<ds-name>[B<:>I<ds-name>]...]>
+S<[B<--template>|B<-t> I<ds-name>[B<:>I<ds-name>]...]> [B<-->]
 S<B<N>|I<timestamp>B<:>I<value>[B<:>I<value>...]>
 S<I<at-timestamp>B< <at> >I<value>[B<:>I<value>...]>
 S<[I<timestamp>B<:>I<value>[B<:>I<value>...] ...]>
 <at>  <at>  -69,6 +69,10  <at>  <at>  timing right to the second is especially important when you are
 working with data-sources of type B<COUNTER>, B<DERIVE> or
 B<ABSOLUTE>.

+When using negative time values, options and data have to be separated
+by two dashes (B<-->), else the time value would be parsed as an option.
+See below for an example.
+
 The remaining elements of the argument are DS updates. The order of
 this list is the same as the order the data sources were defined in
 the RRA. If there is no data for a certain data-source, the letter
 <at>  <at>  -95,6 +99,11  <at>  <at>  Update the database file demo2.rrd which expects data from a single
 data-source, three times. First with an I<*UNKNOWN*≥ value then with two

Re: [PATCH] rrdupdate(1): Mention that negative time values should be separated by '--'.

Hi Sebastian,

Today Sebastian Harl wrote:

> ---
>  program/doc/rrdupdate.pod |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)

thanks, it's in

tobi

--

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

RRDtool 1.4rc1 with RRDcached performance accelerator

After some more work on the build process, I have put out

  RRDtool 1.4 RC1

it is a copy of the current trunk snapshot

  http://oss.oetiker.ch/rrdtool/pub/beta/rrdtool-1.4rc1.tar.gz

Please test this on the platform of your choice and report any
problems you find to

  http://oss.oetiker.ch/rrdtool-trac/newticket

Below you find the NEWS file for 1.4. If you have any additions,
please tell me.

News for RRDtool 1.4
====================
$Id: NEWS 1840 2009-06-07 11:16:07Z oetiker $

RRD Caching Daemon (rrdcached)
------------------------------
by Florian Forster and Kevin Brintnall

The RRD Caching Daemon can dramatically improve the 'update' performance
of your system.  Due to filehandling overheads, the time it takes todo one
update is virtually the same as to doing two updates in a row.

The Cache Daemon intercepts rrdtool update calls, assembling multiple
updates before writing them to the actual rrd file. When calling rrdtool

FW: [PATCH 1/2] bindings should invoke new rrd_flushcached (instead of rrd_cmd_flush)

Tobi, it looks like this patch was not completely applied?

Specifically, the following files in 1.4rc1 still invoke the bogus
"rrd_cmd_flush" call:

	bindings/perl-shared/RRDs.xs
	bindings/ruby/main.c
	bindings/python/rrdtoolmodule.c

-- 
 kevin brintnall =~ /kbrint <at> rufus.net/

---
 bindings/lua/rrdlua.c           |    2 +-
 bindings/perl-shared/RRDs.xs    |    2 +-
 bindings/python/rrdtoolmodule.c |    2 +-
 bindings/ruby/main.c            |    2 +-
 bindings/tcl/tclrrd.c           |    2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/bindings/lua/rrdlua.c b/bindings/lua/rrdlua.c
index 2060f3b..a93159f 100644

Re: FW: [PATCH 1/2] bindings should invoke new rrd_flushcached (instead of rrd_cmd_flush)

Hi Kevin,

thanks ... added

tobi

Today kevin brintnall wrote:

> Tobi, it looks like this patch was not completely applied?
>
> Specifically, the following files in 1.4rc1 still invoke the bogus
> "rrd_cmd_flush" call:
>
> 	bindings/perl-shared/RRDs.xs
> 	bindings/ruby/main.c
> 	bindings/python/rrdtoolmodule.c
>
>

--

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

build tool-chain updates (was: 1.4rc1 announcement)

> * switched to using automake 1.11 which provides a 'silent' build process,
>   causing errors and warnings to stand out much more than before.
>   by Tobi Oetiker

Tobi,

Are all these version upgrades necessary?  I think we should only insist
on the minimum version required to correctly build the software.

-LIBTOOL_VER="1.5.6"
+LIBTOOL_VER="2.2.6"

1.5.6 continues to build rrdtool correctly on my system...

-AUTOMAKE_VER="1.9.2"
+AUTOMAKE_VER="1.11"

The new version is only 3 weeks old.. unlikely to be picked up by
packagers.  I can still build correctly under 1.9.2.

-AUTOCONF_VER="2.59"
+AUTOCONF_VER="2.63"

I like 'AC_USE_SYSTEM_EXTENSIONS', available since 2.60.  But, everything
still builds correctly on 2.60.  Is it worth forcing this feature or can
we conditionally enable it?

If there are other reasons that make the forced upgrade worthwhile, can
you elaborate?

Re: RRDtool 1.4rc1 with RRDcached performance accelerator

Tobias Oetiker escreveu:
> After some more work on the build process, I have put out
> 
>   RRDtool 1.4 RC1

After applying the missing patches pointed out by Kevin it compiled OK.
Lua bindings also worked OK - make test generated the graph as expected.

--

-- 
Fidelis

Re: [rrd] build tool-chain updates (was: 1.4rc1 announcement)

Hi Kevin,

Yesterday kevin brintnall wrote:

> > * switched to using automake 1.11 which provides a 'silent' build process,
> >   causing errors and warnings to stand out much more than before.
> >   by Tobi Oetiker
>
> Tobi,
>
> Are all these version upgrades necessary?  I think we should only insist
> on the minimum version required to correctly build the software.
>
> -LIBTOOL_VER="1.5.6"
> +LIBTOOL_VER="2.2.6"
>
> 1.5.6 continues to build rrdtool correctly on my system...
>
> -AUTOMAKE_VER="1.9.2"
> +AUTOMAKE_VER="1.11"
>
> The new version is only 3 weeks old.. unlikely to be picked up by
> packagers.  I can still build correctly under 1.9.2.
>
> -AUTOCONF_VER="2.59"
> +AUTOCONF_VER="2.63"
>
> I like 'AC_USE_SYSTEM_EXTENSIONS', available since 2.60.  But, everything
> still builds correctly on 2.60.  Is it worth forcing this feature or can
> we conditionally enable it?