Re: RedBoot load command speedup

[Yoshinori Sato <qzb04471 at nifty dot ne dot jp>]

At Thu, 27 Jun 2002 12:29:22 +0200 (CEST),
Larice Robert wrote:
> 
> > The transmission speed of the RedBoot "load" command was accelerated.
> > 
> > The tftp download speed of 600KByte raw binary by H8/3068(20MHz)
> > 15sec -> 8sec It became twice as many speed as this.
> > 
> > Reading stream of 512byte blocks.
> > 
> > Please give me evaluation with any target.
> > -- 
> > Yoshinori Sato
> > <qzb04471@nifty.ne.jp>
> > 
> 
> Hello,
> 
>   on my system (a sh4 7751 + 82559) i can see cpu idling for 1ms per received
>   tftp udp packet.
>   searching a bit the source it seems
>     1) redboot uses polling mode for ethernet
>     2) there is a MS_DELAY_US() call somewhere in the network code
>     3) this MS_DELAY_US is really do_ms_tick in redboots ticks.c file
>     4) which calls CYGACC_CALL_IF_DELAY_US(1000);
>     5) which calls hal_delay_us
>   thus you shouldn't be able to receive more than 1000 packets (512 byte each)
>   via udp, thus less than 512kbyte/s
> 
>   is your hal_delay_us broken ?
>   or did you somehow speed up the polling code ?

It seems that it is normal

>   i get 306kByte/s without your patch
> 
>   scope shows me:
>     ethernet send activity (pci bus master read of mem)
>     cpu is going idle now (no rom access any more)
>     followed pretty fast by ethernet receive activity (bus master write to mem),
>     now ethernet chip activates irq line, (though this is not used by redboot)
>     now aprox 1ms pass (total cpu inactivity pretty exact 1ms)
>     cpu goes active, irq line is deasserted
>     cpu does the actual while(getc()) (one can see write access with
>     low density).
> 
>   with your patch speed dropped to 150k/s
>   scope reveals 2*1000us idleness
> 
>   if i modify the do_ms_ticks to 100us instead of 1000us, i get
>     554kbyte/s (without your patch) (and scope shows much less cpu idleness)
>   if i then apply your patch speed drops again to 205k/s

It may be that the throughput of CPU has not caught up. Investigate.

-- 
Yoshinori Sato
<qzb04471@nifty.ne.jp>