All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Xenomai-help] clock problem
@ 2011-08-15 13:50 Philip Ha
  0 siblings, 0 replies; 18+ messages in thread
From: Philip Ha @ 2011-08-15 13:50 UTC (permalink / raw)
  To: Xenomai-help

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]


> The cpu frequency is obtained by the linux kernel calibration procedure.
> This same procedure returns the same imprecise results without xenomai.
> Now, something in the distro kernel must change the frequency to a nice
> round value (a good candidate would be the cpufreq module, except that
> the acpi_cpufreq module does not seem to load on my atom).
>
> As a workaround, xenomai proposes kernel parameters to adjust the idea
> of the machine clock/cpu frequency. Try adding the following argument on
> the kernel command line:
>
> xeno_hal.clockfreq=1600000000 xeno_hal.cpufreq=1600000000


Hi Gilles,

Thank you very much for your help and advice. I tried it out on
our PC, and it worked. The latency between messages stays constant
(only varies to a few microseconds) after each reboot. 

I really appreciate for your help and patience.

Best regards,

Philip Ha 



[-- Attachment #2: Type: text/html, Size: 1115 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Xenomai-help] clock problem
@ 2011-08-11 21:18 Philip Ha
  2011-08-11 22:24 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 18+ messages in thread
From: Philip Ha @ 2011-08-11 21:18 UTC (permalink / raw)
  To: Xenomai-help

[-- Attachment #1: Type: text/plain, Size: 1500 bytes --]

> Could you try measuring the jitter in cpu cycles with rdtscll, in
> kernel-space? If the inaccuracy persists, check that cpufreq is not
> enabled, and that if running on a multicore system, tscs are
> synchronized. Apart from that no, no idea.
>
> -- 
>                                            Gilles.


Hi Gilles,

I measured the interval between input pulses using rdtsc to grab the 
cpu cycles. The number of clock cycles between my 1 second input 
pulses was quite consistent varying by less than 10,000 cycles. On 
my 1600 MHz system that works out to less than 6 us. This value was 
consistent between reboots. This indicates to me that the tsc clock 
is very stable between reboots.

Looking at /proc/cpuinfo showed that the "cpu MHz" value changes 
by a small amount during each reboot. It varies from 1600.131 MHz 
to 1599.628 MHz. The difference between 1600 and 1599.628 MHz 
accounts exactly for the unexpected latency I described in earlier 
emails.

So it would seem that the frequency used for clock time stamps is 
reported incorrectly when using my Xenomai build. If I boot the system 
with regular Ubuntu, /proc/cpuinfo consistently reports the frequency 
as 1600 MHz.

I do not have CPU scaling set. I am running an Atom dual CPU 
processor and /proc/cpuinfo shows both processors as having the 
same frequency. How can I ensure syncronization of the tscs?

The Xenomai build seems to produce an incorrect cpufreq, any ideas 
as to why?

Thanks for all your help.

Philip Ha


[-- Attachment #2: Type: text/html, Size: 1766 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Xenomai-help] clock problem
@ 2011-08-10 15:18 Philip Ha
  2011-08-10 15:49 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 18+ messages in thread
From: Philip Ha @ 2011-08-10 15:18 UTC (permalink / raw)
  To: Xenomai-help

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]


> The question remains: are you sure the UART does not introduce the
> delay, have you checked the datasheet?
>
> -- 
                                                                Gilles.
Hi Gilles,

I apologize for the delay in responding the last message.

I measured the latency of the UART by pulsing the DTR pin on the 
serial port as soon as the ISR is called. Using an oscilloscope 
I monitored the DSR input signal from the function generator and 
the DTR signal from the serial port. The time difference between 
signals was 6-9 us. Therefore the latency of the UART is < 10 us 
at all times.

As long as the UART latency is consistent the size of it does not
matter for the test I am performing. An input signal that comes in 
every 1000000 us should result in the 16550 ISR being called every 
1000000 us.

The function generator is accurate to 1us, the UART ISR latency 
jitter is approximately 3 us. Therefore I would not expect to see
100 us of timing measurement inacurracy using OS time stamps. It 
is also strange that this timing measurement inaccuracy changes 
every time the system is rebooted.

Any thoughts? 


Thanks,

Philip Ha

[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Xenomai-help] clock problem
@ 2011-08-04 19:27 Philip Ha
  2011-08-05 12:53 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 18+ messages in thread
From: Philip Ha @ 2011-08-04 19:27 UTC (permalink / raw)
  To: Xenomai-help

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

> Would it be possible for you to send mails formatted correctly?
>
> Then the bug is somewhere in between the serial line and the test
> application, including possibly in the driver.
>
> In order to know where it is, you should compute the latency at each
> point on this path: when receiving the interrupt, when waking up the
> task, etc...
>
> -- 
>                                                                Gilles.



Hi Gilles,

Sorry for the formatting, I am new to mailing lists.

I have looked at the latency in the 16550A driver. The first thing 
the driver does in its ISR is to call rtdm_clock_read and store the 
resulting timestamp in a "struct rtser_event". The code I posted 
grabs this structure. If I use this as my timestamp I get the exact
same timing results.

It seems like the clock used by rtdm_clock_read is fast. I don't
see how I could get a delay according to rtdm_clock_read of 
1000000us between interrupts that I know are being triggered by an 
event coming in at 1000000 us.

Do you have any suggestions on what I can test?

Thanks for all your help.

Philip Ha

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* Re: [Xenomai-help] clock problem
@ 2011-08-04 15:55 Philip Ha
  2011-08-04 16:39 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 18+ messages in thread
From: Philip Ha @ 2011-08-04 15:55 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/plain, Size: 7223 bytes --]


> Hi Gilles,
>
> The following is some part of the code. It is receiving data at a period of
> 1 second intervals. The variable "lat" prints similar latency values for
> the current session, even though I stop the program and start again several
> times. The latency values change everytime I reboot the PC. Please
> advise.

I do not understand:
- how the "latency" may be 40us while it should be around 1s, if you say
that the periodic event happens every second;
- whether you are compiling for the native skin or posix skin, could you
show us the compilation arguments you pass?
- on what platform you get this issue?

-- 
Gilles.



Hello Gilles,

Sorry for any confusion, here are the responses to your questions:

The
 "latency" or time elapsed between events recieved on the serial port 
should ideally be 1 second. However the system will have some
 latency jitter, therefore I would expect the delay to be 1 second +- 
some number of microseconds.

Using the attached program running 
on an x86 system I see a "latency" of 1 second + some variable number of
 microseconds. Each time I reboot the system the variable number of 
micro seconds changes anywhere from 40 to 100 microseconds. The total 
latency is always greater than 1 second.

I know that the pulse 
generated by the function generator ( Agilent 33220A ) is acurrate to 1 
microsecond. This unit has also been recently calibrated.

How is 
this possible? Is it possible that the clock I am using on the x86 
system to capture timing is faster than the clock used on the function 
generator?

I am compiling using the POSIX skin. The compilation arguments are:

CFLAGS+= -g $(shell $(XENOCONFIG) --skin=posix --cflags) $(APP_CFLAGS)

LDFLAGS+= $(shell $(XENOCONFIG) --skin=posix --ldflags) $(APP_LDFLAGS)
 \
-L$(BUILD_ROOT)/usr/xenomai/lib -lrtdm -lrt


The results have been repeated on two different systems:

root@domain.hid# lscpu
Architecture: i686
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 2
Thread(s) per core: 1
Core(s) per socket: 2
CPU socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 15
Stepping: 6
CPU MHz: 1000.000
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K

root@domain.hid# lscpu
Architecture: i686
CPU op-mode(s): 32-bit
CPU(s): 2
Thread(s) per core: 2
Core(s) per socket: 1
CPU socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 28
Stepping: 2
CPU MHz: 1599.820
Virtualization: VT-x
L1d cache: 24K
L1i cache: 32K
L2 cache: 512K


Here is my complete program:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include
 <posix/time.h>
#include <fcntl.h>
#include <posix/posix.h>
#include <rtdm/rtserial.h>


//******************
// Global defines
//******************
#define DEVICE_NAME "rtser0"

//***********************
// Global Structures
//***********************
struct rtser_config set_config =
{
.config_mask = 0xFFFF,
.baud_rate = 9600,
.parity = RTSER_DEF_PARITY,
.data_bits = RTSER_DEF_BITS,
.stop_bits = RTSER_DEF_STOPB,
.handshake = RTSER_DEF_HAND,
.fifo_depth = RTSER_FIFO_DEPTH_8,
.rx_timeout = RTSER_DEF_TIMEOUT,
.tx_timeout = RTSER_DEF_TIMEOUT,
.event_timeout = 6000000000, /* 6 s */
.timestamp_history = RTSER_RX_TIMESTAMP_HISTORY,
.event_mask = RTSER_EVENT_MODEMHI,
};

static int device_fd = -1;


//***********************************************************
//
// int open_serial_port(void)
//
// rt_dev_ioctl returns - Positive
 value on success,
// negative error code.
//
// rt_dev_open returns - Positive value on success,
// negative error code
//
//***********************************************************
static int open_serial_port(void)
{
int err = 0;

// Open RT Serial Port
device_fd = rt_dev_open(DEVICE_NAME, 0);
if (device_fd < 0)
{

printf("\nopen_serial_port => can't open %s (write), %s\n", DEVICE_NAME,
strerror(-device_fd));
return device_fd;
}

printf("\nopen_serial_port => opened\n");


// Setting port config
err = rt_dev_ioctl(device_fd, RTSER_RTIOC_SET_CONFIG, &set_config);
if (err < 0)
{
printf("open_serial_port => error while RTSER_RTIOC_SET_CONFIG, %s\n",
strerror(-err));
return err;
}

printf("open_serial_port => port config set\n");

return
 err;
}



/************************************************************
*
* int get_args(int argc, char *argv[])
*
************************************************************/
int get_args(int argc, char *argv[])
{
int c = 0;
int ok = -1;

while (ok != 0)
{
if ( argc == 0 ) 
{
printf("usage: %s filename", argv[0]);
}
else
{
while ((c = getopt (argc, argv, "bd")) != -1)
{
switch (c)
{
case 'b':
set_config.baud_rate = atoi(argv[2]);
printf("get_args => baud_rate set to %d\n", atoi(argv[2]));
break;

case 'd':
set_config.data_bits = atoi(argv[4]);
printf("get_args => data bit set to %d\n", atoi(argv[4]));
break;

default:
break;
}
}

ok =0;
}
}
return ok;
}

//***********************************************************
//
// void
 cleanup_all(void)
//
//***********************************************************
static void cleanup_all(void)
{
rt_dev_close(device_fd); // close serial port
printf("cleanup_all => close port and/or cancel pthread\n");
}


//***********************************************************
//
// struct timespec calc_time(struct timespec start,
// struct timespec end)
//
//
//***********************************************************
struct timespec calc_time(struct timespec start, struct timespec end)
{
struct timespec temp;

if ((end.tv_nsec - start.tv_nsec) < 0) {
temp.tv_sec = end.tv_sec - start.tv_sec - 1;
temp.tv_nsec = 1000000000 + end.tv_nsec - start.tv_nsec;
} else {
temp.tv_sec = end.tv_sec - start.tv_sec;
temp.tv_nsec = end.tv_nsec - start.tv_nsec;
}
return temp;
}

//***********************************************************
//
// int
 main(void)
//
// clock_settime returns - 0 on success, -1 if failed.
//***********************************************************

int main (int argc, char *argv[])
{
int rtn_code = 0;
struct timespec res;
int stat = 0;
int err = 0;
struct rtser_event rx_event;

struct timespec curr_time;
struct timespec prev_time;
struct timespec elapsed_time;
double lat = 0.0;

// Process arguments from command line
rtn_code = get_args(argc, argv);

// No memory-swapping for this program
mlockall(MCL_CURRENT | MCL_FUTURE);

// Open serial port
rtn_code = open_serial_port();
if (rtn_code < 0)
goto error;

stat = clock_getres(CLOCK_MONOTONIC, &res);
printf("clock resolution => %d %ld\n", (int)res.tv_sec, res.tv_nsec);

rx_event.events = RTSER_EVENT_MODEMHI;

// part of code in main function

while (1)
{ 
// waiting for event from the serial
 driver
err = rt_dev_ioctl(device_fd, RTSER_RTIOC_WAIT_EVENT, &rx_event);
if (err < 0)
{
printf("serial_recv -> error on RTSER_RTIOC_WAIT_EVENT, %s\n",
strerror(-err));
} 
else if (clock_gettime(CLOCK_MONOTONIC, &curr_time) == -1)
perror("clock gettinme");

// elapsed time between previous and current message
elapsed_time = calc_time(prev_time, curr_time);

// Convert to seconds
lat = elapsed_time.tv_sec + elapsed_time.tv_nsec/1000000000.0;

prev_time = curr_time;

printf("%d", (int)curr_time.tv_sec);
printf(" %ld", curr_time.tv_nsec);
printf(" %lf\n", lat);
}

error:
cleanup_all();
return rtn_code;

}


Please advise.

Thank you,

Philip Ha

[-- Attachment #2: Type: text/html, Size: 8390 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
[parent not found: <1311873701.2537.YahooMailClassic@domain.hid>]
* [Xenomai-help] clock problem
@ 2011-07-20 18:35 Philip Ha
  0 siblings, 0 replies; 18+ messages in thread
From: Philip Ha @ 2011-07-20 18:35 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]


Hi All,

I would like to add some more details for the message I posted on 19 July.

The timing period for the testing is 1 second intervals. So every second, I will
call clock_gettime to get the current time, and measures the elapsed time
(or latency) between 2 events (messages).

The event is triggered by the function generator, which send s a pulse signal 
to the serial port at one second intervals.

Can someone please advise me about the unstable elapsed time (latency)
after the reboots.

Regards,
Philip Ha


[-- Attachment #2: Type: text/html, Size: 697 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* [Xenomai-help] clock problem
@ 2011-07-19 14:24 Philip Ha
  2011-07-27 18:47 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 18+ messages in thread
From: Philip Ha @ 2011-07-19 14:24 UTC (permalink / raw)
  To: xenomai

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Dear all,

I am running a serial port test in xenomai (xenomai-2.5.5.2) using 16550A driver.
In my program, I am calling

rt_dev_ioctl(dev_id, RTSER_RTIOC_WAIT_EVENT, & rx_event);

when an event happens, I use clock_gettime(CLOCK_MONOTONIC, & curr_time)
to get the current time. The program runs continuosly in a while loop. In this way, I 
measure the elapsed time between the previous and current events.


For this test, I find something that I still cannot figure out. They are as follows:

1st session running the program, elapsed time between events - 40 us  (reboot system)
2nd session                                                  - 80 us  (reboot system)
3rd session                                                  - 150 us (reboot system)
4th session                                                  - 100 us (reboot system)

and so on.

And I use clock_getres to see the resolution of the clock, tv_sec = 0, tv_nsec = 1.

My question is - why everytime I reboot the system, I get different elapsed time 
measurement for the same program?

Can someone please help ?


Regards,

Ph293

[-- Attachment #2: Type: text/html, Size: 2060 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-08-15 13:50 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <1311805213.7716.YahooMailClassic@domain.hid>
2011-07-28 14:35 ` [Xenomai-help] clock problem Gilles Chanteperdrix
2011-08-15 13:50 Philip Ha
  -- strict thread matches above, loose matches on Subject: below --
2011-08-11 21:18 Philip Ha
2011-08-11 22:24 ` Gilles Chanteperdrix
2011-08-10 15:18 Philip Ha
2011-08-10 15:49 ` Gilles Chanteperdrix
2011-08-04 19:27 Philip Ha
2011-08-05 12:53 ` Gilles Chanteperdrix
2011-08-08 16:44   ` Philip Ha
2011-08-08 18:00     ` Gilles Chanteperdrix
2011-08-04 15:55 Philip Ha
2011-08-04 16:39 ` Gilles Chanteperdrix
2011-08-04 17:26   ` Philip Ha
2011-08-04 17:34     ` Gilles Chanteperdrix
     [not found] <1311873701.2537.YahooMailClassic@domain.hid>
2011-07-31 17:19 ` Gilles Chanteperdrix
2011-07-20 18:35 Philip Ha
2011-07-19 14:24 Philip Ha
2011-07-27 18:47 ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.