[mosh-devel] Lazy buffers?

[Keith Winstein]

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
> > > > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20150428/32e3d2fc/attachment.html