This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot load command speedup
- From: Mark Salter <msalter at redhat dot com>
- To: larice at vidisys dot de
- Cc: jeroen dot dobbelaere at acunia dot com, ecos-devel at sources dot redhat dot com
- Date: Mon, 1 Jul 2002 10:40:12 -0400
- Subject: Re: RedBoot load command speedup
- References: <200207011417.g61EHqS18675@doms.vidisys.com>
>>>>> Larice Robert writes:
> this MS_TICKS stuff is obviously meant to maintain some kind of rudimentary
> timebase, when there is actually none. (the idea of timebase is necessary
> for various net protocols, timeouts ...) simply shortening those delays
> will damage slow target machines. (those would have their time running
> more slowly, because the cpu-time per call to hal_delay_us would be worse)
> what could be done without much rising the hardware prerequisites,
> is to have a more sophisticated hal_delay_us.
> one which keeps running/circling in the background (without interrupts).
> i suppose most targets could be configured for some kind of free-running
> counter easily. instead of doing something like
> for(500) {
> trysomething();
> hal_delay_us(1000);
> }
> one would then to something like
> int t = hal_rudimentary_time_get();
> t = hal_rudimentary_time_add(t,500000);
> while(!hal_rudimentary_endofgame(t)) {
> trysomething();
> }
> so you wouldn't destroy concept of time by slow cpu processing, and
> you would poll as frequently as the machine actually can.
This is exactly what I did when I originally wrote the network stack
used by RedBoot. When Gary Thomas merged it into RedBoot, the change
to the current system of timekeeping was made. FWIW, I think this was
the right thing to do. The downside with what you suggest (and the
original timekeeping method) is that it depends on a free running
counter which may not be available in hardware.
I think that changing the base delay from 1ms to 100us (potentially
increasing max transfer speed by an order of magnitude) is the best
solution for slow tftp. Even slow (by today's standard) CPUs can do
a lot of work in 100us, so that timer granularity shouldn't present
a problem.
--Mark