[Xenomai-core] some results on my laptop

[Xenomai-core] some results on my laptop

[Jim Cromie]

some random sucesses ..

Ive been running an ipipe kernel as the default since shortly after 1/7.
Since then, Ive had a couple of freezes on boot,
and sometimes bash's auto-complete takes longer to complete,
but other than that, things have been solid.

But that kernel wasnt configured using scripts/prepare-kernel.sh,
so was missing the xeno_* modules.

[jimc@domain.hid latency]$ sudo ./run -- -T 120 -h
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: periodic user-mode task
warming up...
RTT|  00:00:05  (periodic user-mode task, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|       -4749|       -4585|       -3921|       0|       -4749|       
-3921
RTD|       -4749|       -4583|       -3015|       0|       -4749|       
-3015
RTD|       -4749|       -4578|       -2685|       0|       -4749|       
-2685
RTD|       -4750|       -4581|       -3015|       0|       -4750|       
-2685
RTD|       -4812|       -4578|       -3049|       0|       -4812|       
-2685
RTD|       -4757|       -4584|       -3785|       0|       -4812|       
-2685
RTD|       -4798|       -4584|       -2636|       0|       -4812|       
-2636
RTD|       -4757|       -4582|       -3029|       0|       -4812|       
-2636
RTD|       -4748|       -4582|       -3906|       0|       -4812|       
-2636
RTD|       -4751|       -4582|       -2666|       0|       -4812|       
-2636
RTD|       -4752|       -4582|       -2806|       0|       -4812|       
-2636
RTD|       -4748|       -4581|       -3157|       0|       -4812|       
-2636
RTD|       -4750|       -4583|       -2882|       0|       -4812|       
-2636
RTD|       -4779|       -4583|       -2816|       0|       -4812|       
-2636
RTD|       -4804|       -4585|       -2979|       0|       -4812|       
-2636
RTD|       -4747|       -4583|       -2684|       0|       -4812|       
-2636
RTD|       -4761|       -4583|       -2600|       0|       -4812|       
-2600
RTD|       -4763|       -4583|       -2782|       0|       -4812|       
-2600
RTD|       -4807|       -4584|       -2582|       0|       -4812|       
-2582
RTD|       -4787|       -4582|       -2721|       0|       -4812|       
-2582
RTD|       -4766|       -4584|       -2713|       0|       -4812|       
-2582
RTT|  00:01:04  (periodic user-mode task, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|       -4750|       -4584|       -2936|       0|       -4812|       
-2582
RTD|       -4749|       -4585|       -2736|       0|       -4812|       
-2582
RTD|       -4814|       -4586|       -2935|       0|       -4814|       
-2582
RTD|       -4781|       -4584|       -2884|       0|       -4814|       
-2582
RTD|       -4749|       -4579|       -2743|       0|       -4814|       
-2582
RTD|       -4749|       -4580|       -2708|       0|       -4814|       
-2582
RTD|       -4750|       -4585|       -2870|       0|       -4814|       
-2582
RTD|       -4748|       -4584|       -2761|       0|       -4814|       
-2582
RTD|       -4766|       -4585|       -3152|       0|       -4814|       
-2582
RTD|       -4755|       -4584|       -3001|       0|       -4814|       
-2582
RTD|       -4749|       -4584|       -2810|       0|       -4814|       
-2582
RTD|       -4748|       -4584|       -2935|       0|       -4814|       
-2582
RTD|       -4754|       -4584|       -2734|       0|       -4814|       
-2582
RTD|       -4789|       -4586|       -3109|       0|       -4814|       
-2582
RTD|       -4765|       -4583|       -2835|       0|       -4814|       
-2582
RTD|       -4751|       -4584|       -2767|       0|       -4814|       
-2582
RTD|       -4750|       -4582|       -2831|       0|       -4814|       
-2582
RTD|       -4750|       -4585|       -2829|       0|       -4814|       
-2582
RTD|       -4782|       -4584|       -2751|       0|       -4814|       
-2582
RTD|       -4750|       -4584|       -2851|       0|       -4814|       
-2582
---|--param|----range-|--samples
HSD|    min|   4 -  5 |       41
---|--param|----range-|--samples
HSD|    avg|   2 -  3 |       60
HSD|    avg|   3 -  4 |      429
HSD|    avg|   4 -  5 |   416620
---|--param|----range-|--samples
HSD|    max|   2 -  3 |       30
HSD|    max|   3 -  4 |       11
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        41|      4.000|      0.000
HSS|    avg|    417109|      3.999|      0.040
HSS|    max|        41|      2.268|      0.449
---|------------|------------|------------|--------|-------------------------
RTS|       -4814|       -4583|       -2582|       0|    00:02:00/00:02:00


This was run on a pentium-M laptop,
with cpu-clock running at 600 MHz, (capable of 1.7 GHz)
I presume this might explain the negative latancies.
Im aware this is un-supported ..

The only thing that looks wrong is the test-duration.
I asked for 120 sec, it gave me 40 samples.
The test did take 120 to run.


heres config, info, and -t1 and -t2 runs:


[jimc@domain.hid bin]$ xeno-info
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux harpo.jimc.earth 2.6.15.1-ipipe-103-sony #2 Thu Feb 2 14:50:16 MST 
2006 i686 i686 i386 GNU/Linux

Gnu C                  4.0.2
Gnu make               3.80
util-linux             2.12p
mount                  2.12p
module-init-tools      3.1
e2fsprogs              1.38
pcmcia-cs              3.2.8
PPP                    2.4.2
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Procps                 3.2.5
Net-tools              1.60
Kbd                    1.12
Sh-utils               5.2.1
Modules Loaded         snd_seq_midi snd_rawmidi radeon sonypi nfsd 
exportfs lockd sunrpc ipv6 autofs4 eeprom pcmcia ipt_REJECT ipt_LOG 
ipt_state ip_conntrack iptable_filter ip_tables isofs zlib_inflate loop 
vfat fat video container button battery asus_acpi ac ohci1394 ieee1394 
yenta_socket rsrc_nonstatic pl2303 usbserial pcmcia_core uhci_hcd 
ohci_hcd ehci_hcd intel_agp shpchp i2c_i801 i2c_core snd_intel8x0m 
snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss 
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss 
snd_pcm snd_timer snd soundcore snd_page_alloc ipw2200 ieee80211 hostap 
ieee80211_crypt e1000 joydev ext3 jbd


[jimc@domain.hid bin]$ xeno-config
xeno-config --verbose
    --version="2.0.92"
    --cc="gcc"
    --arch="i386"
    --prefix="/usr/xenomai"
    --xeno-cflags="-I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE 
-D_REENTRANT -D__XENO__ -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing"
    --xeno-ldflags="-L/usr/xenomai/lib -lpthread "
    --posix-cflags="-I. -I/usr/xenomai/include 
-I/usr/xenomai/include/posix -O2 -D_GNU_SOURCE -D_REENTRANT -D__XENO__ 
-Wall -pipe -fstrict-aliasing -Wno-strict-aliasing"
    --posix-ldflags="-L/usr/xenomai/lib -lpthread_rt -lpthread -lrt "
    --uvm-cflags="-I. -I/usr/xenomai/include -O2 -D_GNU_SOURCE 
-D_REENTRANT -D__XENO__ -Wall -pipe -fstrict-aliasing 
-Wno-strict-aliasing -D__XENO_UVM__ "
    --uvm-ldflags="-u__xeno_skin_init -L/usr/xenomai/lib -luvm -lnucleus 
-lpthread"
    --library-dir="/usr/xenomai/lib"
Usage xeno-config OPTIONS
Options :
        --help
        --v,--verbose
        --version
        --cc
        --arch
        --prefix
        --xeno-cflags
        --xeno-ldflags
        --posix-cflags
        --posix-ldflags
        --uvm-cflags
        --uvm-ldflags
        --lib*-dir,--libdir,--user-libdir


[jimc@domain.hid latency]$ sudo ./run -- -T 60 -h -t 1
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel periodic task
warming up...
RTT|  00:00:05  (in-kernel periodic task, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|       -5331|       -5171|       -4688|       0|       -5331|       
-4688
RTD|       -5331|       -5166|       -3350|       0|       -5331|       
-3350
RTD|       -5330|       -5169|       -3467|       0|       -5331|       
-3350
RTD|       -5331|       -5169|       -3265|       0|       -5331|       
-3265
RTD|       -5331|       -5170|       -3396|       0|       -5331|       
-3265
RTD|       -5331|       -5170|       -3530|       0|       -5331|       
-3265
RTD|       -5331|       -5171|       -3440|       0|       -5331|       
-3265
RTD|       -5331|       -5171|       -3511|       0|       -5331|       
-3265
RTD|       -5331|       -5172|       -3389|       0|       -5331|       
-3265
RTD|       -5330|       -5171|       -3801|       0|       -5331|       
-3265
RTD|       -5331|       -5171|       -3316|       0|       -5331|       
-3265
RTD|       -5331|       -5171|       -4631|       0|       -5331|       
-3265
RTD|       -5330|       -5169|       -3481|       0|       -5331|       
-3265
RTD|       -5331|       -5171|       -3419|       0|       -5331|       
-3265
RTD|       -5331|       -5169|       -3357|       0|       -5331|       
-3265
RTD|       -5331|       -5147|       -3027|       0|       -5331|       
-3027
RTD|       -5331|       -5141|       -3361|       0|       -5331|       
-3027
RTD|       -5331|       -5170|       -4652|       0|       -5331|       
-3027
RTD|       -5331|       -5168|       -3354|       0|       -5331|       
-3027
RTD|       -5330|       -5147|       -3117|       0|       -5331|       
-3027
---|--param|----range-|--samples
HSD|    min|   5 -  6 |       20
---|--param|----range-|--samples
HSD|    avg|   3 -  4 |       91
HSD|    avg|   4 -  5 |     6194
HSD|    avg|   5 -  6 |   199025
---|--param|----range-|--samples
HSD|    max|   3 -  4 |       17
HSD|    max|   4 -  5 |        3
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        20|      5.000|      0.000
HSS|    avg|    205310|      4.969|      0.176
HSS|    max|        20|      3.150|      0.366
---|------------|------------|------------|--------|-------------------------
RTS|       -5331|       -5166|       -3027|       0|    00:01:00/00:01:00


[jimc@domain.hid latency]$ sudo ./run -- -T 60 -h -t 2
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel timer handler
warming up...
RTT|  00:00:05  (in-kernel timer handler, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|       -6502|       -6357|       -6146|       0|       -6502|       
-6146
RTD|       -6498|       -6357|       -6032|       0|       -6502|       
-6032
RTD|       -6503|       -6356|       -6133|       0|       -6503|       
-6032
RTD|       -6503|       -6357|       -6084|       0|       -6503|       
-6032
RTD|       -6504|       -6357|       -6140|       0|       -6504|       
-6032
RTD|       -6502|       -6357|       -6134|       0|       -6504|       
-6032
RTD|       -6501|       -6357|       -6031|       0|       -6504|       
-6031
RTD|       -6504|       -6357|       -6133|       0|       -6504|       
-6031
RTD|       -6502|       -6357|       -6144|       0|       -6504|       
-6031
RTD|       -6502|       -6356|       -6149|       0|       -6504|       
-6031
RTD|       -6501|       -6356|       -6128|       0|       -6504|       
-6031
RTD|       -6502|       -6356|       -6133|       0|       -6504|       
-6031
RTD|       -6504|       -6357|       -6112|       0|       -6504|       
-6031
RTD|       -6502|       -6357|       -6108|       0|       -6504|       
-6031
RTD|       -6503|       -6356|       -6159|       0|       -6504|       
-6031
RTD|       -6502|       -6357|       -5939|       0|       -6504|       
-5939
RTD|       -6503|       -6356|       -6112|       0|       -6504|       
-5939
RTD|       -6502|       -6357|       -6146|       0|       -6504|       
-5939
RTD|       -6499|       -6357|       -6156|       0|       -6504|       
-5939
RTD|       -6498|       -6357|       -6160|       0|       -6504|       
-5939
---|--param|----range-|--samples
HSD|    min|   6 -  7 |       20
---|--param|----range-|--samples
HSD|    avg|   5 -  6 |        1
HSD|    avg|   6 -  7 |   205310
---|--param|----range-|--samples
HSD|    max|   5 -  6 |        1
HSD|    max|   6 -  7 |       19
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        20|      6.000|      0.000
HSS|    avg|    205311|      6.000|      0.002
HSS|    max|        20|      5.950|      0.224
---|------------|------------|------------|--------|-------------------------
RTS|       -6504|       -6356|       -5939|       0|    00:01:00/00:01:00
[jimc@domain.hid latency]$


hope this is usefull

Re: [Xenomai-core] some results on my laptop

[Philippe Gerum]

Hi Jim,

Jim Cromie wrote:
> 
> some random sucesses ..
> 
> Ive been running an ipipe kernel as the default since shortly after 1/7.
> Since then, Ive had a couple of freezes on boot,
> and sometimes bash's auto-complete takes longer to complete,

Eh? Maybe the CONFIG_PCI_MSI syndrom again?

> but other than that, things have been solid.
>
> But that kernel wasnt configured using scripts/prepare-kernel.sh,
> so was missing the xeno_* modules.
> 

<snip>

> RTS|       -4814|       -4583|       -2582|       0|    00:02:00/00:02:00
> 
> 
> This was run on a pentium-M laptop,
> with cpu-clock running at 600 MHz, (capable of 1.7 GHz)
> I presume this might explain the negative latancies.
> Im aware this is un-supported ..
> 

The negative values are just there because even at 600Mhz, the timing anticipation 
applied by the nucleus to compensate for the intrinsic latency of the box is too 
high; i.e. the nucleus performs a bit too well latency-wise, so the anticipated 
timer ticks end up being a bit early on schedule. IOW, all is fine. Given the 
figures above, you could probably reduce the anticipation factor by setting the 
CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 nanoseconds 
(the default null value tells the nucleus to use the pre-calibrated value, which 
might be higher than this for your setup).

Btw, I'm not sure if you enabled the local APIC in your kernel config; if you did 
not, you should: there is no reason to keep using the braindamage 8254 PIT when a 
LAPIC is available with your CPU.

> The only thing that looks wrong is the test-duration.
> I asked for 120 sec, it gave me 40 samples.
> The test did take 120 to run.
> 

You should disable the ACPI support if enabled, and especially everything related 
to the CPUfreq scaling and power suspend.

-- 

Philippe.

Re: [Xenomai-core] some results on my laptop

[Jim Cromie]

Philippe Gerum wrote:
>
>>
>> Ive been running an ipipe kernel as the default since shortly after 1/7.
>> Since then, Ive had a couple of freezes on boot,
>> and sometimes bash's auto-complete takes longer to complete,
>
> Eh? Maybe the CONFIG_PCI_MSI syndrom again?

Um, does this tell you anything ?

$ zcat /proc/config.gz | grep PCI_MSI
# CONFIG_PCI_MSI is not set

I noticed the slow completion when doing some heavy disk stuff,
lndir on a kernel tree, and probably diff -r on 2 kernel trees,
so the laptop was pretty busy.


>>
>> This was run on a pentium-M laptop,
>> with cpu-clock running at 600 MHz, (capable of 1.7 GHz)
>> I presume this might explain the negative latancies.
>> Im aware this is un-supported ..
>>
>
> The negative values are just there because even at 600Mhz, the timing 
> anticipation applied by the nucleus to compensate for the intrinsic 
> latency of the box is too high; i.e. the nucleus performs a bit too 
> well latency-wise, so the anticipated timer ticks end up being a bit 
> early on schedule. IOW, all is fine. Given the figures above, you 
> could probably reduce the anticipation factor by setting the 
> CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 
> nanoseconds (the default null value tells the nucleus to use the 
> pre-calibrated value, which might be higher than this for your setup).
>
Ok.  
with latencies == 0, calibration happens at runtime, so it would
reflect the current workload (and with cpufreq on) also would reflect
the current clock frequency, correct ?


> Btw, I'm not sure if you enabled the local APIC in your kernel config; 
> if you did not, you should: there is no reason to keep using the 
> braindamage 8254 PIT when a LAPIC is available with your CPU.
>
Ok, now running this.

zcat /proc/config.gz | grep APIC
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

[jimc@domain.hid latency]$ sudo ./run -- -T60 -s -t1
Password:
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 100 us
== Test mode: in-kernel periodic task
warming up...
RTT|  00:00:05  (in-kernel periodic task, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
worst
RTD|       -2165|      127216|     1399358|    7582|       -2165|     
1399358
RTD|       -2188|     -205817|     1403255|   16431|       -2188|     
1403255
RTD|       -2178|     -207605|     1399828|   25271|       -2188|     
1403255
RTD|       -2186|     -208602|     1402253|   34096|       -2188|     
1403255
RTD|       -2163|     -206835|     1399144|   42943|       -2188|     
1403255
RTD|       -2175|     -206848|     1401346|   51785|       -2188|     
1403255
RTD|       -2184|     -210270|     1396823|   60621|       -2188|     
1403255
RTD|       -2167|     -208781|     1399323|   69453|       -2188|     
1403255
RTD|       -2169|     -211121|     1397365|   78267|       -2188|     
1403255
RTD|       -2173|     -210119|     1398349|   87084|       -2188|     
1403255
RTD|       -2168|     -208425|     1400764|   95922|       -2188|     
1403255
RTD|       -2173|      211271|     1397470|  104678|       -2188|     
1403255
RTD|       -2170|     -208130|     1399794|  113508|       -2188|     
1403255
RTD|       -2161|     -208400|     1397968|  122334|       -2188|     
1403255
RTD|       -2162|     -211225|     1397581|  131139|       -2188|     
1403255
RTD|       -2175|     -210500|     1397274|  139951|       -2188|     
1403255
RTD|       -2179|     -207530|     1396890|  148781|       -2188|     
1403255
RTD|       -2178|     -207890|     1399275|  157611|       -2188|     
1403255
RTD|       -2172|     -207750|     1397386|  166432|       -2188|     
1403255
RTD|       -2175|     -206057|     1399763|  175260|       -2188|     
1403255
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        20|      2.000|      0.000
HSS|    avg|    205060|     90.399|     25.538
HSS|    max|        20|     99.000|      0.000
---|------------|------------|------------|--------|-------------------------
RTS|       -2188|     -170670|     1403255|  175260|    00:01:00/00:01:00


Obviously, the numbers dont look so good.
The test duration comments still apply.

> You should disable the ACPI support if enabled, and especially 
> everything related to the CPUfreq scaling and power suspend.
>
Given that Im not really developing any RT code,
and I like the laptop quiet and cool, Im inclined to keep
the CPUfreq scaling on, at least for my everyday kernel.
How much does CPUfreq invalidate results I might send (periodically)


thanks

Re: [Xenomai-core] some results on my laptop

[Philippe Gerum]

Jim Cromie wrote:
> Philippe Gerum wrote:
> 
>>
>>>
>>> Ive been running an ipipe kernel as the default since shortly after 1/7.
>>> Since then, Ive had a couple of freezes on boot,
>>> and sometimes bash's auto-complete takes longer to complete,
>>
>>
>> Eh? Maybe the CONFIG_PCI_MSI syndrom again?
> 
> 
> Um, does this tell you anything ?
> 
> $ zcat /proc/config.gz | grep PCI_MSI
> # CONFIG_PCI_MSI is not set
> 
> I noticed the slow completion when doing some heavy disk stuff,
> lndir on a kernel tree, and probably diff -r on 2 kernel trees,
> so the laptop was pretty busy.
> 
> 
>>>
>>> This was run on a pentium-M laptop,
>>> with cpu-clock running at 600 MHz, (capable of 1.7 GHz)
>>> I presume this might explain the negative latancies.
>>> Im aware this is un-supported ..
>>>
>>
>> The negative values are just there because even at 600Mhz, the timing 
>> anticipation applied by the nucleus to compensate for the intrinsic 
>> latency of the box is too high; i.e. the nucleus performs a bit too 
>> well latency-wise, so the anticipated timer ticks end up being a bit 
>> early on schedule. IOW, all is fine. Given the figures above, you 
>> could probably reduce the anticipation factor by setting the 
>> CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500 
>> nanoseconds (the default null value tells the nucleus to use the 
>> pre-calibrated value, which might be higher than this for your setup).
>>
> Ok.  with latencies == 0, calibration happens at runtime, so it would
> reflect the current workload (and with cpufreq on) also would reflect
> the current clock frequency, correct ?
> 

With latency == 0, a pre-calibrated latency value is extracted from 
asm-i386/calibration.h.

> 
>> Btw, I'm not sure if you enabled the local APIC in your kernel config; 
>> if you did not, you should: there is no reason to keep using the 
>> braindamage 8254 PIT when a LAPIC is available with your CPU.
>>
> Ok, now running this.
> 
> zcat /proc/config.gz | grep APIC
> CONFIG_X86_GOOD_APIC=y
> CONFIG_X86_UP_APIC=y
> CONFIG_X86_UP_IOAPIC=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> 
> [jimc@domain.hid latency]$ sudo ./run -- -T60 -s -t1
> Password:
> *
> *
> * Type ^C to stop this application.
> *
> *
> == Sampling period: 100 us
> == Test mode: in-kernel periodic task
> warming up...
> RTT|  00:00:05  (in-kernel periodic task, 100 us period)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat 
> worst
> RTD|       -2165|      127216|     1399358|    7582|       -2165|     
> 1399358

ACPI is still on, it seems. ACPI, and PM must be off. They are responsible for 
hw-generated latencies. Additionally, you may want to switch on the "SMI disable" 
option from the Xeno config, to see if things improve.

> RTD|       -2188|     -205817|     1403255|   16431|       -2188|     
> 1403255
> RTD|       -2178|     -207605|     1399828|   25271|       -2188|     
> 1403255
> RTD|       -2186|     -208602|     1402253|   34096|       -2188|     
> 1403255
> RTD|       -2163|     -206835|     1399144|   42943|       -2188|     
> 1403255
> RTD|       -2175|     -206848|     1401346|   51785|       -2188|     
> 1403255
> RTD|       -2184|     -210270|     1396823|   60621|       -2188|     
> 1403255
> RTD|       -2167|     -208781|     1399323|   69453|       -2188|     
> 1403255
> RTD|       -2169|     -211121|     1397365|   78267|       -2188|     
> 1403255
> RTD|       -2173|     -210119|     1398349|   87084|       -2188|     
> 1403255
> RTD|       -2168|     -208425|     1400764|   95922|       -2188|     
> 1403255
> RTD|       -2173|      211271|     1397470|  104678|       -2188|     
> 1403255
> RTD|       -2170|     -208130|     1399794|  113508|       -2188|     
> 1403255
> RTD|       -2161|     -208400|     1397968|  122334|       -2188|     
> 1403255
> RTD|       -2162|     -211225|     1397581|  131139|       -2188|     
> 1403255
> RTD|       -2175|     -210500|     1397274|  139951|       -2188|     
> 1403255
> RTD|       -2179|     -207530|     1396890|  148781|       -2188|     
> 1403255
> RTD|       -2178|     -207890|     1399275|  157611|       -2188|     
> 1403255
> RTD|       -2172|     -207750|     1397386|  166432|       -2188|     
> 1403255
> RTD|       -2175|     -206057|     1399763|  175260|       -2188|     
> 1403255
> HSH|--param|--samples-|--average--|---stddev--
> HSS|    min|        20|      2.000|      0.000
> HSS|    avg|    205060|     90.399|     25.538
> HSS|    max|        20|     99.000|      0.000
> ---|------------|------------|------------|--------|------------------------- 
> 
> RTS|       -2188|     -170670|     1403255|  175260|    00:01:00/00:01:00
> 
> 
> Obviously, the numbers dont look so good.
> The test duration comments still apply.
> 
>> You should disable the ACPI support if enabled, and especially 
>> everything related to the CPUfreq scaling and power suspend.
>>
> Given that Im not really developing any RT code,
> and I like the laptop quiet and cool, Im inclined to keep
> the CPUfreq scaling on, at least for my everyday kernel.
> How much does CPUfreq invalidate results I might send (periodically)
>

Well, it basically totally wrecks the timing...

> 
> thanks
> 


-- 

Philippe.

Re: [Xenomai-core] some results on my laptop

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jim Cromie wrote:
>> Philippe Gerum wrote:
>>
>>>
>>>>
>>>> Ive been running an ipipe kernel as the default since shortly after
>>>> 1/7.
>>>> Since then, Ive had a couple of freezes on boot,
>>>> and sometimes bash's auto-complete takes longer to complete,
>>>
>>>
>>> Eh? Maybe the CONFIG_PCI_MSI syndrom again?
>>
>>
>> Um, does this tell you anything ?
>>
>> $ zcat /proc/config.gz | grep PCI_MSI
>> # CONFIG_PCI_MSI is not set
>>
>> I noticed the slow completion when doing some heavy disk stuff,
>> lndir on a kernel tree, and probably diff -r on 2 kernel trees,
>> so the laptop was pretty busy.
>>
>>
>>>>
>>>> This was run on a pentium-M laptop,
>>>> with cpu-clock running at 600 MHz, (capable of 1.7 GHz)
>>>> I presume this might explain the negative latancies.
>>>> Im aware this is un-supported ..
>>>>
>>>
>>> The negative values are just there because even at 600Mhz, the timing
>>> anticipation applied by the nucleus to compensate for the intrinsic
>>> latency of the box is too high; i.e. the nucleus performs a bit too
>>> well latency-wise, so the anticipated timer ticks end up being a bit
>>> early on schedule. IOW, all is fine. Given the figures above, you
>>> could probably reduce the anticipation factor by setting the
>>> CONFIG_XENO_HW_SCHED_LATENCY (Machine menu) parameter to, say, 2500
>>> nanoseconds (the default null value tells the nucleus to use the
>>> pre-calibrated value, which might be higher than this for your setup).
>>>
>> Ok.  with latencies == 0, calibration happens at runtime, so it would
>> reflect the current workload (and with cpufreq on) also would reflect
>> the current clock frequency, correct ?
>>
> 
> With latency == 0, a pre-calibrated latency value is extracted from
> asm-i386/calibration.h.
> 
>>
>>> Btw, I'm not sure if you enabled the local APIC in your kernel
>>> config; if you did not, you should: there is no reason to keep using
>>> the braindamage 8254 PIT when a LAPIC is available with your CPU.
>>>
>> Ok, now running this.
>>
>> zcat /proc/config.gz | grep APIC
>> CONFIG_X86_GOOD_APIC=y
>> CONFIG_X86_UP_APIC=y
>> CONFIG_X86_UP_IOAPIC=y
>> CONFIG_X86_LOCAL_APIC=y
>> CONFIG_X86_IO_APIC=y
>>
>> [jimc@domain.hid latency]$ sudo ./run -- -T60 -s -t1
>> Password:
>> *
>> *
>> * Type ^C to stop this application.
>> *
>> *
>> == Sampling period: 100 us
>> == Test mode: in-kernel periodic task
>> warming up...
>> RTT|  00:00:05  (in-kernel periodic task, 100 us period)
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat
>> best|---lat worst
>> RTD|       -2165|      127216|     1399358|    7582|       -2165|    
>> 1399358
> 
> ACPI is still on, it seems. ACPI, and PM must be off. They are
> responsible for hw-generated latencies. Additionally, you may want to
> switch on the "SMI disable" option from the Xeno config, to see if
> things improve.

If you are on a Pentium-M system, SMI disable is a must.

> 
>> RTD|       -2188|     -205817|     1403255|   16431|       -2188|    
>> 1403255
>> RTD|       -2178|     -207605|     1399828|   25271|       -2188|    
>> 1403255
>> RTD|       -2186|     -208602|     1402253|   34096|       -2188|    
>> 1403255
>> RTD|       -2163|     -206835|     1399144|   42943|       -2188|    
>> 1403255
>> RTD|       -2175|     -206848|     1401346|   51785|       -2188|    
>> 1403255
>> RTD|       -2184|     -210270|     1396823|   60621|       -2188|    
>> 1403255
>> RTD|       -2167|     -208781|     1399323|   69453|       -2188|    
>> 1403255
>> RTD|       -2169|     -211121|     1397365|   78267|       -2188|    
>> 1403255
>> RTD|       -2173|     -210119|     1398349|   87084|       -2188|    
>> 1403255
>> RTD|       -2168|     -208425|     1400764|   95922|       -2188|    
>> 1403255
>> RTD|       -2173|      211271|     1397470|  104678|       -2188|    
>> 1403255
>> RTD|       -2170|     -208130|     1399794|  113508|       -2188|    
>> 1403255
>> RTD|       -2161|     -208400|     1397968|  122334|       -2188|    
>> 1403255
>> RTD|       -2162|     -211225|     1397581|  131139|       -2188|    
>> 1403255
>> RTD|       -2175|     -210500|     1397274|  139951|       -2188|    
>> 1403255
>> RTD|       -2179|     -207530|     1396890|  148781|       -2188|    
>> 1403255
>> RTD|       -2178|     -207890|     1399275|  157611|       -2188|    
>> 1403255
>> RTD|       -2172|     -207750|     1397386|  166432|       -2188|    
>> 1403255
>> RTD|       -2175|     -206057|     1399763|  175260|       -2188|    
>> 1403255
>> HSH|--param|--samples-|--average--|---stddev--
>> HSS|    min|        20|      2.000|      0.000
>> HSS|    avg|    205060|     90.399|     25.538
>> HSS|    max|        20|     99.000|      0.000
>> ---|------------|------------|------------|--------|-------------------------
>>
>> RTS|       -2188|     -170670|     1403255|  175260|    00:01:00/00:01:00
>>
>>
>> Obviously, the numbers dont look so good.
>> The test duration comments still apply.
>>
>>> You should disable the ACPI support if enabled, and especially
>>> everything related to the CPUfreq scaling and power suspend.
>>>
>> Given that Im not really developing any RT code,
>> and I like the laptop quiet and cool, Im inclined to keep
>> the CPUfreq scaling on, at least for my everyday kernel.
>> How much does CPUfreq invalidate results I might send (periodically)
>>
> 
> Well, it basically totally wrecks the timing...
> 

...and may also add further latencies with the system has to speed up
again. Anyway, there might be use-cases where power consumption is -
besides latency - also an important issue. I'm just thinking of our
smaller mobile robots where the power demand of the drives and the
controller are not that far apart as on the larger platforms.

What about other time sources on x86? Which systems already have HPET
these days, and does this source not suffer from frequency scaling? I
once read that HPET is quite easy to program, is this true? IOW, would
it be worth considering to add this to the HAL?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] some results on my laptop

[Jan Kiszka]

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

Jan Kiszka wrote:
> ...
> What about other time sources on x86? Which systems already have HPET
> these days, and does this source not suffer from frequency scaling? I
> once read that HPET is quite easy to program, is this true? IOW, would
> it be worth considering to add this to the HAL?

There are actually only few registers:

http://www.intel.com/hardwaredesign/hpetspec_1.pdf

Even a replacement for the TSC is available ("Main Counter"), but I
guess that some effort will be required to replace all direct usages of
rdtsc in the current Xenomai code, right?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] some results on my laptop

[Philippe Gerum]

Jan Kiszka wrote:
> Jan Kiszka wrote:
> 
>>...
>>What about other time sources on x86? Which systems already have HPET
>>these days, and does this source not suffer from frequency scaling? I
>>once read that HPET is quite easy to program, is this true? IOW, would
>>it be worth considering to add this to the HAL?
> 
> 
> There are actually only few registers:
> 
> http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> 
> Even a replacement for the TSC is available ("Main Counter"), but I
> guess that some effort will be required to replace all direct usages of
> rdtsc in the current Xenomai code, right?
>

There should not be any direct usage, at least into the generic code, since it is 
aimed at running over the event-driven simulator too. Actually, the same goes for 
the x86-specific code, since we do support using the 8254 as an alternative to the 
TSC.

> Jan
> 


-- 

Philippe.

Re: [Xenomai-core] some results on my laptop

[Anders Blomdell]

Jan Kiszka wrote:
> Jan Kiszka wrote:
> 
>>...
>>What about other time sources on x86? Which systems already have HPET
>>these days, and does this source not suffer from frequency scaling? I
>>once read that HPET is quite easy to program, is this true? IOW, would
>>it be worth considering to add this to the HAL?
> 
> 
> There are actually only few registers:
> 
> http://www.intel.com/hardwaredesign/hpetspec_1.pdf
> 
> Even a replacement for the TSC is available ("Main Counter"), but I
> guess that some effort will be required to replace all direct usages of
> rdtsc in the current Xenomai code, right?
And unfortunately they aren't guaranteed to survive S3 sleep, which laptops 
spend a lot of time in (around 50% when doing coantrol at 100 Hz).

-- 
Anders

Re: [Xenomai-core] some results on my laptop

[Jan Kiszka]

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

Anders Blomdell wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> ...
>>> What about other time sources on x86? Which systems already have HPET
>>> these days, and does this source not suffer from frequency scaling? I
>>> once read that HPET is quite easy to program, is this true? IOW, would
>>> it be worth considering to add this to the HAL?
>>
>>
>> There are actually only few registers:
>>
>> http://www.intel.com/hardwaredesign/hpetspec_1.pdf
>>
>> Even a replacement for the TSC is available ("Main Counter"), but I
>> guess that some effort will be required to replace all direct usages of
>> rdtsc in the current Xenomai code, right?
> And unfortunately they aren't guaranteed to survive S3 sleep, which
> laptops spend a lot of time in (around 50% when doing coantrol at 100 Hz).
> 

Great. Someone should go out and choke a few hardware developers again
for being that short-sighted. So the PM timer is the most robust one,
just a bit slow.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] some results on my laptop

[Anders Blomdell]

Jan Kiszka wrote:
> ...and may also add further latencies with the system has to speed up
> again. Anyway, there might be use-cases where power consumption is -
> besides latency - also an important issue. I'm just thinking of our
> smaller mobile robots where the power demand of the drives and the
> controller are not that far apart as on the larger platforms.
> 
> What about other time sources on x86? Which systems already have HPET
> these days, and does this source not suffer from frequency scaling? I
> once read that HPET is quite easy to program, is this true? IOW, would
> it be worth considering to add this to the HAL?
If it an computer with ACPI (which is very likely), one could use the PM Timer 
(3.579545 MHz) as the base system clock, and sync with TSC at every clockscaling 
and power events (the reason for that is that PM Timer reads  are quite slow 
(around 1 microsecond on the hardwares I have tested), so most timer stuff 
should go via TSC).

The advantage with this is that the system will keep accurate time even in the 
low power modes (when TSC is turned off). I have done a crude implementation of 
this on KURT (http://www.ittc.ku.edu/kurt/), and it is a workable solution

There are also good research/development oppurtunities in:

   1. scheduling ACPI wakeup from those low-power modes in such good
      time that all realtime requirements are met :-)
   2. scheduling of clockscaling changes to make minimum impact
      on realtime tasks

(For ACPI, see http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf)

-- 

Regards

Anders Blomdell

Re: [Xenomai-core] some results on my laptop

[Jan Kiszka]

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

Anders Blomdell wrote:
> Jan Kiszka wrote:
>> ...and may also add further latencies with the system has to speed up
>> again. Anyway, there might be use-cases where power consumption is -
>> besides latency - also an important issue. I'm just thinking of our
>> smaller mobile robots where the power demand of the drives and the
>> controller are not that far apart as on the larger platforms.
>>
>> What about other time sources on x86? Which systems already have HPET
>> these days, and does this source not suffer from frequency scaling? I
>> once read that HPET is quite easy to program, is this true? IOW, would
>> it be worth considering to add this to the HAL?
> If it an computer with ACPI (which is very likely), one could use the PM
> Timer (3.579545 MHz) as the base system clock, and sync with TSC at
> every clockscaling and power events (the reason for that is that PM
> Timer reads  are quite slow (around 1 microsecond on the hardwares I
> have tested), so most timer stuff should go via TSC).
> 
> The advantage with this is that the system will keep accurate time even
> in the low power modes (when TSC is turned off). I have done a crude
> implementation of this on KURT (http://www.ittc.ku.edu/kurt/), and it is
> a workable solution

Oh, KURT still exists? Appeared a bit unmaintained to me last time I
checked.

> 
> There are also good research/development oppurtunities in:
> 
>   1. scheduling ACPI wakeup from those low-power modes in such good
>      time that all realtime requirements are met :-)
>   2. scheduling of clockscaling changes to make minimum impact
>      on realtime tasks
> 
> (For ACPI, see http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf)
> 

Hmm, though likely feasible, this sounds like it requires some effort,
especially the infrastructure to access ACPI directly (I guess we would
still have to switch it off for Linux, wouldn't we?) and to set up the
power event hooks. How much code was involved in your KURT add-on? Can
you extract it as a patch to asses the required work? I'm not planing to
work on this, but if it is not too complicated, someone may once pick it
up and integrate it in Xenomai.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] some results on my laptop

[Anders Blomdell]

Jan Kiszka wrote:
> Anders Blomdell wrote:
> 
>>Jan Kiszka wrote:
>>
>>>...and may also add further latencies with the system has to speed up
>>>again. Anyway, there might be use-cases where power consumption is -
>>>besides latency - also an important issue. I'm just thinking of our
>>>smaller mobile robots where the power demand of the drives and the
>>>controller are not that far apart as on the larger platforms.
>>>
>>>What about other time sources on x86? Which systems already have HPET
>>>these days, and does this source not suffer from frequency scaling? I
>>>once read that HPET is quite easy to program, is this true? IOW, would
>>>it be worth considering to add this to the HAL?
>>
>>If it an computer with ACPI (which is very likely), one could use the PM
>>Timer (3.579545 MHz) as the base system clock, and sync with TSC at
>>every clockscaling and power events (the reason for that is that PM
>>Timer reads  are quite slow (around 1 microsecond on the hardwares I
>>have tested), so most timer stuff should go via TSC).
>>
>>The advantage with this is that the system will keep accurate time even
>>in the low power modes (when TSC is turned off). I have done a crude
>>implementation of this on KURT (http://www.ittc.ku.edu/kurt/), and it is
>>a workable solution
> 
> 
> Oh, KURT still exists? Appeared a bit unmaintained to me last time I
> checked.
Maintained, but results are unfortunately not propagated to their homepage. We 
are currently running a 2.6.12 version, which is (for our purposes) essentially 
is Ingo Molnars patches + microsecond timer resolution.

>>There are also good research/development oppurtunities in:
>>
>>  1. scheduling ACPI wakeup from those low-power modes in such good
>>     time that all realtime requirements are met :-)
>>  2. scheduling of clockscaling changes to make minimum impact
>>     on realtime tasks
>>
>>(For ACPI, see http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf)
>>
> 
> 
> Hmm, though likely feasible, this sounds like it requires some effort,
> especially the infrastructure to access ACPI directly (I guess we would
> still have to switch it off for Linux, wouldn't we?) and to set up the
> power event hooks. 
Or present our own virtual ACPI controller to Linux, and enforce our timing 
constraints while trying to keep power as low as Linux want us to.

> How much code was involved in your KURT add-on? Can
> you extract it as a patch to asses the required work? I'm not planing to
> work on this, but if it is not too complicated, someone may once pick it
> up and integrate it in Xenomai.
I guess this is approximately the patch (which always reads the PM Timer, which 
is not good for performance). It also does nothing to prevent Linux from doing 
Power management, the only thing it does, is to keep wall time and computer time 
in sync.

===================================================================
--- include/linux/mutime.h      (revision 1334)
+++ include/linux/mutime.h      (working copy)
@@ -144,6 +144,8 @@
          */
         atomic_t jiffies_intr;

+       time_standard_t volatile cycles_lost;
+        long cpu_khz;
         time_standard_t volatile cycles_at_last_jiffy;
         time_standard_t volatile cycles_at_next_jiffy;
         time_standard_t volatile cycles_at_last_wall_jiffy;
@@ -290,11 +292,13 @@
  #define utimespec_to_timespec(x,y) \
         utime_subjiffies_to_timespec ((x)->jiffies, (x)->subjiffies, y)

-static inline time_standard_t get_time_standard(void)
+extern time_standard_t get_time_standard(void);
+extern void sync_time_standard_to_acpi(long pm_timer);
+/*static inline time_standard_t get_time_standard(void)
  {
        return get_cycles();
  }
-
+*/
  /* Compares two timer values.  Returns:
   * -1 if timer1 is set for earlier than timer2.
   * 0 if timer1 and timer2 are set for the same time.
Index: Makefile
===================================================================
--- Makefile    (revision 1334)
+++ Makefile    (working copy)
@@ -1,7 +1,7 @@
  VERSION = 2
  PATCHLEVEL = 6
  SUBLEVEL = 12
-EXTRAVERSION = -RT-V0.7.50-04-utime
+EXTRAVERSION = -RT-V0.7.50-04-laptop
  NAME=Woozy Numbat

  # *DOCUMENTATION*
Index: drivers/utime/utime.c
===================================================================
--- drivers/utime/utime.c       (revision 1334)
+++ drivers/utime/utime.c       (working copy)
@@ -41,10 +41,14 @@
  #include <linux/utimedev.h>
  #include <asm/div64.h>
  #include <linux/seq_file.h>
+#include <linux/cpufreq.h>
+#include <acpi/acpi_bus.h>

  /* Standard kernel module header files */
  #include <linux/module.h> /* For doing modules */
  #include <linux/init.h> /* For doing kernel work */
+#define DEB(i) outb_p(1<<i, 0x378)
+static int switched = 0;

  #define __UTIME_DEBUG__
  #ifdef __UTIME_DEBUG__
@@ -162,7 +166,12 @@
   */
  static inline void internal_update_system_time(void)
  {
-       time_standard_t elapsed;
+        signed long long elapsed;
+       int n;
+       /* elapsed is signed to handle the case where
+        * get_time_standard() < utime_state.cycles_at_last_jiffy,
+        * which can happen when cpu frequency is changed
+        */

         /* Here's the part we care about.  We want to save the result
          * from the get_time_standard call into last_update.
@@ -175,7 +184,15 @@

         /* Have any jiffies elapsed since our last update?
          */
-       while (elapsed >= utime_state.time_standard_per_jiffy) {
+       n = 0;
+       while (elapsed > 0 &&
+              elapsed >= utime_state.time_standard_per_jiffy) {
+         n++;
+         outb_p(0x80, 0x378);
+         if (switched && elapsed < 0) {
+           printk("elapsed=%Ld %d\n", elapsed, n);
+           BUG();
+         }
                 utime_state.cycles_at_last_jiffy =
                         utime_state.cycles_at_next_jiffy;
                 utime_state.cycles_at_next_jiffy +=
@@ -183,6 +200,7 @@
                 elapsed -= utime_state.time_standard_per_jiffy;
                 atomic_inc(&utime_state.jiffies_intr);
                 jiffies_64++;
+          outb_p(0x40, 0x378);
         }

         /* Now calculate the new subjiffies with what's left in
@@ -228,7 +246,45 @@
         internal_update_system_time();
         write_sequnlock_irqrestore(&xtime_lock, flags);
  }
+
+static time_standard_t acpi_ts = 0;
+static long saved_pm_timer = 0;

+extern void sync_time_standard_to_acpi(long pm_timer)
+{
+  unsigned long flags;
+  DEB(1);
+  pm_timer = pm_timer & 0xffffff;
+  local_irq_save(flags);
+  if (acpi_ts == 0) {
+    acpi_ts += 0x1000000;
+  } else if (pm_timer < saved_pm_timer ) {
+    acpi_ts += 0x1000000;
+  }
+  saved_pm_timer = pm_timer;
+  local_irq_restore(flags);
+  DEB(2);
+}
+
+time_standard_t get_time_standard(void)
+{
+  time_standard_t result;
+  unsigned long flags;
+  u32 pm_timer;
+  static u32 t_old;
+  static time_standard_t ts = 0;
+
+  local_irq_save(flags);
+  pm_timer = inl(acpi_fadt.xpm_tmr_blk.address) & 0xffffff;
+  sync_time_standard_to_acpi(pm_timer);
+  result = acpi_ts + pm_timer;
+  local_irq_restore(flags);
+
+//  result = get_cycles() + utime_state.cycles_lost;
+
+  return result<<4;
+}
+
  void get_system_time(unsigned long *j, u32 *u)
  {
         unsigned long flags;
@@ -736,6 +792,7 @@

         unsigned long flags;

+       DEB(0);
         local_irq_save(flags);
         /* Clear the interrupt expected flag, before we go to
          * internal_program_next_event. This used to live in
@@ -767,18 +824,23 @@
                  * there is nothing to do, but this is left as a
                  * placeholder.
                  */
+               DEB(1);
                 orig_do_timer(regs);
                 atomic_dec(&utime_state.jiffies_intr);
+               DEB(2);
         }

         /*
          * Update system time and reprogram the timer chip for the
          * next event
          */
+       DEB(3);
         internal_update_system_time();

+       DEB(4);
         internal_program_next_event();

+       DEB(5);
         dotimer_active = 0;

         local_irq_restore(flags);
@@ -1020,6 +1082,7 @@
         unsigned long flags;

         printk("Calibrating UTIME \n");
+       utime_state.time_standard_per_sec = 3579545<<4;
         if (!utime_state.time_standard_per_sec) {
                 time_standard_t diff;
                 if (UTIME_TSC_HZ) {
@@ -1301,6 +1364,57 @@
  }
  EXPORT_SYMBOL(set_utime_state);

+/*
+ * CPU frequency scaling handler
+ */
+static inline time_standard_t
+utime_cpufreq_scale(time_standard_t old, u_int div, u_int mult)
+{
+  time_standard_t result = ((time_standard_t) old) * ((time_standard_t) mult);
+  do_div(result, div);
+  return result;
+};
+
+static int
+time_cpufreq_notifier(struct notifier_block *nb, unsigned long val, void *data)
+{
+  unsigned long flags;
+  struct cpufreq_freqs *freq = data;
+  static time_standard_t ref_per_sec = 0;
+  static time_standard_t ref_per_jiffy = 0;
+  static time_standard_t ref_per_subjiffy = 0;
+  static u_int ref_freq = 0;
+
+  printk("cpufreq val=%lx old=%d new=%d ref=%d\n",
+        val, freq->old, freq->new, ref_freq);
+  if (val == CPUFREQ_PRECHANGE) {
+    write_seqlock_irqsave(&xtime_lock, flags);
+    if (!ref_freq) {
+      ref_per_sec = utime_state.time_standard_per_sec;
+      ref_per_jiffy = utime_state.time_standard_per_jiffy;
+      ref_per_subjiffy = utime_state.time_standard_per_subjiffy;
+      ref_freq = freq->old;
+    }
+    if (ref_freq) {
+      utime_state.time_standard_per_sec =
+       utime_cpufreq_scale(ref_per_sec, ref_freq, freq->new);
+      utime_state.time_standard_per_jiffy =
+       utime_cpufreq_scale(ref_per_jiffy, ref_freq, freq->new);
+      utime_state.time_standard_per_subjiffy =
+       utime_cpufreq_scale(ref_per_subjiffy, ref_freq, freq->new);
+      calc_utime_quotient();
+      switched = 1;
+    }
+    write_sequnlock_irqrestore(&xtime_lock, flags);
+  }
+  printk("Done\n");
+  return 0;
+}
+
+static struct notifier_block time_cpufreq_notifier_block = {
+        .notifier_call  = time_cpufreq_notifier
+};
+
  /**
   * UTIME init code
   */
@@ -1358,6 +1472,8 @@

         change_timer_mode();
         write_sequnlock_irqrestore(&xtime_lock, flags);
+//     cpufreq_register_notifier(&time_cpufreq_notifier_block,
+//                               CPUFREQ_TRANSITION_NOTIFIER);
         printk(KERN_INFO "UTIME module loaded successfully\n");
         return 0;
  }
Index: drivers/acpi/processor_idle.c
===================================================================
--- drivers/acpi/processor_idle.c       (revision 1334)
+++ drivers/acpi/processor_idle.c       (working copy)
@@ -290,6 +290,7 @@
                 t2 = inl(acpi_fadt.xpm_tmr_blk.address);
                 /* Get end time (ticks) */
                 t2 = inl(acpi_fadt.xpm_tmr_blk.address);
+               sync_time_standard_to_acpi(t2);
                 /* Re-enable interrupts */
                 local_irq_enable();
                 /* Compute time (ticks) that we were actually asleep */
@@ -307,6 +308,7 @@
                 t2 = inl(acpi_fadt.xpm_tmr_blk.address);
                 /* Get end time (ticks) */
                 t2 = inl(acpi_fadt.xpm_tmr_blk.address);
+               sync_time_standard_to_acpi(t2);
                 /* Enable bus master arbitration */
                 acpi_set_register(ACPI_BITREG_ARB_DISABLE, 0, 
ACPI_MTX_DO_NOT_LOCK);
                 /* Re-enable interrupts */


-- 

Anders

Re: [Xenomai-core] some results on my laptop

[Jan Kiszka]

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

Anders Blomdell wrote:
> Jan Kiszka wrote:
>> Anders Blomdell wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> ...and may also add further latencies with the system has to speed up
>>>> again. Anyway, there might be use-cases where power consumption is -
>>>> besides latency - also an important issue. I'm just thinking of our
>>>> smaller mobile robots where the power demand of the drives and the
>>>> controller are not that far apart as on the larger platforms.
>>>>
>>>> What about other time sources on x86? Which systems already have HPET
>>>> these days, and does this source not suffer from frequency scaling? I
>>>> once read that HPET is quite easy to program, is this true? IOW, would
>>>> it be worth considering to add this to the HAL?
>>>
>>> If it an computer with ACPI (which is very likely), one could use the PM
>>> Timer (3.579545 MHz) as the base system clock, and sync with TSC at
>>> every clockscaling and power events (the reason for that is that PM
>>> Timer reads  are quite slow (around 1 microsecond on the hardwares I
>>> have tested), so most timer stuff should go via TSC).
>>>
>>> The advantage with this is that the system will keep accurate time even
>>> in the low power modes (when TSC is turned off). I have done a crude
>>> implementation of this on KURT (http://www.ittc.ku.edu/kurt/), and it is
>>> a workable solution
>>
>>
>> Oh, KURT still exists? Appeared a bit unmaintained to me last time I
>> checked.
> Maintained, but results are unfortunately not propagated to their
> homepage. We are currently running a 2.6.12 version, which is (for our
> purposes) essentially is Ingo Molnars patches + microsecond timer
> resolution.

But I guess you are then running a quite old version of the
RT-patch-set. Or is there still anything in the utime-patches (besides
your PM-add-on) that the hrtimer does not provide? Cannot imagine
because Thomas (Gleixner) was so deeply involved in KURT that he will
likely have extracted all relevant features for his hrtimers.

> 
>>> There are also good research/development oppurtunities in:
>>>
>>>  1. scheduling ACPI wakeup from those low-power modes in such good
>>>     time that all realtime requirements are met :-)
>>>  2. scheduling of clockscaling changes to make minimum impact
>>>     on realtime tasks
>>>
>>> (For ACPI, see http://www.acpi.info/DOWNLOADS/ACPIspec30a.pdf)
>>>
>>
>>
>> Hmm, though likely feasible, this sounds like it requires some effort,
>> especially the infrastructure to access ACPI directly (I guess we would
>> still have to switch it off for Linux, wouldn't we?) and to set up the
>> power event hooks. 
> Or present our own virtual ACPI controller to Linux, and enforce our
> timing constraints while trying to keep power as low as Linux want us to.

Hmm, sounds again like a lot of work - but it's attractive because it
would be clean. ;)

> 
>> How much code was involved in your KURT add-on? Can
>> you extract it as a patch to asses the required work? I'm not planing to
>> work on this, but if it is not too complicated, someone may once pick it
>> up and integrate it in Xenomai.
> I guess this is approximately the patch (which always reads the PM
> Timer, which is not good for performance). It also does nothing to
> prevent Linux from doing Power management, the only thing it does, is to
> keep wall time and computer time in sync.

Ah, these patches do not look that complicated. If I find some time to
study them, I may come up with further questions.

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]