RM57L843: TCP/IP performance with various stacks

Hi QJ,

more work has been done at the customer

1. Micrium's TCP stack makes use of their uC OSii's Mem_Copy() function. They replaced the basic C implementation of Mem_Copy() with a generic ARM assembler version that it provides. New speed: 12 Mbps

2. Micrium's TCP stack also provides a generic ARM assembler checksum calculator. Putting this in place brought the speed up to 17 Mbps.

3. They switched on compiler optimization (-O3 for gcc) for the TCP stack and MCU-side IPerf libraries.  New speed was 32 Mbps

4. They gave attention to alignment, giving 8-byte alignment to all memory buffers involved. New speed was 40 Mbps

5. A regression -- to see what would happen if using the SDRAM to allocate a very large number of TCP buffers instead of using local RAM, they placed the TCP Tx and Rx buffers in the SDRAM instead of the internal SRAM. Speed regressed to 17 Mbps. Undid that...

6. Disabled checksum checks for the IP and TCP layers. Speed increased to 45 Mbps. They probably don't want to keep checksum checking disabled, but this might point to a need to use the hardware CRC calculator.

How does this compare to your test? It looks like your test was testing on the ethernet level, but not on the IP level, is this correct?

Do you see other room for improvement?

Thanks,

--Gunter

Hi Gunter,

I only did ethernet level test. I will ask one of our ethernet experts to provide comments.

Hi Gunter,

What is the MPU settings for SRAM? Is the cache enabled?

Hi QJ,

Gunter has sent me the URL to this discussion so I can comment directly.  I took at look at my MPU setup, and indeed, cache was enabled for the SRAM...but not for flash! I enabled cache for the flash, and immediately my iperf performance jumped to 80 Mbps!

Here was the old MPU setup:

 static const MpuEntryTable_t mpuTable = {
     { 0x00000000,  MPU_4_GB, (0xFF << MPU_SUBREGION_SHIFT), MPU_PRIV_NA_USER_NA_NOEXEC, MPU_NORMAL_OINC_NONSHARED }, /* Background region */
     { 0x00000000,  MPU_4_MB, 0x00, MPU_PRIV_RO_USER_RO_EXEC, MPU_NORMAL_OINC_NONSHARED },   /* Flash */
     { 0x08000000,  MPU_64_KB,0, MPU_PRIV_RW_USER_RW_EXEC, MPU_NORMAL_OINC_NONSHARED },    /* DMA region of internal RAM */
     { 0x08000000,  MPU_512_KB, MPU_SUBREGION_DISABLE(0), MPU_PRIV_RW_USER_RW_EXEC, MPU_NORMAL_OIWBWA_NONSHARED },   /* remaining internal RAM */
     { 0x08400000,  MPU_512_KB, 0x00, MPU_PRIV_RW_USER_RW_EXEC, MPU_NORMAL_OINC_NONSHARED },
     { 0x30000000,  MPU_64_MB, 0x00, MPU_PRIV_RW_USER_RW_NOEXEC, MPU_NORMAL_OINC_NONSHARED }, /*  R5F cache 0 */
     { 0x34000000,  MPU_64_MB, 0x00, MPU_PRIV_NA_USER_NA_NOEXEC, MPU_NORMAL_OINC_NONSHARED }, /*  R5F cache 1 */
     { 0x60000000,  MPU_256_MB, MPU_SUBREGION_DISABLE(6)|MPU_SUBREGION_DISABLE(7), MPU_PRIV_RW_USER_RW_EXEC, MPU_STRONGLYORDERED_SHAREABLE },
     { 0x80000000,  MPU_128_MB, 0x00, MPU_PRIV_RW_USER_RW_EXEC, MPU_STRONGLYORDERED_SHAREABLE },
     { 0xF0000000,  MPU_8_MB, 0x00, MPU_PRIV_RW_USER_RO_NOEXEC, MPU_NORMAL_OINC_NONSHARED },
     { 0xFB000000,  MPU_16_MB, 0x00, MPU_PRIV_RW_USER_RW_NOEXEC, MPU_DEVICE_NONSHAREABLE },  /* CRC 2  (SPNU562 Fig. 2-3) */
     { 0xFC000000,  MPU_16_MB, 0x00, MPU_PRIV_RW_USER_RW_NOEXEC, MPU_DEVICE_NONSHAREABLE },  /* Peripherals frame 2 (SPNU562 Fig. 2-3) */
     { 0xFE000000,  MPU_16_MB, 0x00, MPU_PRIV_RW_USER_RW_NOEXEC, MPU_DEVICE_NONSHAREABLE },  /* CRC 1  (SPNU562 Fig. 2-3) */
     { 0xFF000000,  MPU_16_MB, 0x00, MPU_PRIV_RW_USER_RW_NOEXEC, MPU_DEVICE_NONSHAREABLE },   /* System peripherals, Frame 1,3 (SPNU562 Fig. 2-3) */
     { 0x08000000,  0,0,0,0 },   /*  Unused */
     { 0x08000000,  0,0,0,0 }    /*  Unused */
 };

I changed MPU_NORMAL_OINC_NONSHARED for the flash to MPU_NORMAL_OINC_NONSHARED to match the SRAM and that increased the speed dramatically.

I think we disabled it due to problems it was causing during debugging or similar. I will ask the team and try and learn the history of this MPU setup.

Best,

 - Alex