[Xenomai-core] Re: [Xenomai-help] rt_task_wait_period() and overruns

2006-02-28 Thread Steven Seeger
would be to make this a task property that users can set? Keep the current behavior by default, but purge overruns if they so desire. The cost of this would be only one branch condition in rt_task_wait_period(). Steven On 2/28/06 9:53 AM, Philippe Gerum [EMAIL PROTECTED] wrote: Steven Seeger

[Xenomai-core] rt_alarm_create

2005-10-11 Thread Steven Seeger
Why is there a different version of this function for user and kernel space? I don't see this reflected in the docs. Steven

[Xenomai-core] rt_timer_ticks2ns

2005-10-11 Thread Steven Seeger
In periodic mode, rt_timer_ticks2ns should convert ticks to periodic jiffies. However, it always seems to return 0.

Re: [Xenomai-core] rt_timer_ticks2ns

2005-10-11 Thread Steven Seeger
Do you have to ask? :) rt_timer_start(125000); On 10/11/05 7:24 AM, Gilles Chanteperdrix [EMAIL PROTECTED] wrote: Steven Seeger wrote: In periodic mode, rt_timer_ticks2ns should convert ticks to periodic jiffies. However, it always seems to return 0. Did you call rt_timer_start before

Re: [Xenomai-core] rt_queue_create in RT task?

2009-03-09 Thread Steven Seeger
Andreas, I do not know your situation but it is generally better to not allocate things in realtime contexts because it is not deterministic. You may consider redesigning your applications to use pre-allocated queues as it would be better overall. Regards, Steven On Mar 9, 2009, at 10:20

Re: [Xenomai-core] rt_queue_create in RT task?

2009-03-09 Thread Steven Seeger
I do not have Xenomai code in front of me, but I see no reason why this should be a problem but I don't have Xenomai code easily accessible right now so I can't provide any further insight. Steven ___ Xenomai-core mailing list Xenomai-core@gna.org

[Xenomai-core] rtdm timers

2009-03-10 Thread Steven Seeger
Gilles believes he's on the track of our FPU issue when using kernel threads. Would using an RTDM timer to accomplish our need have the same issue? We would not use the FPU in the timer of course, because it is not allowed. I just don't want to spend the time converting things if it won't

[Xenomai-core] rtdm timer questions

2009-03-12 Thread Steven Seeger
Is an RTDM timer going to run at a priority higher than any scheduled realtime thread? How accurate is the timing? We are seeing the timer running at 125us periodic rate being called much too quickly. At least, I think we are. I can't personally use anything for a little over a week.

Re: [Xenomai-core] rtdm timer questions

2009-03-12 Thread Steven Seeger
wrote: Steven Seeger wrote: Is an RTDM timer going to run at a priority higher than any scheduled realtime thread? How accurate is the timing? We are seeing the timer running at 125us periodic rate being called much too quickly. At least, I think we are. I can't personally use anything

Re: [Xenomai-core] rtdm timer questions

2009-03-12 Thread Steven Seeger
Not explicitly specified, but the existing timer will be stopped first and then newly started. I should see if we are doing that, then. We are loading bytes into a buffer and calling start if we need to call it. Perhaps the logic is incorrect. ...start ... in 2 ms sounds a bit like

Re: [Xenomai-core] rtdm timer questions

2009-03-12 Thread Steven Seeger
I think I see what my problem is with the driver. The flag that is holding off the extra starts is stupidly not set to volatile. Oops. I'll report back with results later. Thanks, Steven ___ Xenomai-core mailing list Xenomai-core@gna.org

Re: [Xenomai-core] rtdm timer questions

2009-03-12 Thread Steven Seeger
Be careful with volatile variables: Unless they refer to hardware- backed data (MMIO), you may just happen to write racy lock-less code - or the volatile is useless anyway. Yes that is true. In this case, however, writes are atomic (just 0 or 1) and even if something happens the mode of

[Xenomai-core] irq0 usage

2009-03-23 Thread Steven Seeger
We are still running into issues where irq0 is using a lot of CPU time. The same threads on an RTAi system on the same hardware used about 13% of the CPU but are using closer to 60% on Xenomai. I know there is some overhead with userspace calls but hte irq0 handler alone accounts for 20%

Re: [Xenomai-core] irq0 usage

2009-03-23 Thread Steven Seeger
What are you comparing, I mean, exactly? All kernel RTAI vs all userland Xenomai? Yes. The timer handler is charged for the callbacks it runs, so it really boils down to what code is attached to Xenomai timers, aside of the built-in scheduler tick. In this case we have only a single RTDM

Re: [Xenomai-core] irq0 usage

2009-03-23 Thread Steven Seeger
Ok, so we will agree that the 20%/60% ratios can't be compared, in fact. Do you mean that this is not a fair comparison or that I should not be this slow compared to RTAI? The fact that the GX still has to use a crappy 8253 PIT for timing and must emulate the TSC using one of the PIT

