Re: [Xenomai-core] Question about getting system time
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. Even a third clock would have to be delivered for more archs than x86, no question. We would basically need a generic but slow syscall variant and per-arch syscall-less optimizations (where feasible). So, you would add a syscall which would becomre useless when you have implemented synchronized clocks properly? Yet another reason for avoiding this solution. Could be CLOCK_LINUX - ie. no need for a new syscall. I am Ok for this solution (and now that I think about it, I wonder if we did not already have this discussion). Anyway, I would go for CLOCK_HOST_REALTIME, in case someone wants to implement CLOCK_HOST_MONOTONIC. The advantage is that we can return EINVAL in the timer_create or clock_settime calls, to indicate clearly that using this clock for timing services is verboten. And when/if the full synchronization is implemented, the ID simply becomes a #define. okay, so let's pursue this path. Patches will follow. Best, Wolfgang ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. Even a third clock would have to be delivered for more archs than x86, no question. We would basically need a generic but slow syscall variant and per-arch syscall-less optimizations (where feasible). So, you would add a syscall which would becomre useless when you have implemented synchronized clocks properly? Yet another reason for avoiding this solution. Could be CLOCK_LINUX - ie. no need for a new syscall. I am Ok for this solution (and now that I think about it, I wonder if we did not already have this discussion). Anyway, I would go for CLOCK_HOST_REALTIME, in case someone wants to implement CLOCK_HOST_MONOTONIC. The advantage is that we can return EINVAL in the timer_create or clock_settime calls, to indicate clearly that using this clock for timing services is verboten. And when/if the full synchronization is implemented, the ID simply becomes a #define. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. Even a third clock would have to be delivered for more archs than x86, no question. We would basically need a generic but slow syscall variant and per-arch syscall-less optimizations (where feasible). So, you would add a syscall which would becomre useless when you have implemented synchronized clocks properly? Yet another reason for avoiding this solution. Could be CLOCK_LINUX - ie. no need for a new syscall. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
On 19/05/10 07:49, Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. I'm using Xenomai for scientific data acquisition, so I'm quite interested to the issue. Can I ask you to detail how you solved the issue? Maybe it's not much related, but there is any possibility to synchronize either linux or xenomay clocks to an external clock source, let say the GPS timing signal from a GPS receiver? Thanks. Cheers, -- Daniele ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Daniele Nicolodi wrote: On 19/05/10 07:49, Gilles Chanteperdrix wrote: Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. I'm using Xenomai for scientific data acquisition, so I'm quite interested to the issue. Can I ask you to detail how you solved the issue? In my case, I was working on network equipments, and we needed timestamping of rtnet packets to be synchronized with linux clock, to compare/merge them with timestamps of network packets captured in the Linux domain. An rtnet packet is passed to the Linux domain not longer after it has been captured (and timestamped) in Xenomai domain. So, I just corrected the Xenomai timestamp using the difference between xenomai timebase and Linux timebase at the time when the packet was passed to Linux domain. It turned out to be quite precise, and if it is not precise enough, some statistical method could probably be used to evaluate the drift and compensate for it. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
[moved to xenomai-core] Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: - gettimeofday should not have another timebase than clock_gettime(CLOCK_REALTIME): in other word, the whole clock system should be based on the ntp clock. Sorry, I'm not quite sure what you are talking about here. The NTP corrections are provided for the clock offered in the vsyscall page by Linux, so the clock is based on the NTP clock, isn't it? Or am I misparsing your statement? Unless I misunderstood your patch, what you provide is: gettimeofday which uses linux timebase clock_gettime which uses Xenomai timebase unrelated to linux' timebase This is unacceptable. What we want is a unique timebase. okay, I see your point now. But this sound more like 3.0 stuff, doesn't it? The goal right now is just to have some code that generates synchronised, NTP corrected timestamps on Linux and Xenomai, not to rework the base timer handling. And since this will have a cost not everyone is willing to pay, I have another requirement: this code should be compiled conditionally. - you should not use vread, you should use __xn_rdtsc directly in user-space, otherwise, your code would only work on x86. Of course this means that the I-pipe should create a clocksource with whatever hardware counter the architecture is providing to Xenomai. This also means that the I-pipe should declare a clocksource using whatever hardware counter is provided by the architecture with highest priority than other clocksources, to ensure that Linux is using the same clock source as Xenomai, and that NTP is correcting that clock source. This would also remove the issue with Linux declaring the tsc unstable. the reason why it's based on vread() is because the Linux kernel automatically makes sure that it points to a function that can be called from userland, so why would it only run on x86? Currently, the userland patch is limited to x86 because I've only adapted the sequence counter for this arch. Besides, vread() could also work with a different source than the TSC as long as it's accessible from userland. vread is a function pointer call, which: - requires vsyscalls, currently only implemented on x86 (and maybe ppc) - is function pointer call, so damn slow on low end hardware. ... and fast as lightning on x86 when the call is made often, which is the important case when speed matters. So it makes sense on this platform. Xenomai has __xn_rdtsc on all architectures, so, we should be based on that. Since what we want is Xenomai to use the same clock source as Linux, and anything else than tsc is not implemented for Xenomai, we should implement tsc first and keep other clock sources for later. And when we use another clock, __xn_rdtsc will use that clock anyway. - why the transactionnal mechanism at all? Why not simply using seqlocks with an ipipe_spinlock, and do the update with irqs off? the locking section is much shorter than, say, xnpod_schedule, so it will not have any influence on the worst case latency, and the reader side will still be lockless. Because even if we don't increase the peak latency, we'll still increase the average latency. Additionally, it would also be possible to extend the base mechanism to an RCU-style communication channel between the kernel and Xenomai in the long run, so I'd argue that the lock-less solution is nicer. It is a useless optimization, it is a lot of code to avoid shutting interrupts of for a handful of assignments (since you can avoid copying vread, and mult and shift which never change if we enfore the clock source). There are many more, longer masking sections everywhere in the I-pipe patch and in Xenomai code. On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... Would having the synchronised time stamp feature (maybe by another name than gettimeofday()) conditionally compiled on x86 be acceptable? Best, Wolfgang - the NTP event should trigger an ipipe event with ipipe_dispatch_event. could do, but I was following Gilles' suggestion ;-) to use an arch-specific hook since it's easier to maintain in the long run than writing a generic function and replacing every call to vsyscall_update(), also the future. (http://www.opensubscriber.com/message/xenomai-core@gna.org/13126830.html, although I can change that, certainly no religious issues here) What I mean is that vsyscall_update should trigger ipipe_dispatch_event. This is what I meant from
Re: [Xenomai-core] Question about getting system time
Wolfgang Mauerer wrote: [moved to xenomai-core] Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: - gettimeofday should not have another timebase than clock_gettime(CLOCK_REALTIME): in other word, the whole clock system should be based on the ntp clock. Sorry, I'm not quite sure what you are talking about here. The NTP corrections are provided for the clock offered in the vsyscall page by Linux, so the clock is based on the NTP clock, isn't it? Or am I misparsing your statement? Unless I misunderstood your patch, what you provide is: gettimeofday which uses linux timebase clock_gettime which uses Xenomai timebase unrelated to linux' timebase This is unacceptable. What we want is a unique timebase. okay, I see your point now. But this sound more like 3.0 stuff, doesn't it? The goal right now is just to have some code that generates synchronised, NTP corrected timestamps on Linux and Xenomai, not to rework the base timer handling. We are going to open a 2.6 branch soon (we are migrating Xenomai to a new hoster, and this job is almost finished). This will go to 2.6. And I am not going to merge anything that would provide two different timebases for CLOCK_REALTIME. That is too unnatural. There are a bunch of natural things which will not work with this approach. It create many ways to shoot oneself in the foot. So the answer is definitely no. vread is a function pointer call, which: - requires vsyscalls, currently only implemented on x86 (and maybe ppc) - is function pointer call, so damn slow on low end hardware. ... and fast as lightning on x86 when the call is made often, which is the important case when speed matters. So it makes sense on this platform. rdtsc is even faster. It is just one instruction. The generic solution is even faster than the architecture specific one. So, please implement the generic one. On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... Would having the synchronised time stamp feature (maybe by another name than gettimeofday()) conditionally compiled on x86 be acceptable? No. We have a generic implementation at hand for a limited amount of additional effort. Let us do things properly. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. I was referring to the argument that system calls are so fast that replacing gtod with a syscall-less version that uses function pointer dereferencing instead does not make much of a difference. Be it as it may, I need to check how far our budget can cover the (much more comprehensive) modifications required for the solution suggested by you. Let's see. Regards, Wolfgang ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Wolfgang Mauerer wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. I was referring to the argument that system calls are so fast that replacing gtod with a syscall-less version that uses function pointer dereferencing instead does not make much of a difference. That is not what I said. I compared the weight of a function pointer call with the one of four asignments with irqs off. And yes syscalls are fast on x86, do the measurements yourself, you may be surprised. Be it as it may, I need to check how far our budget can cover the (much more comprehensive) modifications required for the solution suggested by you. Let's see. I do not think there is that much work involved. The way I see it, we would need to replace our tsc reading function with one returning ntp-corrected tsc (that is, essentially a subset of the gettimeofday function you implemented, without conversion to ns and to CLOCK_REALTIME). Changes in this monotonic clock would trigger a recomputation of the next timer event date. Changes in monotonic to real-time conversion would trigger a call to xnpod_set_time. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. I was referring to the argument that system calls are so fast that replacing gtod with a syscall-less version that uses function pointer dereferencing instead does not make much of a difference. That is not what I said. I compared the weight of a function pointer call with the one of four asignments with irqs off. And yes syscalls are fast on x86, do the measurements yourself, you may be surprised. Be it as it may, I need to check how far our budget can cover the (much more comprehensive) modifications required for the solution suggested by you. Let's see. I do not think there is that much work involved. The way I see it, we would need to replace our tsc reading function with one returning ntp-corrected tsc (that is, essentially a subset of the gettimeofday function you implemented, without conversion to ns and to CLOCK_REALTIME). Changes in this monotonic clock would trigger a recomputation of the next timer event date. Changes in monotonic to real-time conversion would trigger a call to xnpod_set_time. If all works out well, it might be that simple. But this is timer/clock stuff, the heart of the system, and easy to get subtly wrong. For that reason the plan was to gain more confidence in the externally corrected clock source, collect experience in other use cases, and then work on the core for its optional use. So far our customer is using this clock for important but not yet critical jobs. Making it the RT clock source is of a different quality, and for now without a use case. I personally do want this feature long-term, definitely, but I do not see ATM it's going to be something we can deliver for 2.6. Maybe we can split out the lower bits and prepare I-pipe as well as the hal already. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. I was referring to the argument that system calls are so fast that replacing gtod with a syscall-less version that uses function pointer dereferencing instead does not make much of a difference. That is not what I said. I compared the weight of a function pointer call with the one of four asignments with irqs off. And yes syscalls are fast on x86, do the measurements yourself, you may be surprised. Be it as it may, I need to check how far our budget can cover the (much more comprehensive) modifications required for the solution suggested by you. Let's see. I do not think there is that much work involved. The way I see it, we would need to replace our tsc reading function with one returning ntp-corrected tsc (that is, essentially a subset of the gettimeofday function you implemented, without conversion to ns and to CLOCK_REALTIME). Changes in this monotonic clock would trigger a recomputation of the next timer event date. Changes in monotonic to real-time conversion would trigger a call to xnpod_set_time. If all works out well, it might be that simple. But this is timer/clock stuff, the heart of the system, and easy to get subtly wrong. For that reason the plan was to gain more confidence in the externally corrected clock source, collect experience in other use cases, and then work on the core for its optional use. So far our customer is using this clock for important but not yet critical jobs. Making it the RT clock source is of a different quality, and for now without a use case. To be quite frank about use cases, I do not really understand in what use case the patch Wolfgang sent is useful. An application can not use the timestamps returned by this gettimeofday syscall for anything useful. And if we talk about things breaking subtly, an application that would use these timestamps with Xenomai services would be subtly broken too. Avoiding the drift between Xenomai clock and Linux clock by making them synchronized by design, on the other hand, albeit probably solving a corner case, looks more useful, and some people asked for it (it looks to me like what Steve asked for is that, not to have a third timebase accessible in real-time context, and Steve asked for a solution for powerpc, not for x86). So, my feeling about all this is that Wolfgang's patch is not useful for anyone else than your customer. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: Gilles Chanteperdrix wrote: Wolfgang Mauerer wrote: On the one hand you make complicated code (which will be costly on low end hardware) to avoid shutting interrupts around a few assignments, but on the other hand you leave an architecture specific function pointer call where we want a fast behaviour on average (remember, we do all this to avoid a system call, which is only a few hundreds nanoseconds on your big iron x86), and where we have a generic fast replacement. Sometimes, I do not understand your logic. But using the same argument, you could get rid of Linux vsyscall based gettimeofday()... I do not see your point, the Linux code does not go a long way to make lockless code, it simply turns off interrupts around the gtod data update, which is really reasonable given the size of the masking section. The reading is lockless, the writing is not. I was referring to the argument that system calls are so fast that replacing gtod with a syscall-less version that uses function pointer dereferencing instead does not make much of a difference. That is not what I said. I compared the weight of a function pointer call with the one of four asignments with irqs off. And yes syscalls are fast on x86, do the measurements yourself, you may be surprised. Be it as it may, I need to check how far our budget can cover the (much more comprehensive) modifications required for the solution suggested by you. Let's see. I do not think there is that much work involved. The way I see it, we would need to replace our tsc reading function with one returning ntp-corrected tsc (that is, essentially a subset of the gettimeofday function you implemented, without conversion to ns and to CLOCK_REALTIME). Changes in this monotonic clock would trigger a recomputation of the next timer event date. Changes in monotonic to real-time conversion would trigger a call to xnpod_set_time. If all works out well, it might be that simple. But this is timer/clock stuff, the heart of the system, and easy to get subtly wrong. For that reason the plan was to gain more confidence in the externally corrected clock source, collect experience in other use cases, and then work on the core for its optional use. So far our customer is using this clock for important but not yet critical jobs. Making it the RT clock source is of a different quality, and for now without a use case. To be quite frank about use cases, I do not really understand in what use case the patch Wolfgang sent is useful. An application can not use the timestamps returned by this gettimeofday syscall for anything useful. And if we talk about things breaking subtly, an application that would use these timestamps with Xenomai services would be subtly broken too. Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. Avoiding the drift between Xenomai clock and Linux clock by making them synchronized by design, on the other hand, albeit probably solving a corner case, looks more useful, and some people asked for it (it looks to me like what Steve asked for is that, not to have a third timebase It is surely more useful, but also more complex. Nothing unsolvable, but asking for more care. accessible in real-time context, and Steve asked for a solution for powerpc, not for x86). Even a third clock would have to be delivered for more archs than x86, no question. We would basically need a generic but slow syscall variant and per-arch syscall-less optimizations (where feasible). So, my feeling about all this is that Wolfgang's patch is not useful for anyone else than your customer. I think your feeling is a bit too pessimistic on this general approach and a bit too optimistic regarding the complexity of a complete solution. But I wouldn't mind being proven wrong, specifically regarding the latter. However, let's see if we can do some uncontroversial steps in this direction. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Question about getting system time
Jan Kiszka wrote: Just like it seems to be the case for Steve (unless I misunderstood his reply), it is very useful for us being able to time-stamp events in RT context that need to be correlated with events stamped in non-RT (including non-Xenomai) parts or even on other systems: (offline) data fusion, logging, tracing. I even bet that this is currently the major use case for synchronized clocks, only a smaller part already has the need to synchronize timed activities on a common clock source. But there is huge potential in the second part once we can provide a stable infrastructure. I already had such issues, and I did not solve them by modifying Xenomai core. Even a third clock would have to be delivered for more archs than x86, no question. We would basically need a generic but slow syscall variant and per-arch syscall-less optimizations (where feasible). So, you would add a syscall which would becomre useless when you have implemented synchronized clocks properly? Yet another reason for avoiding this solution. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
