<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    I needed to back up some of my NAS over the WAN to another (friends)
    NAS (3/4TB-total).  A lot of expensive hi-def music files, mostly
    very large.  He backs up to mine, vice versa for disaster recovery.<br>
    <br>
    There were two issues:  1) sucking up all my UL bandwidth, only
    5mbit in this case, 2) having the option to do a "delayed" kill of
    the rsync when it *finished* the current file rather than an
    immediate stop so as not to waste the bandwidth already used to move
    a portion of a large file.<br>
    <br>
    I implemented both with signals.  A signal toggles the
    enable/disable of the --bwlimit=XXX param so you can do a simple
    throttle back or run wide open.  The second signal is a delayed quit
    - when current file is finished.<br>
    <br>
    This seemed to work pretty well.  During the day when I needed the
    BW for work, etc.  I'd throttle it, then let it run wide open at
    night.  This could be expanded with a BW list, so instead of a
    simple toggle, the next BW setting in the list could be used,
    round-robin.  The delayed quit was nice if new content was added
    that I felt I wanted backed up first.  Quit (delayed), then restart,
    easily scripted.<br>
    <br>
    Let me know if there is any interest in putting this in the code
    base and I'll create some diffs for review.<br>
    <br>
    Cheers,<br>
    Frank<br>
    <br>
    <div class="moz-cite-prefix">On 4/3/14, 10:47 AM, Marian Marinov
      wrote:<br>
    </div>
    <blockquote cite="mid:533D747F.2070503@yuhu.biz" type="cite">On
      04/03/2014 03:35 PM, Christoph Biedl wrote:
      <br>
      <blockquote type="cite">Joe wrote...
        <br>
        <br>
        <blockquote type="cite">This is way beyond my level of
          expertise, but wouldn't something like
          <br>
          ionice help with that?
          <br>
        </blockquote>
        <br>
        Although I'm not Marian, probably not. The ionice program does a
        <br>
        reasonable good job when it's about prioritizing read operation.
        The
        <br>
        context makes me guess it's rather about writing.
        <br>
      </blockquote>
      <br>
      We were using ionice and it did not help. The problem is that if
      for some reason all of your concurrent rsyncs are running with the
      same ionice level and class, even thou they are ioniced,
      effectively there is no change.
      <br>
      So at that point we wrote a simple perl daemon that monitored
      rsyncs and changed ionice levels based on the amount of time each
      rsync spent in each level.
      <br>
      We pushed all new rsyncs onto the lowest level and dynamically
      moved them to the top. It simply does not work as well as I
      imagined.
      <br>
      <br>
      The best solution was to use the bklio control-group, BUT, with it
      the backups were still slower then with the slow-down option.
      <br>
      <br>
      Marian
      <br>
      <br>
      <blockquote type="cite">
        <br>
        <blockquote type="cite">Also, check out:
          <br>
          <br>
          2 more pipe utilities
          <br>
          <br>
          Viewer & throttle
          <br>
          <a class="moz-txt-link-freetext" href="http://www.ivarch.com/programs/pv.shtml">http://www.ivarch.com/programs/pv.shtml</a>
          <br>
          <br>
          Throttle - limits bandwidth of a pipe - for use with network
          transfers
          <br>
          <a class="moz-txt-link-freetext" href="http://linux.die.net/man/1/throttle">http://linux.die.net/man/1/throttle</a>
          <br>
        </blockquote>
        <br>
        The pv utility is way to little known and served me well in many
        <br>
        situations, and throttle seems to do quite the same. Both
        however seem
        <br>
        to do quite the same thing rsync's --bwlimit option does, while
        the
        <br>
        latter is more sophisticated.
        <br>
        <br>
        It the issue is the one I have in mind (which is one I
        constantly
        <br>
        suffer from), the actual problem is the dirty buffer writeback
        <br>
        strategy, deep in the Linux kernel.
        <br>
        <br>
             Christoph
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <hr>
      <pre> Frank Terhaar-Yonkers         W4FTY
 Cisco Systems, Inc.
 7025 Kit Creek Road  PO Box 14987
 Research Triangle Park,  North Carolina  27709
 <a class="moz-txt-link-abbreviated" href="mailto:fty@cisco.com">fty@cisco.com</a>   voice(919)392-2101
</pre>
      <br>
      <table>
        <tbody>
          <tr>
            <td style="background-color:#888888; font-family: Calibri,
              Sans-Serif; font-size:11pt; width:95px; height:18px;
              text-align:center;">
              <a
href="https://sjc-jabberc-ext.cisco.com/call/83922101@cisco.com?name=RTP%20Phone"
                target="_blank" style="text-decoration: none;
                color:white;">
                <b>JabberCall me</b>
              </a>
            </td>
            <td style="color:gray; font-size: 9pt; font-family: Calibri,
              Sans-Serif; font-style:italic; height:18px; width: 375px;">browser-based
              video chat</td>
          </tr>
        </tbody>
      </table>
    </div>
  </body>
</html>