[Xenomai-core] tsc/ticks question

2009-03-24 Thread Steven Seeger
rt_task_set_periodic() says the period parameter is expressed in clock ticks. We have tsc being used as clockdev now, while pit is timerdev. We are getting -EINVAL from all these routines. /proc/xenomai/latency is 4200 I notice that in module.c, nklatency is printed with

[Xenomai-core] more on tsc/ticks

2009-03-24 Thread Steven Seeger
It seems that the real problem is that something is wrong with the TSC. We disabled the watchdog code that removes the TSC as the clocksource. Again, the kernel says timerdev is pit (which is right because there is no apic) and clockdev is tsc. I go back to emails with Jan and Phlippe from

[Xenomai-core] tsc part 3

2009-03-24 Thread Steven Seeger
Things seem to be working ok so far. The problem was we had left the kernel CONFIG_OPT_TIMING_PERIODIC on by mistake after doing a test. Numbers are a little nicer but still higher than I'd like. The sound driver which has a single rtdm timer running and doing nothing brings irq0 handler up

[Xenomai-core] irq0 usage

2009-03-26 Thread Steven Seeger
Using TSC really dropped us down. I don't know wh\y the timekeeper says tsc is unstable. We ran our system for an 8 minute cycle and timed it with a stopwatch, and it was accurate to the second. On our test irq0 usage dropped from 19% to 13%. Thanks for the help, guys. Steven

Re: [Xenomai-core] irq0 usage

2009-03-26 Thread Steven Seeger
I forgot to mention. In order to keep tsc as the clockdev I disabled the code in the kernel that removes it as the clocksource. Steven On Mar 26, 2009, at 1:25 PM, Steven Seeger wrote: Using TSC really dropped us down. I don't know wh\y the timekeeper says tsc is unstable. We ran our system

Re: [Xenomai-core] use case: possible to boot Posix subsystem in 50ms and then Linux?

2009-03-27 Thread Steven Seeger
Peter, Please tell us more about your hardware platform. I know this is not possible on convention x86 boards with a PC compatible BIOS. Thanks, Steven On Mar 27, 2009, at 10:38 AM, Peter W├Ąchtler wrote: Hi Xenomai developers, for automotive control units the boot time is essential. After

Re: [Xenomai-core] use case: possible to boot Posix subsystem in 50ms and then Linux?

2009-03-27 Thread Steven Seeger
Well the hardware should not matter and the startup code should be finished in several milli seconds, of course. Most probably are ARM. PPC or SH4 platforms used in automotive devices. In the automation industry the boot time is not that important - therefore a lot of PC compatible

[Xenomai-core] geode gx1 latencies

2009-03-27 Thread Steven Seeger
Per Gilles's suggestion, Mark at Stellartech ran latency and klatency with the TSC enabled the hack and without the TSC enabled. He also posted the CPU task measurements with our app running without the hack, which is horrible compared to when the TSC is on. It looks like we are better off

[Xenomai-core] pipe issue

2009-03-30 Thread Steven Seeger
List, We seem to have an issue where a rt_pipe_read with TM_NONBLOCK in a loop never receives data. We loop and wait on a period for 1 second. This used to work. If we just do a 1 second blocking read the data will be received. We will write a simple test and send it tomorrow morning. I

[Xenomai-core] alarms

2009-04-02 Thread Steven Seeger
Can alarms be used in userspace? I ask because the docs still say RTDM timers can be used in userspace but Gilles told me they can not be. Also, does the alarm run at the priority of the thread that created it or does it run at a priority higher than anything else? Steven

[Xenomai-core] native syscalls

2009-04-08 Thread Steven Seeger
Can xenomai preempt its own system calls? We ran latency with our app. We had a thread waiting on a cond, and when we signaled that cond, the latency jumped from ~70us to almost 400us even though latency runs a higher priority thread than the thread that we wake up. Is there interrupt

[Xenomai-core] syscalls

2009-04-21 Thread Steven Seeger
So our crappy geode does not have sep. I was wondering if syscalls are preemptible? If I call rt_task_wait_period() in prio50, but before it finishes prio60 schedules in and makes the same call, does it have to wait for 50 to finish? It probably doesn't have to wait but I'm just checking.

[Xenomai-core] migration

2009-04-22 Thread Steven Seeger
Can the jitter that a high priority primary domain thread has be affected by lower priority threads migrating between domains? Or is this functionality fully preemptible? Thanks, Steven ___ Xenomai-core mailing list Xenomai-core@gna.org

[Xenomai-core] userspace applications and cache

2009-04-30 Thread Steven Seeger
If a userspace application running xenomai threads is large (1MB or so) then the code can't all live in cache on our puny 16kb instruction cache. Does the cache handling occur as needed in the primary domain or does it have to wait for Linux to handle it? Thanks, Steven