> 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 channels is not helping at
> all. Emulating the TSC costs 1 x time_of(outb) + 2 x time_of(inb),  
> each
> 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  
> is
> really costly compared to the SEP entry. I'd say ~800ns-1us vs 200ns  
> on
> 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  
integer math.

> 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  
you think?

> No, when _your_ test runs.

So we should run latency -p and then our test and look at the output?


Xenomai-core mailing list

Reply via email to