Performance bottleneck about the hardware capabilities of 4B

[twrpi]

I am testing how to get the highest performance of Raspberry pi 4 (4B). After several weeks of trials and research, I want to explore the following performance bottleneck about the hardware capabilities:

1. The new SD controller (for the MicroSD plug) can support DDR50 rate (read bandwidth measured 41.7 MB/s) by 1.8 V signal voltage now. After some modifying the kernel driver and controlling the special register, with a good MicroSD card, the bandwidth will close to SDR104 (stable 84.1 MB/s read), but once I switched to the SDR104 mode, it can only reach about 57 MB/s (stable) or the filesystem will be (re)mounted as read-only mode. I am curious whether it can support the speed of SDR104 in practice? If not, it is mainly a question of hardware capabilities, a problem with the signal, or the software or firmware issue? Will SDR104 officially supported in the future?

2. I am very grateful for the improvement of RPi 4 and the working hard of RPF eng as we can finally use the updated 3200 MHz LPDDR4 memory! It is quite enough. But after long-term measurement, I found that in the best case, only about 4117 MiB/s read bandwidth can be achieved. According to calculations, the theoretical upper limit is about 10.8 GiB/s, so the actually achievable bandwidth is about 38% of the theoretical value. Is this due to the lack of outstanding memory access, the hardware capabilities of DMC, or the problem that 2 memory channels cannot operate in parallel? What cause this? And, is there a way to improve it?

3. The capability of power output of the USB Type-A ports. After measurement, the maximum current is only about 1.175A (hard to get 1.2A as my test). If I use a better Type-C charger (e.g. 5A which is the maximum current of the connector), is there a way to increase this limit?

Has anyone studied these issues about performance, any ideas or comments are welcome!

Thanks!

[trejan]

3. The capability of power output of the USB Type-A ports. After measurement, the maximum current is only about 1.175A (hard to get 1.2A as my test). If I use a better Type-C charger (e.g. 5A which is the maximum current of the connector), is there a way to increase this limit?

No. There is a AP2552 current-limited switch feeding the USB ports. You can measure the resistor but I expect it is set for 1.2A like the older RPi boards. If you want more current then you'll need to get a powered USB hub.

The 5A output on a USB-C power supply is when it is operating at 20V. The RPi 4 doesn't do USB PD to negotiate the higher power profiles and can't handle 20V anyway. A USB-C PSU maxes out at 3A when operating at 5V.

[jdb]

1: The controller supports DDR50. What "special register" are you using to control a) the source clock frequency and b) SDR104 mode?

2: The on-chip interconnect is optimised for high-resolution video decode, playback and 4K resolution displays. All of these hardware blocks perform long read-write data bursts that align well with SDRAM rows and so the interconnect can be maximally utilised. The ARM complex will issue cache line flushes (writes) and fills (reads) on a line-by-line basis and each line is less than the optimum SDRAM access size. The L2 cache can issue speculative line-fills and may combine them into bigger bursts, but ultimately without a carefully crafted sequence of deliberate cache flushes or preload hints the ARM will not be able to saturate the SDRAM controller bandwidth.

3. The available aggregate current from the downstream USB ports is fixed at a nominal 1.2A. Component tolerances will cause some variation in the actual trip value.

[twrpi]

some thoughts:

In the experience of existing USB chargers, it seems that a lot of chargers does not fully comply with USB power supply specifications. e.g., most traditional USB 2.0 chargers without PD do not limit the current to 500mA. If the PCB and connector can support, may consider to use a hardware switch to limit the current which is selected by the end-user in the future and the user is responsible for the sufficient current required by the core to prevent system shut-down. I originally expected that it would be by a software control, thanks to trejan for figure out that there is a hard-coded resistor by AP2552. (I guess it is 20k ohm but not yet tested)

By the way, I don't think it's a good idea to power by the USB hub, due to some hubs don't meet the specifications or generate reverse currents because of the voltage difference.

