[mosh-devel] Lazy buffers?

[Robert Redelmeier]

Prediction is possible  and might help position the cursor sometimes.
But as you say, many times the arrow keys are command-keys that change
the screen in wierd and wonderful ways.  There is nothing to do but
send it (and anything else in the buffer) immediately because nothing
else is coming into the buffer.  A mechanical time-out delay just is
uselessly annoying.


On 2325-0700 Mon 27 Apr, Keith Winstein wrote in part:
> Great!
> 
> If you wanted to try to add local prediction for up- and down-arrow,
> https://github.com/keithw/mosh/blob/master/src/frontend/terminaloverlay.cc#L824-L836
> would be the place to do it.
> 
> I don't think we have that high a probability of successfully predicting
> these locally very often, though, but maybe in a lowbandwidth mosh it's
> worth it just to move the cursor so the user can see that they've done
> something?
> 
> On Mon, Apr 27, 2015 at 8:44 PM, Robert Redelmeier <redelm at sbcglobal.net>
> wrote:
> 
> >   Success!  (Thanks for the tip about debian/control).
> >
> > -b lowbandwith has the delays I suggested.  --predict=[DEFAULT]
> > and sightly better --predict=experimental  give that neat underlining
> > that disappears and fixes itself when wrong (like vim k for scroll up).
> >
> > Horizontal cursor <- and -> work fine, without delays (or at least
> > working on the buffer).  But vertical scrolling has maddening delays
> > and slow visual feedback.  Hard to correctly position cursor.
> >
> > -- Robert
> >
> >
> > On 1657-0700 Tue 21 Apr, Keith Winstein wrote in part:
> > > 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.
> > >
> > > We could flush out on certain characters -- that would be reasonable (but
> > > not currently implemented).
> > >
> > > Cheers,
> > > Keith
> > >
> > > On Tue, Apr 21, 2015 at 4:49 PM, Robert Redelmeier <redelm at sbcglobal.net
> > >
> > > wrote:
> > >
> > > > On 0022-0700 Tue 21 Apr, Keith Winstein wrote in part:
> > > > > Hello Robert, Thanks for your email!
> > > >
> > > > And thank you in turn for your prompt and detailed reply.
> > > >
> > > > > We do this to a degree,
> > > > > but with the goal of _reducing_ latency -- please see Figure
> > > > > 3 of the Mosh paper ( https://mosh.mit.edu/mosh-paper.pdf).
> > > >
> > > > Fascinating!  This 8ms is far too fast for human input, could
> > > > it be something like ACK & echo packet combining, or combining
> > > > from terminal local [cut'n']paste?
> > > >
> > > > > With the constants tuned differently, we end up reducing the
> > > > > packets sent as you suggest. This is in the "lowbandwidth"
> > > > > branch in the Git repository.  > > Cheers, > Keith
> > > >
> > > > I had a peek, thanks, but could not see how this would work
> > > > differently from termios.c_cc(VTIME)=5 beyond ^C handling.  I tried
> > > > this dumb delay, and the added latency on top of a slow connection
> > > > was very irksome.  But I found I could reduce the irritation greatly
> > > > by forcing the buffer out early when a command char was received.
> > > > Could the special handling for ^C be expanded to all ^char plus
> > > > duplicated chars (many pgms use hjkl for cursor movement)?
> > > >
> > > > Latency during straight typing is far less annoying unless chars
> > > > are lost.  Of course this system generates lots of false flushes.
> > > > But who cares?  Even `bookkeepers` sent as 4 packets is much better
> > > > than 11, especially considering the "ACK-echo-ACK" multiplication.
> > > >
> > > >
> > > > > On Mon, Apr 20, 2015 at 6:00 PM, Robert Redelmeier <
> > redelm at sbcglobal.net
> > > > >
> > > > > wrote:
> > > > >
> > > > > >  First, thanks y'all for your work on mosh!
> > > > > > Second, a suggestion for your consideration (_NOT_ a vile "feature
> > > > > > request"):
> > > > > >
> > > > > > Have you considered allowing send buffers to fill a bit before
> > > > > > sending?  Not sending ASAP, but often sending more than one char
> > > > > > per packet?  Of course this increases latency, but reduces packet
> > > > > > count _tremendously_ and data usage likewise since the payload is
> > > > > > tiny compared to overhead (incl ACK)..
> > > > > >
> > > > > > Not sure how this would interact with SSP, but I hacked ssh to do
> > > > > > this 10+ years ago.  To minimize the latency when it would most
> > > > > > annoy, the buffer was released if a command was received or when
> > > > > > typing stopped for 300-600ms.  Commands were considered to be any
> > > > > > control-char or any duplicated char (likely to be cursor movement).
> > > > > >
> > > > > > Of course, latency is sometimes noticeable but that is the price
> > > > > > of reduced transmission data.  Most of the time, I'm typing blind
> > > > > > anyways -- I'm not going to focus on the screen unless needed.
> > > > > > Sometimes the reductions were as large as 70%, more often 50%.
> > > > > >
> > > > > > -- Robert in Houston
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > mosh-devel mailing list
> > > > > > mosh-devel at mit.edu
> > > > > > http://mailman.mit.edu/mailman/listinfo/mosh-devel
> > > > > >
> > > >
> >