-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Very poor performance with SDIO, sporadic SDIO errors #549
Comments
clockspeed=60 Exceeds the max capacity of slave SDIO for esp32-c6. Worth to check what real frequency Linux released although. sudo cat /sys/kernel/debug/mmcX/ios |
Considering -84 errors, Did you check the external pull-up register requirements from porting guide? Also, please note, the SDIO can only work over the PCB, not jumper cables. Additionally, you have captured the throughput one side, what about reverse direction? |
I hear you, but I have the same behavior with 1, 5, 10, 20, 30, 40, 50, and 60. At 60, it does this: clock: 60000000 Hz I agree that it is out of spec, and perhaps that was the wrong example to paste in here; it just happened to be the last test that I did. |
Its better not to exceed 50. it would be undefined behaviour. You can try changing. but in any case you both side traffic test makes sense. -84 is worrysome. Can you please send me recent picture for c6 integration? |
Would these be show in the logs on the host side? If so they looked nearly identical to the messages printed on the esp32c6 side.
I will confirm
The esp32c6 module is on the PCB, and the traces are ~30mm and length balanced. |
Yes, we have pull-ups |
one direction, suppose esp to host. other direction would be host to esp. Both need to test in individual test case. check https://github.com/espressif/esp-hosted/blob/master/esp_hosted_ng/docs/Raw_TP_Testing.md. two different test cases / runs with reloads of esp. |
I understand. Here is esp -> host @50MHz:
|
Checklist
How often does this bug occurs?
always
Expected behavior
I expected reasonable throughput
Actual behavior (suspected bug)
Throughput is about 2 megabits per second, and it stops working entirely after less than 10 megabytes have been transferred.
Error logs or terminal output
Steps to reproduce the behavior
Load module, configure wlan / acquire IP address, set route, run iperf
Project release version
76bb60975ce4fcbae1434771ee4de6ef09bc2f6b
System architecture
ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)
Operating system
Linux
Operating system version
6.6.23
Shell
sh
Additional context
Here are the results of the raw throughput test, and they look fantastic.
I (3113) stats: 0-1 sec 0.00 kbits/sec
I (4113) stats: 1-2 sec 490.47 kbits/sec
I (5113) stats: 2-3 sec 72703.44 kbits/sec
I (6113) stats: 3-4 sec 74231.88 kbits/sec
I (7113) stats: 4-5 sec 73889.69 kbits/sec
I (8113) stats: 5-6 sec 72897.34 kbits/sec
I (9113) stats: 6-7 sec 74402.97 kbits/sec
I (10113) stats: 7-8 sec 74311.72 kbits/sec
I (11113) stats: 8-9 sec 72395.47 kbits/sec
I (12113) stats: 9-10 sec 74311.72 kbits/sec
I (13113) stats: 10-11 sec 74391.56 kbits/sec
I (14113) stats: 11-12 sec 73193.91 kbits/sec
I (15113) stats: 12-13 sec 74345.94 kbits/sec
I (16113) stats: 13-14 sec 74414.38 kbits/sec
I (17113) stats: 14-15 sec 74163.44 kbits/sec
I (18113) stats: 15-16 sec 73399.22 kbits/sec
I (19113) stats: 16-17 sec 74357.34 kbits/sec
I (20113) stats: 17-18 sec 73787.03 kbits/sec
I (21113) stats: 18-19 sec 73365.00 kbits/sec
I (22113) stats: 19-20 sec 74345.94 kbits/sec
I (23113) stats: 20-21 sec 73923.91 kbits/sec
I (24113) stats: 21-22 sec 73536.09 kbits/sec
I (25113) stats: 22-23 sec 74231.88 kbits/sec
I (26113) stats: 23-24 sec 74072.19 kbits/sec
I (27113) stats: 24-25 sec 74368.75 kbits/sec
I (28113) stats: 25-26 sec 73604.53 kbits/sec
I (29113) stats: 26-27 sec 74254.69 kbits/sec
I (30113) stats: 27-28 sec 74460.00 kbits/sec
I (31113) stats: 28-29 sec 73513.28 kbits/sec
I (32113) stats: 29-30 sec 74209.06 kbits/sec
I (33113) stats: 30-31 sec 74551.25 kbits/sec
I (34113) stats: 31-32 sec 73741.41 kbits/sec
I (35113) stats: 32-33 sec 74152.03 kbits/sec
I (36113) stats: 33-34 sec 74505.62 kbits/sec
I (37113) stats: 34-35 sec 74562.66 kbits/sec
I (38113) stats: 35-36 sec 73536.09 kbits/sec
I (39113) stats: 36-37 sec 74585.47 kbits/sec
I (40113) stats: 37-38 sec 74631.09 kbits/sec
I (41113) stats: 38-39 sec 73433.44 kbits/sec
I (42113) stats: 39-40 sec 74448.59 kbits/sec
I (43113) stats: 40-41 sec 74585.47 kbits/sec
I (44113) stats: 41-42 sec 73490.47 kbits/sec
I (45113) stats: 42-43 sec 74551.25 kbits/sec
I (46113) stats: 43-44 sec 74562.66 kbits/sec
I (47113) stats: 44-45 sec 74243.28 kbits/sec
I (48113) stats: 45-46 sec 73558.91 kbits/sec
I (49113) stats: 46-47 sec 74471.41 kbits/sec
I (50113) stats: 47-48 sec 74163.44 kbits/sec
I had previously reported problems with instability in issue #482, which was related to our linear regulator being insufficient. The output current of the LDO was great, but the transient response was not. It has been replaced with a more capable part -- the esp32c6 is no longer suffering from brownout conditions, but the performance isn't great. This particular SoC has three SDIO interfaces and it can really move some data, so I'm quite trusting in its SDIO abilities.
I have tried many clock speeds, but lower ones don't seem any more stable than high ones.
The text was updated successfully, but these errors were encountered: