[En-Nut-Discussion] TCP FFlush slow on Ethernut 3

[Harald Kipp]

Martin,

ml wrote:
> hi,
>
> i´m trying to find out why my tcp routines are so slow.

Just a few ideas (I know you are developing on ARM):

1. Heavy interrupts (sometimes caused by level instead of edge triggering)

You can use DEV_DEBUG and add a putchar() to all your interrupt
routines. For most systems this will have low impact on overall
performance unless one of your interrupts is running crazy.


2. Too many memory wait states, specifically with external 8/16-bit
devices on ARM

Check the remap table in the runtime initialization. Some heavy duty
routines can moved to fast memory, like internal RAM.


3. Not optimized code used during debugging

The difference between optimized and non-opimized code is amazing,
specifically when running many tight loops.


4. Extensive calculations in a non-cooperative thread

Until we have better capabilities, you can simply add something like

  printf("[%s]", runningThread->td_name);
  if (runningThread->td_next == NULL)
    putchar('\n');

immediately after

  NutEnterCritical();
  NutThreadSwitch();
  NutExitCritical();

in NutThreadResume() in os/thread.c. This simple method is not exact and
will produce a lot of output. Anyway, in most cases you will soon
recognize bad threads. Again, make sure to use DEV_DEBUG for stdout.


5. TCP buffering problems.

If you are transferring large amounts of data, it helps to divide data
transfer and data processing into two threads. Otherwise the TCP window
may be always closed, leading to additional overhead and timeout
processing. As an alternative you can increase the TCP receive buffer
(to be set by socket options). Also avoid reading/writing single bytes
via fputc/fgetc. fscanf() is slow also. Better collect some data in a
buffer and use fwrite(), fwrite() or similar. Increasing the MSS
(another socket option) may help too. All these methods consume more
RAM, of course.


Harald