Re: [ECOS] Regarding timing measurements for eCos

[Gary Thomas <gary at mlbassoc dot com>]

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

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss