> Ok, so we will agree that the 20%/60% ratios can't be compared, in
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 channels is not helping at
> all. Emulating the TSC costs 1 x time_of(outb) + 2 x time_of(inb),
> time a timestamp is read via the rdtsc emulation code. That is costly.
Do you agree that if I build with TSC on and disable suspend on halt
(or use idle=poll) that xenomai will use rdtsc?
> It switches to supervisor mode using an interrupt (0x80); that logic
> really costly compared to the SEP entry. I'd say ~800ns-1us vs 200ns
> average for your target.
This is bad, but since our fastest userspace period is 500us it is not
a dealbreaker. Just rt_task_wait_next_period() and one mutex lock/
unlock is too much for it.
> Btw, did you fix your driver code regarding the unprotected usage of
> in pure Linux kernel context?
Yes in fact the new driver does not use floats at all. It's purely
> Eh, no. TSC is always preferred when available.
I was looking at rthal_timer_program_shot().
> Frankly, those figures are really surprising. rdtsc() is about
> 100-200ns, running rthal_get_8254_tsc() is a lot, lot more.
I asked above if what we did would really use the TSC or not. What do
> No, when _your_ test runs.
So we should run latency -p and then our test and look at the output?
Xenomai-core mailing list