ESP32-S3 - Bad Share

[matteocrippa]

Describe the bug
I was trying to investigate how to make work at decent speed an ESP32-S3, I started looking into the main issue: we cannot use esp32-arduino 2.0.1 because S3 is not supporter.
Later I found this issue that helped me a bit to understand the undergoing issue.

So I tried to adjust the code around CONFIG_MBEDTLS_HARDWARE_SHA disabling that and I started seeing that performance are comparable to ESP32 with v2.0.1.

Good? Nope, seems that many result got rejected as bad share. Similar to #1580

To Reproduce

1. Edit ESP32 code adding #define CONFIG_MBEDTLS_HARDWARE_SHA 0
2. Upload on S3

Expected behavior
Improved performance from 14 kH/s to ±44 kH/s with result being accepted.

System (please complete the following information):

• ESP32-S3
• DucoMiner 3.5

[revoxhere]

This requires some changes on the backend, I have some ESP32-S2/S3s and maybe I'll check it myself, for now- can you check if this could help with the regular ESP32s that have low hashrate on versions newer than 2.0.1?

[matteocrippa]

I gave a quick try on a old ESP32, but the performance was around 4kH/s with the patch, so not working at all.
Instead for S3 using esp32-arudino 2.0.6 or the latest I was able to reach back around 44kH/s.

[revoxhere]

That's what I was concerned about. It complicates the code unification, but on the other hand it's probably not hard to add a switch to check if running on an old ESP32 or the new S variants. Either way, there must be something else that can be changed for old ESPs as their performance suffers on new versions. Maybe I'll try digging through some docs if I find the time to do so

[matteocrippa]

Probably the best workaround is what you mentioned.
I will try to make a test and see if flagging that with #ifdef CONFIG_IDF_TARGET_ESP32S3 works as expected

[matteocrippa]

FYI I tried investigate ESP32 (Wroom, S3) performance too, let's address first #1688 and then I will port and try performance test there too

[reinos]

I gave a quick try on a old ESP32, but the performance was around 4kH/s with the patch, so not working at all. Instead for S3 using esp32-arudino 2.0.6 or the latest I was able to reach back around 44kH/s.

I did also a small test, based on platform.io and it seems to work, sort of.

This requires some changes on the backend

I think it applies here as well. As I can see it changed the difficulty dynamically to a much higher value, resulting in a timeout where the watchdog intercept

My Log

Core 0 is connecting to the Duino-Coin server...
Core 0 has connected to the server
Core 0 received server version: v3.0
Core 0 asking for a new job for user: ----------------

Core 0 received a correct job with size of 87 bytes
[DEBUG] JOB data: datapreviousHash(b8d5eae3b49496af91df9e9a97528ba5d8b9bb08) expectedHash(f0d1f8740af34ddbd90c021075362ee3be00f22c) difficulty(130000)

Core 1 is connecting to the Duino-Coin server...
Core 1 has connected to the server
Core 1 received server version: v3.0
Core 1 asking for a new job for user: -------------

Core 1 received a correct job with size of 87 bytes
[DEBUG] JOB data: datapreviousHash(dbf0ac038cde4c1804354c177dfb9e8237af9caa) expectedHash(109e9a0e4641ae59e9e09ddbce5b096ce6fb4c9f) difficulty(130000)
Core 0 found a correct hash (1.14s)
DEBUG 31350,27567.30,Official ESP32 Miner 3.5,test-full-speed,DUCOIDF4EA9B519140,2682

Core 0 retrieved job feedback: BAD,Too low starting difficulty, hashrate: 27.57kH/s, share #1
Core 0 asking for a new job for user: -------------

Core 0 received a correct job with size of 88 bytes
[DEBUG] JOB data: datapreviousHash(4fbfefa11f50e2a492d05f8a91773ac58631c094) expectedHash(997a0cb813f0f7c069d6b4fdac6cfd6eac9ec6fe) difficulty(4707000)
Core 1 found a correct hash (2.73s)
DEBUG 70789,25883.11,Official ESP32 Miner 3.5,test-full-speed,DUCOIDF4EA9B519140,2682

Core 1 retrieved job feedback: BAD,Too low starting difficulty, hashrate: 25.88kH/s, share #1
Core 1 asking for a new job for user: -------------

Core 1 received a correct job with size of 88 bytes
[DEBUG] JOB data: datapreviousHash(9a93f443f181a9681340d9ccedf4e3a788eddabf) expectedHash(b815db4ce8db2ac40f4d75ce19e3f4bdf102254c) difficulty(4307500)
Core 0 found a correct hash (35.58s)
DEBUG 781736,21968.56,Official ESP32 Miner 3.5,test-full-speed,DUCOIDF4EA9B519140,2682

Core 0 retrieved job feedback: GOOD, hashrate: 21.97kH/s, share #2
Core 0 asking for a new job for user: -------------

Core 0 received a correct job with size of 87 bytes
[DEBUG] JOB data: datapreviousHash(a22e1bd37202bbe11e38603dac3a06bef0e00a9b) expectedHash(95f3f79576afbc5b8a3f371ea4fd81b457bb1fef) difficulty(632300)
Core 0 found a correct hash (16.60s)
DEBUG 361497,21771.08,Official ESP32 Miner 3.5,test-full-speed,DUCOIDF4EA9B519140,2682

Core 0 retrieved job feedback: GOOD, hashrate: 21.77kH/s, share #3
Core 0 asking for a new job for user: -------------

Core 0 received a correct job with size of 87 bytes
[DEBUG] JOB data: datapreviousHash(6a4027beaa688a112afcc2dfecfb97c9b5d3e012) expectedHash(1ee1e17cd9b761ee2facd7074af0eb0d9688459d) difficulty(845700)
Core 0 found a correct hash (26.10s)
DEBUG 572607,21942.71,Official ESP32 Miner 3.5,test-full-speed,DUCOIDF4EA9B519140,2682

Core 0 retrieved job feedback: GOOD, hashrate: 21.94kH/s, share #4
Core 0 asking for a new job for user: -------------

About while ( xSemaphoreTake(xMutex, portMAX_DELAY) != pdTRUE ); and xSemaphoreGive(xMutex);. I think those can be removed as those calls are for hardware crypto and not CPU crypto calls, but im not sure. Testing it without those 2 increase the hashrate to around 30~35 kH/s per core.

So the whole issue is that as part of the update in the ESPIDF lib, they seems to switched the crypto to hardware by default. If you check the ESP-IDF docs (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html#config-mbedtls-hardware-sha) they are saying basically that you should test where you get the best performance

SHA hardware acceleration is faster than software in some situations but slower in others. You should benchmark to find the best setting for you. - source (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kconfig.html#config-mbedtls-hardware-sha)

[matteocrippa]

I think we can close this, turned to be obsolete somehow.
In #1688 I refactored for ESP8266 and start working on a bigger refactor that covers ESP32 too in an unique code base.
Performances are improved there too, but we need a few tweaks server side.

[reinos]

Thanks for letting me know. 👍