This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot load command speedup
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>