<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 02/06/2011 23:12, Mike Oxford wrote:
    <blockquote
      cite="mid:BANLkTimVtd__hUa1kkJLf+JNPy3yvQo_-Q@mail.gmail.com"
      type="cite">I'm guessing you've already tried increasing SASL
      debugging, and using dbg:tracer()?
      <div>How about putting a debugger (gdb or the like) on your
        driver?</div>
      <div>Have you tried synthetic testing (eg, loop the same packet
        into your system, injected just after </div>
      <div>the UDP layer and then check the output on the other side?"</div>
      <div>You say that you're breaking the packets up for processing,
        and putting them back together, with </div>
      <div>sequencing staying the same... but you're losing packets?
         That seems only possible if your</div>
      <div>hardware isn't actually sending it (or there's a bug in your
        sequencing numbers/checks.)</div>
      <div><br>
      </div>
    </blockquote>
    I started out with a simulator (in Erlang) and when I was happy
    moved onto the hardware. I think I will move back to the simulator
    because I can then see both ends, and I can vary the data rate
    easily and should be able to reproduce the fault. Nothing makes
    sense at the moment because I'm pretty sure the sequence numbering
    is sound and because of it I can pretty much state I'm not losing
    packets either in reception or transmission and don't have queues
    building in Erlang but blocks are still going missing.<br>
    <blockquote
      cite="mid:BANLkTimVtd__hUa1kkJLf+JNPy3yvQo_-Q@mail.gmail.com"
      type="cite">
      <div>Have you put Ethereal/Wireshark/tcpdump etc on the wire
        during the tests?  Have you seen a pause</div>
      <div>in output?</div>
      <div><br>
      </div>
    </blockquote>
    I've used Wireshark but the disruption in output is not seen because
    its missing data but the sequence is correct. It's not a silent
    pause.<br>
    <blockquote
      cite="mid:BANLkTimVtd__hUa1kkJLf+JNPy3yvQo_-Q@mail.gmail.com"
      type="cite">
      <div>Hard to tell from this far away.  =/</div>
    </blockquote>
    I know, but sometime just talking through the problem helps to
    clarify. <br>
    <blockquote
      cite="mid:BANLkTimVtd__hUa1kkJLf+JNPy3yvQo_-Q@mail.gmail.com"
      type="cite">
      <div><br>
        <div class="gmail_quote">On Thu, Jun 2, 2011 at 2:02 PM, Bob
          Cowdery <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:bob@bobcowdery.plus.com">bob@bobcowdery.plus.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
            0.8ex; border-left: 1px solid rgb(204, 204, 204);
            padding-left: 1ex;">
            <div text="#000000" bgcolor="#ffffff">
              <div class="im"> On 02/06/2011 20:26, Mike Oxford wrote:
                <blockquote type="cite">
                  <div>
                    <div>Can you pin down where you think you're losing
                      the data?  You state a hard number....where in the
                      chain are you measuring?</div>
                  </div>
                  <div><br>
                  </div>
                </blockquote>
              </div>
              I've been trying to do that for several days but it's
              really hard to track it all the way through in one go
              because the buffer size changes in different stages and
              its not even multiples, it only comes together in fixed
              size blocks at each end. When I check each stage
              individually I'm failing to find any problem. I see I've
              lost blocks overall but the stage I'm looking at has no
              breaks in the pattern. They all seem to process the data
              correctly - and most of the time the input and output keep
              pace. There is no code in the path that could just junk
              blocks.
              <div class="im"><br>
                <blockquote type="cite">
                  <div>Usually in audio-processing you're going to run
                    into issues in two main places; buffer starvation
                    and codec corruption.</div>
                  <div>Buffer starvation is pretty self-explanitory --
                    something in the chain cannot keep up, usually due
                    to CPU load, lock contention or other data flow
                    interruption.</div>
                  <div>Codec corruption happens when the codec tries to
                    use the new incoming packets against it's stored
                    run-state.  If </div>
                  <div>something happens (out of sequence, null packets,
                    etc) the codec will usually do one of two things:
                     do its best and give you corrupted audio or just
                    drop the packet on the floor as if it never got it.</div>
                  <div><br>
                  </div>
                </blockquote>
              </div>
              This is akin to audio processing but the signal processing
              is under my control so there are no unknowns in the chain.
              <div class="im"><br>
                <blockquote type="cite">
                  <div> </div>
                  <div>One more caveat with audio: output packet size is
                    not usually equal to input packet size.  The most
                    codecs do lossy-compression.  Just one more thing to
                    check.</div>
                  <div><br>
                  </div>
                </blockquote>
              </div>
              I'm using 48k input and output rate for the test. <br>
              <div>
                <div class="h5">
                  <blockquote type="cite">
                    <div>-mox </div>
                    <div><br>
                      <div class="gmail_quote"> On Thu, Jun 2, 2011 at
                        12:09 PM, Bob Cowdery <span dir="ltr"><<a
                            moz-do-not-send="true"
                            href="mailto:bob@bobcowdery.plus.com"
                            target="_blank">bob@bobcowdery.plus.com</a>></span>
                        wrote:<br>
                        <blockquote class="gmail_quote" style="margin:
                          0pt 0pt 0pt 0.8ex; border-left: 1px solid
                          rgb(204, 204, 204); padding-left: 1ex;"> Can
                          anyone give me some hints on how to debug this
                          problem. I know its a<br>
                          long-shot but maybe someone has experience of
                          a similar problem.<br>
                          <br>
                          I have a real-time system that reads from a
                          device using UDP and writes<br>
                          back to the same device using UDP. The data
                          processing chain comprises 6<br>
                          processes:<br>
                          <br>
                          Reader - Decoder - Input to linked-in-driver -
                          output from<br>
                          linked-in-driver - Encoder - Writer<br>
                          <br>
                          With the parameters I'm using I should be
                          writing the same number of<br>
                          blocks that I am reading. There are sequence
                          numbers on both input and<br>
                          output blocks. For a while this is what
                          happens, then I start to lose<br>
                          blocks. I believe in snatches rather than a
                          regular pattern. I can<br>
                          sometimes hear the disruption in the output
                          and if I stop at that point<br>
                          I've lost blocks, as many as 40 in one case.
                          However it can run on way<br>
                          longer than that with no lost blocks.<br>
                          <br>
                          I've checked every stage of the code with
                          debug statements but<br>
                          everything seems to pass through correctly.
                           I've also checked the<br>
                          message queue length at each stage and it
                          never builds up on any<br>
                          process. I have no catch-all message handlers.
                          The messages are all<br>
                          large binary.<br>
                          <br>
                          The symptoms look like it just can't keep up
                          but If a process was<br>
                          getting behind I would expect the message q to
                          build up. CPU is 5-7%.<br>
                          <br>
                          Any ideas would be very welcome.<br>
                          <br>
                          Bob<br>
                          <br>
                          <br>
_______________________________________________<br>
                          erlang-questions mailing list<br>
                          <a moz-do-not-send="true"
                            href="mailto:erlang-questions@erlang.org"
                            target="_blank">erlang-questions@erlang.org</a><br>
                          <a moz-do-not-send="true"
                            href="http://erlang.org/mailman/listinfo/erlang-questions"
                            target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
                        </blockquote>
                      </div>
                      <br>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>