[ECOS] Regarding timing measurements for eCos
Abhi
abhi@4961ocean.org
Thu Dec 9 23:10:00 GMT 2004
>> 2. I believe cyg_current_time() on iPAQ has a granularity of 10ms
>> and HAL_CLOCK_READ returns a number between 0 -- 36864. Thus the
>> granularity using HAL_CLOCK_READ is 10ms/36864. Is this correct?
>
> Look at the tm_basic source - it will show you how to use HAL_CLOCK_READ
> to get times down to the hardware clock rates.
The way I was calculating the granularity is:
On ipaq
#define CYGNUM_HAL_RTC_PERIOD 36864
and
#define CYGNUM_HAL_RTC_NUMERATOR 1000000000
#define CYGNUM_HAL_RTC_DENOMINATOR 100
Thus the clock interrupt happens every 10ms, hence the RTC granularity is
10ms/36864 = 271.2 nano-seconds
Is this correct?
thanks
- Abhi
--On Thursday, December 09, 2004 3:17 PM -0700 Gary Thomas
<gary@mlbassoc.com> wrote:
> On Thu, 2004-12-09 at 14:04, Abhi wrote:
>> Hi,
>> I am doing some performance benchmarks for ecos on iPAQ.
>> eCos version 2+ from the cvs repository
>> Last Changelog entry is
>> {
>> 2003-03-27 Bart Veer <bartv@ecoscentric.com>
>>
>> * configure.in, configure:
>> Look for the host-side sources in tools/src as well as in host,
>> as per the 2.0 release tree.
>> Look for per-package host-side software in any/all versions of a
>> package, not just "current".
>> }
>>
>> I ran the tm_basic.cxx test case to obtain some numbers for simple tests:
>>
>> Platform: Compaq iPAQ Pocket PC (StrongARM 1110)
>> Copyright (C) 2000, 2001, Red Hat, Inc.
>> Confidence
>> Ave Min Max Var Ave Min Function
>> ====== ====== ====== ====== ========== ========
>> ...
>> 1.64 1.63 2.98 0.03 97% 97% Thread switch
>>
>> I guess Thread switch takes about 1.64 micro-seconds.
>>
>> I modified the tcp_lo_test.c to measure the performance of tcp loopback
>> communication
>>
>> In the server() I added
>> if ((len = read(e_source, data_buf, MAX_BUF)) < 0 )
>> {
>> CYG_TEST_FAIL_FINISH( "I/O error" );
>> }
>> HAL_CLOCK_READ(&tcp_test[test_iter].end); // get the raw clock
>> ticks after reading the data
>> cyg_semaphore_post(&wait_for_server);
>>
>>
>> While in the client ()
>>
>> wait_for_tick();
>> for (test_iter = 0; test_iter < nsamples; ++test_iter)
>> {
>> // diag_printf("Sending %d times\n", i);
>> // start_tick = cyg_current_time();
>> HAL_CLOCK_READ(&tcp_test[test_iter].start);
>> if ((len = write(s_source,data_buf_write,40)) < 0)
>> {
>> CYG_TEST_FAIL_FINISH( "Error writing buffer");
>> }
>> cyg_semaphore_wait(&wait_for_server);
>> }
>>
>> and eventually I called
>> show_times_hdr();
>> show_times_detail(tcp_test, nsamples, "tcp_one_way_test", true);
>>
>> The result shows an average latency of 9975 micro-seconds. This figure
>> makes me suspicious. It is too close to 10 ms (the kernel tick time).
>>
>> Other Questions:
>> ================
>> 1. I guess using HAL_CLOCK_READ for recording an interval is useless if
>> the interval is more than 10ms. Is this right?
>>
>> 2. I believe cyg_current_time() on iPAQ has a granularity of 10ms
>> and HAL_CLOCK_READ returns a number between 0 -- 36864. Thus the
>> granularity using HAL_CLOCK_READ is 10ms/36864. Is this correct?
>
> Look at the tm_basic source - it will show you how to use HAL_CLOCK_READ
> to get times down to the hardware clock rates.
>
>>
>> 3. If the interval I am trying to measure is more than 10ms, but I want
>> a granularity of say 1 micro-second. How do I do that? Do I need to
>> create a real_time clock using the get_clock() methods?
>
> Not necessarily - I'd just use a combination of cyg_current_time() [to
> measure 10ms chunks] and HAL_CLOCK_READ() [to measure sub 10ms part].
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list