John, does spread handle out of order packets or does it treat them as drops causing retrans?<br><br>for testing, i'm using iperf (http://dast.nlanr.net/Projects/Iperf/)<br><br>i'm running the debug build for spread, this shouldn't cause any issue, correct?<br><br>how does daemons communicate across segments? does it still use udp?<br><br>thanks<br><br><b><i>John Schultz <jschultz@spreadconcepts.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> I looked at r.c's code and I'm not quite sure I understand what it is <br>trying to do. Maybe Jonathan or Yair can comment on my analysis below.<br><br>> --> count is 1, i is 0, missed 1 total missed 1, corrupt 0<br>> --> count is 30, i is 10, missed 20 total missed 21, corrupt 0<br>> --> count is 52, i is 39, missed 13 total missed 34, corrupt 0<br>> --> count is 65, i is 61, missed 4 total missed 38, corrupt
0<br>> --> count is 78, i is 74, missed 4 total missed 42, corrupt 0<br>> --> count is 88, i is 87, missed 1 total missed 43, corrupt 0<br>> --> count is 4152, i is 4151, missed 1 total missed 44, corrupt 0<br><br>This part is pretty obvious and makes sense. Basically, when the receiver <br>gets a packet # that is AHEAD of where the receiver is, it counts the ones <br>it didn't get as "missed." It sums each "missed" into "total missed." <br>These numbers and their relationship make sense together.<br><br>> -------<br>> Report: total packets at least 4152, total missed 44, total corrupted 0<br>> Initiating count from 4152 to 4151<br>> -------<br><br>This kind of report occurs when the receiver gets a packet # that is <br>BEHIND where the receiver is. The thing I don't understand, and maybe it <br>is a (reporting) bug, is that in this case the code sets "total missed" <br>equal to the packet #.<br><br>The code could be trying to handle the
scenario where the last packet of a <br>flood (which triggers a final report) is lost and a different flood is <br>started. The code tries to reset and process the new flood seperately <br>while accounting for any messages missed in the new flood.<br><br>However, this heuristic doesn't work as intended if packets arrive <br>out-of-order within in a single flood, which seems to be what is <br>happenning in your runs. If all of this reporting occurred within a <br>single run, which I assume it did, then we need to simply sum the "missed" <br>to get the correct "total missed" and ignore the reporting of "total <br>missed." This will double count some losses though as when the code <br>resets it will double count some losses when it jumps ahead in the <br>sequence again.<br><br>When I do that manually for your output I get about 140 losses out of <br>10000 packets. So, your losses aren't nearly as bad as spsend + sprecv <br>are portraying it. So long as a run doesn't have
one of these reports:<br><br>> -------<br>> Report: total packets at least 4152, total missed 44, total corrupted 0<br>> Initiating count from 4152 to 4151<br>> -------<br><br>Then you can trust its reporting of "total missed." If it does have such <br>a report then you need to manually sum the missed to get an estimate of <br>the losses. These reports do indicate though that your network is <br>reordering packets. That isn't a "sin" but it is unusual behavior in a <br>LAN.<br><br>Spread should certainly be able to handle such situations and should never <br>become completely non-responsive, but your network is acting strangely for <br>a LAN. One question to answer would be why is your LAN network reordering <br>and losing packets at ~1% loss rate.<br><br>Cheers!<br><br>---<br>John Schultz<br>Spread Concepts<br>Phn: 443 838 2200<br></blockquote><br><p> 
<hr size=1>Never miss a thing. <a href="http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs"> Make Yahoo your homepage.</a>