[Ovmsdev] ESP32/3 benchmark (was: External Wifi antenna)

[Michael Balzer]

Craig,

persistent metrics do not affect the tests. Persistent metrics also only 
read from RTC on boot (init), and only write to RTC on value changes.

It may well be our test isn't suitable to get a real world estimation, 
as it normally probably won't leave a single cache page.

Maybe we need a better test, i.e. two or more tasks running concurrent 
random accesses over a large address range.

Regards,
Michael


Am 14.03.21 um 19:01 schrieb Craig Leres:
>
> On 3/14/21 12:15 AM, Michael Balzer wrote:
>> you triggered the watchdog by pasting all commands into the shell, 
>> you need to leave 1-2 seconds between the commands to feed the dog.
>
> I didn't realize that was possible!
>
> Do persistent metrics impact test mode 2? Looking at the ESP32-WROVER 
> dat sheet (version 2.4) I see:
>
>     ESP32-D0WDQ6 contains two low-power Xtensa 32-bit LX6
>     microprocessors. The internal memory includes:
>
>      - 448 KB of ROM for booting and core functions.
>
>      - 520 KB of on-chip SRAM for data and instructions.
>
>      - 8 KB of SRAM in RTC, which is called RTC FAST Memory and can
>        be used for data storage; it is accessed by the main CPU
>        during RTC Boot from the Deep-sleep mode.
>
>      - 8 KB of SRAM in RTC, which is called RTC SLOW Memory and can
>        be accessed by the co-processor during the Deep-sleep mode.
>
>      - 1 Kbit of eFuse: 256 bits are used for the system (MAC address
>        and chip configuration) and the remaining 768 bits are
>        reserved for customer applications, including flash-encryption
>        and chip-ID.
>
> And:
>
>     3.2 External Flash and SRAM
>
>     SP32-WROVER integrates a 4 MB of external SPI flash and an 8
>     MB PSRAM for more memory space.
>
> It's confusing to me that the external ram is interchangeably called 
> PSRAM (pseudo static RAM), SPI SRAM, and SPIRAM.
>
> Anyway, does test mode 2 only access SPIRAM or does it also pull from 
> RTC slow memory?
>
>> Your results could indicate the SPIRAM workaround doesn't really 
>> degrade performance for the kind of RAM accesses the test does.
>>
>> Or it indicates something's wrong in your build / configuration, i.e. 
>> the SPIRAM workaround is still in place.
>>
>> Ideas:
>>
>> a) Did you do a "make clean" after disabling the SPIRAM workaround?
>
> I've had the workaround disabled ever since I upgraded my modules to 
> V3 and I don't bother with "make clean", I usually use "rm -rf build" (!)
>
>> b) Verify your toolkit version (should be 
>> crosstool-ng-1.22.0-97-gc752ad5)
>
> ice 1243 % xtensa-esp32-elf-gcc --version
> xtensa-esp32-elf-gcc (crosstool-NG crosstool-ng-1.22.0-97-gc752ad5) 5.2.0
>
>> c) Verify the actual compiler & linker options given by doing "make -n"
>
> I did something like:
>
>     rm -rf build ; gmake -n | fgrep esp32can.o | fmt -1 > file
>
> with CONFIG_SPIRAM_CACHE_WORKAROUND enabled and disabled and it looks 
> like the flag is present/flag:
>
>     ice 1277 % diff /tmp/workaround.txt /tmp/noworkaround.txt
>     21d20
>     < -mfix-esp32-psram-cache-issue
>
> So my setup looks correct to me.
>
>         Craig

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210314/0c458fae/attachment.sig>