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?