<div dir="ltr">Can you give a try to the lowbandwidth branch with the --predict=experimental command-line option? You might find that to be more to your liking.<div><br></div><div>We could flush out on certain characters -- that would be reasonable (but not currently implemented).</div><div><br></div><div>Cheers,</div><div>Keith</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 4:49 PM, Robert Redelmeier <span dir="ltr"><<a href="mailto:redelm@sbcglobal.net" target="_blank">redelm@sbcglobal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 0022-0700 Tue 21 Apr, Keith Winstein wrote in part:<br>
<span>> Hello Robert, Thanks for your email!<br>
<br>
</span>And thank you in turn for your prompt and detailed reply.<br>
<span><br>
> We do this to a degree,<br>
> but with the goal of _reducing_ latency -- please see Figure<br>
> 3 of the Mosh paper ( <a href="https://mosh.mit.edu/mosh-paper.pdf" target="_blank">https://mosh.mit.edu/mosh-paper.pdf</a>).<br>
<br>
</span>Fascinating! This 8ms is far too fast for human input, could<br>
it be something like ACK & echo packet combining, or combining<br>
from terminal local [cut'n']paste?<br>
<span><br>
> With the constants tuned differently, we end up reducing the<br>
> packets sent as you suggest. This is in the "lowbandwidth"<br>
> branch in the Git repository. > > Cheers, > Keith<br>
<br>
</span>I had a peek, thanks, but could not see how this would work<br>
differently from termios.c_cc(VTIME)=5 beyond ^C handling. I tried<br>
this dumb delay, and the added latency on top of a slow connection<br>
was very irksome. But I found I could reduce the irritation greatly<br>
by forcing the buffer out early when a command char was received.<br>
Could the special handling for ^C be expanded to all ^char plus<br>
duplicated chars (many pgms use hjkl for cursor movement)?<br>
<br>
Latency during straight typing is far less annoying unless chars<br>
are lost. Of course this system generates lots of false flushes.<br>
But who cares? Even `bookkeepers` sent as 4 packets is much better<br>
than 11, especially considering the "ACK-echo-ACK" multiplication.<br>
<div><div><br>
<br>
> On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier <<a href="mailto:redelm@sbcglobal.net" target="_blank">redelm@sbcglobal.net</a>><br>
> wrote:<br>
><br>
> > First, thanks y'all for your work on mosh!<br>
> > Second, a suggestion for your consideration (_NOT_ a vile "feature<br>
> > request"):<br>
> ><br>
> > Have you considered allowing send buffers to fill a bit before<br>
> > sending? Not sending ASAP, but often sending more than one char<br>
> > per packet? Of course this increases latency, but reduces packet<br>
> > count _tremendously_ and data usage likewise since the payload is<br>
> > tiny compared to overhead (incl ACK)..<br>
> ><br>
> > Not sure how this would interact with SSP, but I hacked ssh to do<br>
> > this 10+ years ago. To minimize the latency when it would most<br>
> > annoy, the buffer was released if a command was received or when<br>
> > typing stopped for 300-600ms. Commands were considered to be any<br>
> > control-char or any duplicated char (likely to be cursor movement).<br>
> ><br>
> > Of course, latency is sometimes noticeable but that is the price<br>
> > of reduced transmission data. Most of the time, I'm typing blind<br>
> > anyways -- I'm not going to focus on the screen unless needed.<br>
> > Sometimes the reductions were as large as 70%, more often 50%.<br>
> ><br>
> > -- Robert in Houston<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > mosh-devel mailing list<br>
> > <a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a><br>
> > <a href="http://mailman.mit.edu/mailman/listinfo/mosh-devel" target="_blank">http://mailman.mit.edu/mailman/listinfo/mosh-devel</a><br>
> ><br>
</div></div></blockquote></div><br></div></div>