<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 24 Apr '08, at 4:16 AM, Francis Brosnan Blazquez wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Cochin; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Right. Updating the window size is not part of the solution IMHO.<br></span></blockquote></div><br><div>I'm finding that in high-latency low-bandwidth connections, increasing the window size to 16k helps performance (even with my 1k frame size patch).</div><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">With the patch included, a new regression test I'm working on to ensure<br>performance in all scenarios, shows poor performance [1] under no delay<br>environments (for example a local area network). However, without the<br>patch applied [2] better results are found.<br></span></blockquote><br></div><div>Hm, that's too bad. I can see that if there's near-zero latency, the performance could be affected by the extra size occupied by the larger number of frame headers, and perhaps by the CPU overhead of generating and reassembling the frames. Have you done any CPU profiling to see whether the latter is an issue?</div><div><br></div><div>Does your testing include simulations of slow connections? The typical environment for my app is going to be between two consumer DSL or cable links (P2P), where the data rate is likely to be 384kbps or under, and round-trip delay times may be 200ms or more.</div><div><br></div><div>I've been using dummynet with ipfw to simulate such an environment across two computers on a LAN, and it works great. Here's how I turn it on (as root): </div><div><br></div><div><div><font class="Apple-style-span" color="#000000"># ipfw add pipe 1 ip from any to any out</font></div><div><font class="Apple-style-span" color="#000000">#ipfw add pipe 2 ip from any to any in</font></div><div><font class="Apple-style-span" color="#000000"># ipfw pipe 1 config bw 256kbit/s queue 10 delay 100ms</font></div><div><font class="Apple-style-span" color="#000000"># ipfw pipe 2 config bw 768kbit/s queue 30 delay 100ms</font></div><br></div><div>To turn it off, enter "ipfw flush".</div><div><br></div><div><blockquote type="cite" class=""><span class="Apple-style-span" style="color: rgb(0, 0, 0); ">In general, the change required to fix the issue you have found (vortex<br>performance under delay environments) must be dynamic and react properly<br>under delay and no delay conditions. <br></span></blockquote><br></div><div>Adjusting this automatically and dynamically might be quite difficult; I have no idea how to do it. Perhaps other BEEP implementations have figured out how?</div><div><br></div><div>In the absence of that, perhaps there could be a "maximum frame size" parameter that the client could adjust? To preserve current default behavior, it would initially be set to 4k.</div><div><br></div><div>—Jens</div></body></html>