[Ovmsdev] Poor wifi performance

Fri Jul 27 14:15:09 HKT 2018

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180727/0c0d3f07/attachment.htm>
