Loading ...
Sorry, an error occurred while loading the content.

Re: Moving RRDtool files to internal memory - where?

Expand Messages
  • d0nv
    Thanks for mentioning the UDP broadcast. For me, the two machines will be on separate networks across the internet so I don t think that will work in my
    Message 1 of 10 , Jan 5, 2011
    • 0 Attachment
      Thanks for mentioning the UDP broadcast. For me, the two machines will be on separate networks across the internet so I don't think that will work in my application.

      We're running different firmware, so our rrdtool set ups will likely be different... that said, the key is installing temploggerd, which will drag along and set up rrdtool with the associated files and page displays/graphs.

      On unslung, this was as simple as:
      ipkg update
      ipkg install temploggerd

      The default configuration on unslung pretty much worked out of the box for LAN access of the 1-wire data pages/graphs. OTOH, owfs config files required tweaking to work with my iButtonLink LinkUSB adaptors, but it appears you have that sorted.

      I did extensive tweaking of the temploggerd config files afterwards for my purpose. Because I'm exposing this to internet access, I wanted to use an obscure port for port forwarding to minimize random port scans load. That necessitated I move the files elsewhere, etc.

      I have a blog post I'll be updating shortly to detail my overall solution. See http://veino.com/blog/?p=518 if interested.

      --- In nslu2-linux@yahoogroups.com, Doug <dsc3507@...> wrote:
      >
      > Using 1-wire with Debian on NSLU2 here. I do a udp broadcast every 15 minutes to
      > the monitoring site and also have it setup to accept http access to temperatures
      > but I have not implemented rdtool. I would be interested in your configuration
      > there if you would be willing to share it.
      >
      > Doug
      >
      > Doug Crompton
      > WA3DSP
      > www.crompton.com
      >
    • Doug
      Thanks for the rundown. I had considered using the tol but wanted a quick and easy way to get the temps from one place to another. I wrote a udpserver in Perl
      Message 2 of 10 , Jan 5, 2011
      • 0 Attachment
        Thanks for the rundown. I had considered using the tol but wanted a quick and easy way to get the temps from one place to another.

        I wrote a udpserver in Perl that runs and just listens for data on a port at my home location. This location has a static IP so the place I want to monitor sends a udp packet every 15 minutes with the latest 1wire data. There is no handshaking.  This is over the internet and it works fine. I have not missed a 15 minute update and even if I did miss one it would be a trivial problem. On the home router I just open up the selected port to the machine running the server. Security has not been a problem. I only except data with a certain PW in it, I only accept 256 characters or less, and I only allow one reception every minute. Since there is no handshake response anyone that happens to send data to that udp port would have no knowledge they are even talking to an active machine.  Simple but it works.

        Doug
         
        Doug Crompton
        WA3DSP
        www.crompton.com



        From: d0nv <nslu2-yahoo@...>
        To: nslu2-linux@yahoogroups.com
        Sent: Wed, January 5, 2011 1:28:53 PM
        Subject: [nslu2-linux] Re: Moving RRDtool files to internal memory - where?

         



        Thanks for mentioning the UDP broadcast. For me, the two machines will be on separate networks across the internet so I don't think that will work in my application.

        We're running different firmware, so our rrdtool set ups will likely be different... that said, the key is installing temploggerd, which will drag along and set up rrdtool with the associated files and page displays/graphs.

        On unslung, this was as simple as:
        ipkg update
        ipkg install temploggerd

        The default configuration on unslung pretty much worked out of the box for LAN access of the 1-wire data pages/graphs. OTOH, owfs config files required tweaking to work with my iButtonLink LinkUSB adaptors, but it appears you have that sorted.

        I did extensive tweaking of the temploggerd config files afterwards for my purpose. Because I'm exposing this to internet access, I wanted to use an obscure port for port forwarding to minimize random port scans load. That necessitated I move the files elsewhere, etc.

        I have a blog post I'll be updating shortly to detail my overall solution. See http://veino.com/blog/?p=518 if interested.

        --- In nslu2-linux@yahoogroups.com, Doug <dsc3507@...> wrote:
        >
        > Using 1-wire with Debian on NSLU2 here. I do a udp broadcast every 15 minutes to
        > the monitoring site and also have it setup to accept http access to temperatures
        > but I have not implemented rdtool. I would be interested in your configuration
        > there if you would be willing to share it.
        >
        > Doug
        >
        > Doug Crompton
        > WA3DSP
        > www.crompton.com
        >

      • clerew5
        ... As a matter of interest, will it spread stuff out even into neighbouring partitions. I have a 2GB USBstick (twice the size I really need, but you can t buy
        Message 3 of 10 , Jan 6, 2011
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, Mike Westerhof <mwester@...> wrote:

          > Not really. And they're cheap. I'll also mention that modern,
          > good-quality USB flash devices do a good job of wear-leveling, so you
          > can effectively increase the lifetime of the device if you only use a
          > small percentage of the device's space. So, pick a 4GB unit, for
          > example, for 12 USD at your local Walmart store, and expect it to last
          > for years.

          As a matter of interest, will it spread stuff out even into neighbouring partitions. I have a 2GB USBstick (twice the size I really need, but you can't buy them smaller anymore). It is partitioned into 4 lots of 250MB and one of 1GB. Only two of the partitions see anything like heavy use.

          Will that usage spread out into the areas nominally reserved for the empty 1GB? I.e. are the addresses where stuff is actually stored entirely different from their nominal addresses on the "disk", with some lookup table in between?
        • Mike Westerhof
          ... The wear-leveling is done at the block-level, and it is unaware of things like partitions. So it is fair to say that if the read-write cycle count remains
          Message 4 of 10 , Jan 6, 2011
          • 0 Attachment
            clerew5 wrote:
            > --- In nslu2-linux@yahoogroups.com, Mike Westerhof <mwester@...> wrote:
            > Not really. And they're cheap. I'll also mention that modern,
            > good-quality USB flash devices do a good job of wear-leveling, so you
            > can effectively increase the lifetime of the device if you only use a
            > small percentage of the device's space. So, pick a 4GB unit, for
            > example, for 12 USD at your local Walmart store, and expect it to last
            > for years.
            >
            > As a matter of interest, will it spread stuff out even into neighbouring partitions. I have a 2GB USBstick (twice the size I really need, but you can't buy them smaller anymore). It is partitioned into 4 lots of 250MB and one of 1GB. Only two of the partitions see anything like heavy use.
            >
            > Will that usage spread out into the areas nominally reserved for the empty 1GB? I.e. are the addresses where stuff is actually stored entirely different from their nominal addresses on the "disk", with some lookup table in between?
            >

            The wear-leveling is done at the block-level, and it is unaware of
            things like partitions. So it is fair to say that if the read-write
            cycle count remains the same, a 4GB stick will last twice as long as a
            2GB stick, regardless of how the disk is partitioned.

            -Mike
          Your message has been successfully submitted and would be delivered to recipients shortly.