<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 15/12/16 13:48, Jasmin J. wrote:<br>
    </div>
    <blockquote cite="mid:1c1fe147-bc24-1607-40df-4850edc40913@anw.at"
      type="cite">Hello Lars!
      <br>
      <br>
      &gt; Maybe this nice post from 2012,
      <br>
      &gt; helps to realize what congestion is?
      <br>
      &gt; Pasted here for your convenience, even though it is in the
      archives.
      <br>
      THX for answering, it explained it pretty good.
      <br>
      <br>
      &gt; But even with massive buffers (funnels),
      <br>
      &gt; the sustained mid term/long term average write rate
      <br>
      &gt; obviously cannot exceed the minimum bandwith within the whole
      system.
      <br>
      This depends how you implement Protocol A. It seems that it slows
      down the
      <br>
      write speed when the "funnel" is full. It seems the main goal is
      to keep
      <br>
      both in sync, even if this costs write speed.
      <br>
      <br>
      The original from 2012 poster asked this:
      <br>
      &gt;&gt; I was expecting that if I switched to protocol A, I would
      be able to let
      <br>
      &gt;&gt; the SSD drive write at it's full speed (e.g. 250MB/s)
      only at the price of
      <br>
      &gt;&gt; the secondary potentially falling a little bit behind
      <br>
      I guess he meant here the peer going out of sync.
      <br>
      I know (because of the explanation) it isn't implemented that way.
      But
      <br>
      wouldn't it be possible to implement Protocol A2 (or D), which
      simply writes
      <br>
      with full speed to the local disk regardless if the peer can
      follow, get out
      <br>
      of sync and let the already implemented sync mechanism resync the
      peer with
      <br>
      the configured sync parameter settings during the heavy write load
      and
      <br>
      also continue syncing until it is consistent again?
      <br>
      <br>
      There is already a bitmap of inconsistent blocks implemented.
      Instead of
      <br>
      trying to update the peer with each write the driver could simply
      set the bit
      <br>
      in the bitmap, if the buffer (funnel) gets full and change back to
      the already
      <br>
      implemented sync mode (which is currently used only after a peer
      connecting again).
      <br>
    </blockquote>
    I would advise that you refer to the documentation, what you are
    asking for already exists:<br>
    <a class="moz-txt-link-freetext" href="https://www.drbd.org/en/doc/users-guide-84/re-drbdconf">https://www.drbd.org/en/doc/users-guide-84/re-drbdconf</a><br>
    Specifically look for <span class="term"><code class="option">on-congestion</code></span><br>
    <br>
    Regards,<br>
    Adam<br>
    <br>
    <div class="moz-signature">-- <br>
      Adam Goryachev
      Website Managers
      <a class="moz-txt-link-abbreviated" href="http://www.websitemanagers.com.au">www.websitemanagers.com.au</a></div>
  </body>
</html>