This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RedBoot load command speedup


>>>>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]