On the topic of MicroSD, I noticed that sd_overclock is no longer effective on Pi 4b because the SD controller is different from 3b+. There seems to be a sdhci-iproc control if it accepts SDR104. After forced change, /sys/kernel/debug/mmc0/ios will change the timing spec and clock normally, but the actual frequency must be adjusted the VPU controlled mmc2 (not 0...) frequancy register. to achieve > 80MB/s read and > 50MB/s write (not known why write is slower). So, the spec of hardware controller can only supports DDR50 but not SDR104 for unknown some technical reasons?

Finally, I wonder is there any information on how to adjust L2's access to the SDRAM controller so that it can achieve higher bandwidth? I have tried various ways, including through different core access, but this may only affect the shared L2 instead of SDRAM access. If parallel access to SDRAM is possible, theoretically 32-bit width and 16n prefetch should just fill a 64B cache line to achieve higher efficiency, but it is unknown whether there are many buffer to operate different channel/bank at the same time. Also, is there only the DMC and no Cache Coherent Interconnect?

Thanks for the detail responses

[rpdom]

some thoughts:

In the experience of existing USB chargers, it seems that a lot of chargers does not fully comply with USB power supply specifications. e.g., most traditional USB 2.0 chargers without PD do not limit the current to 500mA. If the PCB and connector can support, may consider to use a hardware switch to limit the current which is selected by the end-user in the future and the user is responsible for the sufficient current required by the core to prevent system shut-down. I originally expected that it would be by a software control, thanks to trejan for figure out that there is a hard-coded resistor by AP2552. (I guess it is 20k ohm but not yet tested)

There is no reason to limit current from the supplies. The Pi will only use what it needs as long as it is supplied with enough current. Voltage is the issue. The Pi requires 5V (give or take a little). Some USB-C chargers can supply a higher voltage, but they should default to 5V if not told otherwise.

[andrum99]

In the experience of existing USB chargers, it seems that a lot of chargers does not fully comply with USB power supply specifications. e.g., most traditional USB 2.0 chargers without PD do not limit the current to 500mA.

They're not supposed to. If there is no data on the USB data lines, and they are shorted together, then the spec allows drawing larger currents from the USB port. This is how USB chargers are able to deliver higher currents. (Excepting things like Qualcomm Fast Charge). I'm not sure what the limit is, but it is much more than 500mA. The 500mA limit only applies if the data lines are in use. Also many USB devices, such as external hard disks, use more than this. Yes, this is a breach of the USB spec. No, it is not going to change any time soon.

[twrpi]

some thoughts:

In the experience of existing USB chargers, it seems that a lot of chargers does not fully comply with USB power supply specifications. e.g., most traditional USB 2.0 chargers without PD do not limit the current to 500mA. If the PCB and connector can support, may consider to use a hardware switch to limit the current which is selected by the end-user in the future and the user is responsible for the sufficient current required by the core to prevent system shut-down. I originally expected that it would be by a software control, thanks to trejan for figure out that there is a hard-coded resistor by AP2552. (I guess it is 20k ohm but not yet tested)

There is no reason to limit current from the supplies. The Pi will only use what it needs as long as it is supplied with enough current. Voltage is the issue. The Pi requires 5V (give or take a little). Some USB-C chargers can supply a higher voltage, but they should default to 5V if not told otherwise.

I think it can keep the stability of the system, i.e. prevents the crash of more important part, SoCs, instead of USB external devices.

[W. H. Heydt]

By the way, I don't think it's a good idea to power by the USB hub, due to some hubs don't meet the specifications or generate reverse currents because of the voltage difference.

That has been an issue that has been discussed here for *years*. Some Pis, Model A, A+, Pi3A+, Pi0, Pi0W, can be "backpowered" by a hub (if sufficient current is supplied that way...in practice this usually limits such things to the A, A+, Pi0 and Pi0W). Most of us who recommend specific hubs will mention whether or not the hub attempts to backpower. E.g. The cheap, small, cubical Monoprice hub, if powered will try to do so. Therefore I only recommend that it be used as a passive hub. Others are better behaved.