<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div>Initial feedback from me is that this looks good (both for this one and for the subsequent CAN one). Great work!<div class=""><br class=""></div><div class="">My remote access via modem seems more ’snappy’ now. I get solid green LIVE on the App quicker, and response to messages is better. Perhaps there was some TCP/IP packet retries I had not been aware of before, or just the async is less delayed. On the async simcom port, I have never seen fifo overflows.</div><div class=""><br class=""></div><div class="">For the past week or two, CAN2 on my car has been locking up on a daily basis, and required a ‘can can2 stop’, ‘can can2 start active 500000’ to recover. I’ve been running the new firmware all day, and it seems stable.<br class=""><div><br class=""></div><div>I will try to stress it over the weekend, on my bench, to see how it copes. The can logging to savvycan is fairly high stress (with all 3 can buses active, a lot of wifi, and a bunch of translation code running on the cpus).</div><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 1 Nov 2019, at 5:19 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  

    <meta http-equiv="content-type" content="text/html; charset=UTF-8" class="">
  
  <div class="">
    Everyone,<br class="">
    <br class="">
    I've pushed another optimization for the SIMCOM component that
    reduces the UART hardware<br class="">
    FIFO overflows
(<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274</a>)<br class="">
    to nearly zero by changing core associations.<br class="">
    <br class="">
    TL;DR:<br class="">
    <ul class="">
      <li class="">you also should apply the sdkconfig changes from the commit</li>
      <li class="">we need to optimize interrupt latency</li>
    </ul>
    <br class="">
    Analyzing our current core usage I found we've been running nearly
    all interrupt handlers on<br class="">
    core #1. That's because interrupts are bound to the core that
    allocates them, and after system<br class="">
    init, the housekeeper created all peripheral components on core #1.<br class="">
    <br class="">
    This has been our interrupt allocation up to now:<br class="">
    <br class="">
    <tt class="">Task           Run#  Lvl  ISR#  Usage                    Source</tt><tt class=""><br class="">
    </tt><tt class="">----------------------------------------------------------------------------------------</tt><tt class=""><br class="">
    </tt><tt class="">-              0     1    0     RTC Core                
      ETS_RTC_CORE_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">esp_timer      0     1    0     RTOS esp_timer          
      ETS_TIMER2_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">ipc0           0     1    0     RTOS Scheduler Core0    
      ETS_FROM_CPU_INTR0_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">ipc1           1     1    1     RTOS Scheduler Core1    
      ETS_FROM_CPU_INTR1_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">main           0     1    0     RTOS Watchdog           
      ETS_TG0_WDT_LEVEL_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     Peripherals (GPIO ISR)  
      ETS_GPIO_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     MAX7317 (spi_nodma)     
      ETS_SPI3_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     ESP32 CAN               
      ETS_CAN_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     SIMCOM UART             
      ETS_UART1_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     USB console (UART)      
      ETS_UART0_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">OVMS Events    1     1    1     SD card                 
      ETS_SDIO_HOST_INTR_SOURCE</tt><tt class=""><br class="">
    </tt><tt class="">----------------------------------------------------------------------------------------</tt><br class="">
    <br class="">
    I had some advances on the FIFO overflows by allocating a level 3
    interrupt for the SIMCOM UART,<br class="">
    but not much. I then tried moving the SIMCOM interrupt handler to
    core #0, and that immediately<br class="">
    reduced the overflows drastically -- most of the time.<br class="">
    <br class="">
    I read through the Espressif forums and issues on interrupt latency
    optimization and found a<br class="">
    precious hint here:
    <a class="moz-txt-link-freetext" href="https://www.esp32.com/viewtopic.php?t=11462#p46437">https://www.esp32.com/viewtopic.php?t=11462#p46437</a><br class="">
    <br class="">
    <i class="">"Finally, by default the LWIP task is allowed to run on either
      core, and will sometimes take a</i><i class=""><br class="">
    </i><i class="">spinlock which requires disabling interrupts. Try pinning
      this task to CPU 0, only"</i><br class="">
    <br class="">
    I did so, and the FIFO overflows disappeared completely on my bench.
    In my car there still<br class="">
    are some, but very few. I also tested pinning LWIP to core #1, that
    also worked and may be<br class="">
    an alternative.<br class="">
    <br class="">
    I then searched for more config candidates affecting interrupt
    performance and also disabled<br class="">
    the interrupt backtrace feature. That saves just 4 instructions on
    interrupt entry, so has<br class="">
    little effect and can be re-enabled in case we need it.<br class="">
    <br class="">
    I've reduced the UART IRQ level to 2 again as a support for my
    second finding regarding<br class="">
    the CAN controller, will describe that in the next post.<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>