[mosh-devel] carpal tunnel, measuring latency, and how to disable prediction testing

[John Hood]

Yes, Mosh is by default a little slower on fast local links than ssh.

Mosh does wait a small amount of time before sending new packets, in
order to aggregate small changes and keep the rate of packets low. 
It'll wait 8 ms after you type a character before sending it to the
server, and 1 ms before sending an update from server to client.  It'll
also take a few milliseconds at both clients and server to compute new
frame updates.  All that plus your base latency of 25ms will add up to
40ms or a little more.  It also limits subsequent updates to one every
20ms, so large screen updates can potentially complete slightly more
slowly than on ssh.

The prediction code eliminates this round-trip latency by guessing on
screen updates, of course.  But prediction is only enabled on links with
RTT > 80ms by default, except in experimental mode where it's enabled
all the time.

I've done some work to eliminate that 8 ms latency on initial packets. 
It works but I don't think I have the code exactly right.  I hope to get
that straightened out and share it in a Github pull request soon.

I've also done a lot of work to reduce the cost of screen updates, which
always has a minor-but-significant impact on this issue, and can have a
major impact for larger windows or slower machines (and your Atom CPU is
relatively slow).  That should be coming soon.

Sometimes, Mosh also doesn't interact well with power-saving algorithms
on modern systems.  Mosh needs to do significant computation to render
every keystroke, but not for very long-- just a few milliseconds. 
Often, systems don't switch out of their slow/low-power CPU states
before Mosh is done calculating those updates.

regards,

  --jh

On 07/10/2015 14:47, Frederik Eaton wrote:
> Hi Keith,
>
> Sorry for being so slow to reply...
>
> --predict=experimental works great. 
>
> I did a latency experiment using the tool you linked and found that
> with this option, mosh latency is a little slower than just typing in
> a local shell (2.5ms vs 0.5ms) but faster than ssh on a fast
> connection (25ms). Without that option, in certain circumstances it is
> consistently slower than ssh (40ms): in emacs, the latency is 40ms for
> the first character and 2.5ms thereafter; in zsh, if RPS1 is set then
> the latency is *always* 40ms, otherwise, only for the first character
> (like emacs). With "experimental", always 2.5ms everywhere... I
> definitely prefer the experimental option.
>
> My CPU might be 800MHz or 1600MHz, in fact /proc/cpuinfo shows one of
> each right now.
>
> Thanks again,
>
> Frederick
>
>
> On Wed, Jun 24, 2015 at 12:19:33AM -0700, Keith Winstein wrote:
>> Frederick:
>>
>> Thanks for your kind words about Mosh. For instant predictions (that might
>> be wrong and get corrected by the server), please try the
>> --predict=experimental option to mosh.
>>
>> You can measure the latency with our term-save tool:
>> https://github.com/keithw/stm-data/
>>
>> Best regards,
>> Keith
>>
>> On Wed, Jun 24, 2015 at 12:13 AM, Frederik Eaton <frederik at ofb.net> wrote:
>>
>>> Dear Mosh Developers,
>>>
>>> Thank you for a great product. I have thought about the need for
>>> something like this for years, and was happy when I discovered 'mosh'
>>> (a bit late I know).
>>>
>>> Your mailing list is not indexed by Google, but I downloaded the
>>> archives and found there seems to be no mention of 'carpal tunnel
>>> syndrome' or 'tendonitis'. I wanted to say that the reason I think a
>>> product like mosh is so valuable, is that according to my own self
>>> observation, typing over high-latency connections causes tendonitis. I
>>> wonder that no one else has made this connection, perhaps it is my own
>>> imagination. (I guess the hypothetical mechanism would be that my
>>> brain sends a "work faster" signal whenever a nerve seems to be
>>> working slowly, according to the delayed visual feedback, causing some
>>> kind of damage to healthy nerves)
>>>
>>> In any case, whether for health or "minimum annoyance" reasons, I have
>>> an interest in eliminating latency as much as possible. I don't care
>>> if someone sees part of all of my password, or if control sequences
>>> briefly show up on my editor screen. What I want is for immediate
>>> visual confirmation when one of my fingers pressed a key. The man page
>>> says "The predictive model must prove itself anew on each row of the
>>> terminal and after each control character, so mosh avoids echoing
>>> passwords or non-echoing editor commands." Is there an easy way to
>>> turn this feature off in the source code? Is it a bad idea, for some
>>> reason I haven't anticipated?
>>>
>>> My other (related) question is how to measure the actual latency. I
>>> can imagine that someone may have patched xterm to log input and
>>> output characters with sufficiently fine-grained timestamps, so that
>>> the latency of ssh, mosh, screen, etc. could be calculated, as the
>>> user presses random keys. I saw a couple things on your github issue
>>> tracker which look like people are measuring these values. I'm curious
>>> how to measure them myself. My initial trial of mosh (on an Arch
>>> Linux, 800 MHz "Intel(R) Atom(TM) CPU N270" (32-bit)) seems to show a
>>> slightly higher latency than simply typing on a local editor, and I'm
>>> curious to know if this is real.
>>>
>>> Thank you again for your dedication and incredibly useful software
>>> contribution, and also for reading my questions.
>>>
>>> Please Cc on replies as I'm not subscribed. Thanks,
>>>
>>> Frederick Eaton
>>> _______________________________________________
>>> mosh-devel mailing list
>>> mosh-devel at mit.edu
>>> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>>>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel