[ECOS] Speed up TFTP download time in RedBoot

[ECOS] Speed up TFTP download time in RedBoot

[Elad Yosef]

Hi,
I'm trying to speed up the TFTP download time in the Redboot.
I have tried to change the following params;

CYGNUM_REDBOOT_NETWORKING_MAX_PKTBUF - had no effect
CYGNUM_REDBOOT_GETC_BUFFER - I have increased it to 10K but still no improvement
CYGNUM_IO_ETH_DRIVERS_NUM_PKT - had no effect

My ETH RX ring has 12 buffer each has 770 bytes (9240 in total)

Am I missing something?

Thanks

Elad

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Andrew Lunn]

On Mon, Mar 19, 2012 at 06:05:36PM +0200, Elad Yosef wrote:
> Hi,
> I'm trying to speed up the TFTP download time in the Redboot.
> I have tried to change the following params;
> 
> CYGNUM_REDBOOT_NETWORKING_MAX_PKTBUF - had no effect
> CYGNUM_REDBOOT_GETC_BUFFER - I have increased it to 10K but still no improvement
> CYGNUM_IO_ETH_DRIVERS_NUM_PKT - had no effect
> 
> My ETH RX ring has 12 buffer each has 770 bytes (9240 in total)
> 
> Am I missing something?

TFTP uses a very simple UDP protocol without any windows. Each
received packet is ACKed before the next is sent. So the size of the
buffers makes no difference, so long as it can hold one frame. You are
only likely to get speedup if you are suffering from packet loss. The
retries are quite slow, so the effect of loosing a packet is quite
big. So make sure you have a reliable network.

You might also want to look at using http instead. I don't know how
good the TCP implementation is in redboot, it might support some
windowing so speeding up the transfer.

	  Andrew


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Stanislav Meduna]

On 19.03.2012 17:05, Elad Yosef wrote:

> I'm trying to speed up the TFTP download time in the Redboot.
> I have tried to change the following params;

TFTP is a ping-pong style protocol with small packet sizes,
so the only way to speed it up is to reduce the latencies
on both sender and receiver. What throughput are you getting?

Try lowering CYGDBG_REDBOOT_TICK_GRANULARITY

Regards
-- 
                                     Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Elad Yosef]

Hi,
I get 108 KBytes/sec after lowering the CYGDBG_REDBOOT_TICK_GRANULARITY to 50.
I'm downloading SREC image to my target.
I'm using MIPS32 4Kec.
Does any changes to - hal_delay_us(int us) will improve the time?



On Mon, Mar 19, 2012 at 7:17 PM, Stanislav Meduna <stano@meduna.org> wrote:
> On 19.03.2012 17:05, Elad Yosef wrote:
>
>> I'm trying to speed up the TFTP download time in the Redboot.
>> I have tried to change the following params;
>
> TFTP is a ping-pong style protocol with small packet sizes,
> so the only way to speed it up is to reduce the latencies
> on both sender and receiver. What throughput are you getting?
>
> Try lowering CYGDBG_REDBOOT_TICK_GRANULARITY
>
> Regards
> --
>                                     Stano
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Stanislav Meduna]

On 19.03.2012 18:44, Elad Yosef wrote:

> I get 108 KBytes/sec after lowering the CYGDBG_REDBOOT_TICK_GRANULARITY to 50.
> I'm downloading SREC image to my target.
> I'm using MIPS32 4Kec.
> Does any changes to - hal_delay_us(int us) will improve the time?

Only if the hal_delay_us does not work as expected. If the throughput
significantly depends on the TICK_GRANULARITY in this range
I'd check whether the hal_delay_us really waits the time
it should.

FWIW, I am getting around 200 KB/s using an 80 MHz Cortex-M3
processor and the TICK_GRANULARITY of 250 us. I have no experience
with MIPS32 but from the description the CPU power shouldn't
be an issue here.

Note that it can also be the server that is introducing
the latencies, especially if it runs on a loaded machine.
Or a network driver bug - people usually don't really test
the polled mode much.

A Wireshark could tell whether it is the client or the
server who is introducing latencies and also whether there
are any lost packets.

Regards
-- 
                                         Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Gary Thomas]

On 2012-03-19 12:11, Stanislav Meduna wrote:
> On 19.03.2012 18:44, Elad Yosef wrote:
>
>> I get 108 KBytes/sec after lowering the CYGDBG_REDBOOT_TICK_GRANULARITY to 50.
>> I'm downloading SREC image to my target.
>> I'm using MIPS32 4Kec.
>> Does any changes to - hal_delay_us(int us) will improve the time?
>
> Only if the hal_delay_us does not work as expected. If the throughput
> significantly depends on the TICK_GRANULARITY in this range
> I'd check whether the hal_delay_us really waits the time
> it should.
>
> FWIW, I am getting around 200 KB/s using an 80 MHz Cortex-M3
> processor and the TICK_GRANULARITY of 250 us. I have no experience
> with MIPS32 but from the description the CPU power shouldn't
> be an issue here.
>
> Note that it can also be the server that is introducing
> the latencies, especially if it runs on a loaded machine.
> Or a network driver bug - people usually don't really test
> the polled mode much.
>
> A Wireshark could tell whether it is the client or the
> server who is introducing latencies and also whether there
> are any lost packets.

Also, the performance will vary greatly, depending on the actual
networking hardware.  I get 1MB/sec on a reasonably fast PowerPC
(MPC8379), without any special tuning.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Speed up TFTP download time in RedBoot

[Elad Yosef]

Hi,
I have setup Wire-sharp capture and got about 2 msec between the data
packet and the following ack and again 2 msec delay between the ack
and the following data packet.
I have looked at the fttp code it looks that is not supporting the
"blksize" option as stated in newer RFC.
I would like to to update the tftp code and give it back to eCos.
Where can I get guidance how to?
I'm planing to add option in the CDL file to select the block size.
In case the server does not support "blksize" the client retries to
init session with 512 block size.

Elad



On Mon, Mar 19, 2012 at 8:49 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2012-03-19 12:11, Stanislav Meduna wrote:
>>
>> On 19.03.2012 18:44, Elad Yosef wrote:
>>
>>> I get 108 KBytes/sec after lowering the CYGDBG_REDBOOT_TICK_GRANULARITY
>>> to 50.
>>> I'm downloading SREC image to my target.
>>> I'm using MIPS32 4Kec.
>>> Does any changes to - hal_delay_us(int us) will improve the time?
>>
>>
>> Only if the hal_delay_us does not work as expected. If the throughput
>> significantly depends on the TICK_GRANULARITY in this range
>> I'd check whether the hal_delay_us really waits the time
>> it should.
>>
>> FWIW, I am getting around 200 KB/s using an 80 MHz Cortex-M3
>> processor and the TICK_GRANULARITY of 250 us. I have no experience
>> with MIPS32 but from the description the CPU power shouldn't
>> be an issue here.
>>
>> Note that it can also be the server that is introducing
>> the latencies, especially if it runs on a loaded machine.
>> Or a network driver bug - people usually don't really test
>> the polled mode much.
>>
>> A Wireshark could tell whether it is the client or the
>> server who is introducing latencies and also whether there
>> are any lost packets.
>
>
> Also, the performance will vary greatly, depending on the actual
> networking hardware.  I get 1MB/sec on a reasonably fast PowerPC
> (MPC8379), without any special tuning.
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
>
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss