[Ovmsdev] Poor wifi performance
casner at acm.org
Sat Jul 28 02:47:14 HKT 2018
Maybe reopen issue 2054 to list our specific example of what fails to
see what they say?
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
> 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.
> 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:
> (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
More information about the OvmsDev