[Ovmsdev] Poor wifi performance

[Stephen Casner]

Maybe reopen issue 2054 to list our specific example of what fails to
see what they say?

                                                        -- Steve

On Fri, 27 Jul 2018, Mark Webb-Johnson wrote:

> I looked at the log for this tools/idf_monitor.py:
>
> commit 797340f7f82c29c15c8f59a39856bacbd0a74d53
> Author: Roland Dobai <dobai.roland at gmail.com>
> Date:   Mon Jun 18 12:49:04 2018 +0200
>
>     idf_monitor: Fix console performance
>
>     https://github.com/espressif/esp-idf/commit/51e42d8e925a20011bb7105da8cc3194d6940a6f
>     introduced filtering options which handles the last (unterminated) line
>     with a delay. This introduced poor performance for console applications
>     when the user interacts with the ESP32 device in the same line because
>     there is an artificial delay for each key-press.
>
>     https://github.com/espressif/esp-idf/commit/bb152030a0057c5a9a048782f917c4fa9d7b770e
>     decreased the delay but there are still delays for each key-presses.
>
>     The current fix makes only one delay per line instead of each
>     key-presses. When an unterminated line is detected then no more
>     "delayed" print is used for the given line.
>
>     Fixes https://github.com/espressif/esp-idf/issues/2054
>
> commit bb152030a0057c5a9a048782f917c4fa9d7b770e
> Author: Roland Dobai <dobai.roland at gmail.com>
> Date:   Wed Jun 13 07:48:52 2018 +0200
>
>     Fix the console performance issue
>
>     The IDF monitor waits for one second before printing the last
>     unterminated line. This is necessary for the correct filtering.
>     However, this causes poor performance, for example, in the case of the
>     system/console example.
>
>     This fix reduces the waiting time which improves the response time of
>     the console example and doesn't seem to influence the monitor filter.
>
>     Closes https://github.com/espressif/esp-idf/issues/2054
>
> Then tried rolling back to the Jun 13th commit (bb152030a0057c5a9a048782f917c4fa9d7b770e), and that solved the problem for me.
>
> Issue is the Jun 18th commit (797340f7f82c29c15c8f59a39856bacbd0a74d53), which is:
>
> --- a/tools/idf_monitor.py
> +++ b/tools/idf_monitor.py
> @@ -393,8 +393,8 @@ class Monitor(object):
>          # default we don't touch it and just wait for the arrival of the rest
>          # of the line. But after some time when we didn't received it we need
>          # to make a decision.
> -        if self._last_line_part != b"":
> -            if self._force_line_print or (finalize_line and self._line_matcher.match(self._last_line_part)):
> +        if finalize_line and self._last_line_part != b"":
> +            if self._line_matcher.match(self._last_line_part):
>                  self._force_line_print = True;
>                  if self._output_enabled:
>                      self.console.write_bytes(self._last_line_part)
>
> (that is a reverse patch, so ‘-‘ is new, and ‘+’ is old).
>
> It is simple for us to reverse this in our branch, but we’re out of sync with upstream from then onwards.
>
> Regards, Mark.
>
> > On 10 Jul 2018, at 10:01 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> >
> > Maybe timing related? They’ve messed with things to try to avoid the ‘wait for end of line’ delay.
> >
> > Regards, Mark.
> >
> >> On 10 Jul 2018, at 9:30 AM, Stephen Casner <casner at acm.org> wrote:
> >>
> >> I don't see “Password:” overwriting “OVMS>” but I see "Secure mode"
> >> overwriting "Password:".  Since "Secure mode" is a printf, not a
> >> write, I would expect \n to be massaged into \r\n somewhere along the
> >> path.  It can't be expected that all output strings get \r\n instead
> >> of \n.  So I have to retract my assertion of having fixed the problem.
> >>
> >>                                                       -- Steve
> >>
> >> On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:
> >>
> >>>
> >>> Still not working for me. I get:
> >>>
> >>> “Password:” overwriting “OVMS>” when I type “enable”.
> >>> First line of output overwrites command prompt whenever I type a command.
> >>> Pressing ENTER at “OVMS#” prompt seemingly does nothing.
> >>>
> >>> Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.
> >>>
> >>> Regards, Mark.
> >>>
> >>>> On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner at acm.org> wrote:
> >>>>
> >>>> This problem of no newline is related to the somewhat tricky way I
> >>>> implemented alert output being written above the current command input
> >>>> line.  I truncate the newline from the last or only line of an alert
> >>>> message so that when it is followed by microrl putting out a new
> >>>> prompt, which is preceded by a newline, we don't get a blank line.
> >>>>
> >>>> I've just committed a fix.  The problem was that the terminal monitor
> >>>> discards a newline that does not follow carriage return, and microrl's
> >>>> terminal_newline() function was written to output the same string to
> >>>> go to the next line as it takes for input to indicate the end of a
> >>>> command.  We need the input end-of-line to be just a newline
> >>>> character, so that is all that terminal_newline() put out before the
> >>>> prompt.  My fix was to change terminal_newline() to output the
> >>>> explicit string "\r\n" rather than the macro ENDL.
> >>>>
> >>>>                                                      -- Steve
> >>>> _______________________________________________
> >>>> OvmsDev mailing list
> >>>> OvmsDev at lists.openvehicles.com
> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> >> _______________________________________________
> >> OvmsDev mailing list
> >> OvmsDev at lists.openvehicles.com
> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> >
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>