[Xenomai-help] help with xenomai configuration

[Xenomai-help] help with xenomai configuration

[henning.richter]

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



Hi,

I use a KUbuntu 8.10 with kernel 2.6.27.7, xenomai 2.4.6.1 and the latest
rtnet version.
I set up the EthercatMasterLibrary and send some Frames (size of ~1200
byte) cylical to my Beckhoff devices.
Measuring the time (via rt_read_timer-function of timer.h) handing the
frames over to the NIC last between 5 and 10 us. (its the low_level_send)
Measuring the time at the application layer is takes ~250 - 350 us. So I am
loosing quite a lot time in between.

Maybe there is sth. wrong with my xenomai configuration.
I run the 'xeno-test' (results below) but the test stop at generation load.

Henning

here are the results of xeno-test:

xeno-test: started
withBusybox is 0
xeno-test: running tests

Di 5. Mai 07:12:40 CEST 2009
running: ./xeno-config --verbose
xeno-config --verbose
--version="2.4.6.1"
--cc="gcc"
--arch="x86"
--prefix="/usr/xenomai"
--xeno-cflags="-I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT
-D__XENO__"
--xeno-ldflags="-L/usr/xenomai/lib -lpthread "
--posix-cflags="-I/usr/xenomai/include -I/usr/xenomai/include/posix
-D_GNU_SOURCE -D_REENTRANT -D__XENO__"
--posix-ldflags="-Wl,@/usr/xenomai/lib/posix.wrappers -L/usr/xenomai/lib
-lpthread_rt -lpthread -lrt "
--library-dir="/usr/xenomai/lib"

Di 5. Mai 07:12:40 CEST 2009
running: ./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 rd-ethercat 2.6.27.7-xe #1 SMP Wed Apr 29 12:00:19 CEST 2009 i686
GNU/Linux

Gnu C 4.3.2-1ubuntu12)
Gnu make 3.81
util-linux ng 2.14)
mount ng 2.14 (with libvolume_id and selinux support)
module-init-tools 3.3-pre11
e2fsprogs 1.41.3
Linux C Library 2.8.90
Dynamic linker (ldd) 2.8.90
Procps 3.2.7
Net-tools 1.60
Kbd 1.14.1
Sh-utils 6.10
Modules Loaded e100 rt_eepro100 rtpacket rtnet af_packet i915 drm bridge
stp bnep rfcomm sco l2cap bluetooth ppdev ipv6 iptable_filter ip_tables
x_tables parport_pc lp parport sr_mod cdrom isp1760 com20020_pci com20020
arcnet evdev serio_raw iTCO_wdt psmouse iTCO_vendor_support intel_agp
shpchp pci_hotplug agpgart ext3 jbd mbcache sd_mod crc_t10dif sg
usb_storage libusual ata_piix ata_generic libata mii uhci_hcd ehci_hcd
scsi_mod usbcore fuse

Di 5. Mai 07:12:41 CEST 2009
running: cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 9
model name : Mobile Genuine Intel(R) processor 1100MHz
stepping : 5
cpu MHz : 1099.881
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat
clflush dts acpi mmx fxsr sse sse2 tm pbe up bts est tm2
bogomips : 2199.76
clflush size : 64
power management:


Di 5. Mai 07:12:41 CEST 2009
running: md5sum /proc/cpuinfo # cpuinfo fingerprint
3f1cac044dfe9caf955d09d7612b905f /proc/cpuinfo
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_IPIPE=y
CONFIG_IPIPE_DOMAINS=4
CONFIG_IPIPE_COMPAT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PM is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_IPIPE_DEBUG is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set

Di 5. Mai 07:12:41 CEST 2009
running: cat /proc/ipipe/Linux
+----- Handling ([A]ccepted, [G]rabbed, [W]ired, [D]iscarded)
|+---- Sticky
||+--- Locked
|||+-- Exclusive
||||+- Virtual
[IRQ] |||||
0: A....
1: A....
2: A....
3: A.L..
4: A.L..
5: A....
6: A....
7: A....
8: A....
9: A....
10: A.L..
11: A.L..
12: A....
13: A....
14: A....
15: A....
16: A....
17: A....
18: A....
19: A....
20: A....
21: A....
22: A....
23: A....
24: A....
25: A....
26: A....
27: A....
28: A....
29: A....
30: A....
31: A....
32: A....
33: A....
34: A....
35: A....
36: A....
37: A....
38: A....
39: A....
40: A....
41: A....
42: A....
43: A....
44: A....
45: A....
46: A....
47: A....
48: A....
49: A....
50: A....
51: A....
52: A....
53: A....
54: A....
55: A....
56: A....
57: A....
58: A....
59: A....
60: A....
61: A....
62: A....
63: A....
64: A....
65: A....
66: A....
67: A....
68: A....
69: A....
70: A....
71: A....
72: A....
73: A....
74: A....
75: A....
76: A....
77: A....
78: A....
79: A....
80: A....
81: A....
82: A....
83: A....
84: A....
85: A....
86: A....
87: A....
88: A....
89: A....
90: A....
91: A....
92: A....
93: A....
94: A....
95: A....
96: A....
97: A....
98: A....
99: A....
100: A....
101: A....
102: A....
103: A....
104: A....
105: A....
106: A....
107: A....
108: A....
109: A....
110: A....
111: A....
112: A....
113: A....
114: A....
115: A....
116: A....
117: A....
118: A....
119: A....
120: A....
121: A....
122: A....
123: A....
124: A....
125: A....
126: A....
127: A....
128: A....
129: A....
130: A....
131: A....
132: A....
133: A....
134: A....
135: A....
136: A....
137: A....
138: A....
139: A....
140: A....
141: A....
142: A....
143: A....
144: A....
145: A....
146: A....
147: A....
148: A....
149: A....
150: A....
151: A....
152: A....
153: A....
154: A....
155: A....
156: A....
157: A....
158: A....
159: A....
160: A....
161: A....
162: A....
163: A....
164: A....
165: A....
166: A....
167: A....
168: A....
169: A....
170: A....
171: A....
172: A....
173: A....
174: A....
175: A....
176: A....
177: A....
178: A....
179: A....
180: A....
181: A....
182: A....
183: A....
184: A....
185: A....
186: A....
187: A....
188: A....
189: A....
190: A....
191: A....
192: A....
193: A....
194: A....
195: A....
196: A....
197: A....
198: A....
199: A....
200: A....
201: A....
202: A....
203: A....
204: A....
205: A....
206: A....
207: A....
208: A....
209: A....
210: A....
211: A....
212: A....
213: A....
214: A....
215: A....
216: A....
217: A....
218: A....
219: A....
220: A....
221: A....
222: A....
223: A....
224: A....
230: A....
231: A....
232: A....
233: A....
234: GS...
235: A....
236: A....
237: A....
238: A....
239: A....
240: A....
256: G...V
257: G...V
259: G...V
[Domain info]
id=0x00000000
priority=100

Di 5. Mai 07:12:41 CEST 2009
running: cat /proc/ipipe/Xenomai
+----- Handling ([A]ccepted, [G]rabbed, [W]ired, [D]iscarded)
|+---- Sticky
||+--- Locked
|||+-- Exclusive
||||+- Virtual
[IRQ] |||||
9: W..X.
230: W....
233: W..X.
234: GS...
258: W...V
[Domain info]
id=0x58454e4f
priority=topmost

Di 5. Mai 07:12:41 CEST 2009
running: cat /proc/ipipe/version
2.1-02

Di 5. Mai 07:12:41 CEST 2009
running: generate_loads 1
dd workload started, pids 5100 stored in /var/lock/xeno-test.4960.pids
5100 pts/2 00:00:00 dd
something died a 5100 or

[-- Attachment #2: Type: text/html, Size: 9412 bytes --]

Re: [Xenomai-help] help with xenomai configuration

[Gilles Chanteperdrix]

henning.richter@domain.hid wrote:
> 
> Hi,
> 
> I use a KUbuntu 8.10 with kernel 2.6.27.7, xenomai 2.4.6.1 and the latest
> rtnet version.
> I set up the EthercatMasterLibrary and send some Frames (size of ~1200
> byte) cylical to my Beckhoff devices.
> Measuring the time (via rt_read_timer-function of timer.h) handing the
> frames over to the NIC last between 5 and 10 us. (its the low_level_send)
> Measuring the time at the application layer is takes ~250 - 350 us. So I am
> loosing quite a lot time in between.
> 
> Maybe there is sth. wrong with my xenomai configuration.
> I run the 'xeno-test' (results below) but the test stop at generation load.

Yes, xeno-test has a known issue when run without bash, and ubuntu no
longer uses bash by default. So, try running xeno-test with bash.

Alternatively, you can run the latency test directly. Preferably using
the same period as the problematic one with EML.

-- 
                                                 Gilles.

Re: [Xenomai-help] help with xenomai configuration

[Philippe Gerum]

On Tue, 2009-05-05 at 15:23 +0200, Gilles Chanteperdrix wrote:
> henning.richter@domain.hid wrote:
> > 
> > Hi,
> > 
> > I use a KUbuntu 8.10 with kernel 2.6.27.7, xenomai 2.4.6.1 and the latest
> > rtnet version.
> > I set up the EthercatMasterLibrary and send some Frames (size of ~1200
> > byte) cylical to my Beckhoff devices.
> > Measuring the time (via rt_read_timer-function of timer.h) handing the
> > frames over to the NIC last between 5 and 10 us. (its the low_level_send)
> > Measuring the time at the application layer is takes ~250 - 350 us. So I am
> > loosing quite a lot time in between.
> > 
> > Maybe there is sth. wrong with my xenomai configuration.
> > I run the 'xeno-test' (results below) but the test stop at generation load.
> 
> Yes, xeno-test has a known issue when run without bash, and ubuntu no
> longer uses bash by default. So, try running xeno-test with bash.
> 

Gilles, we have an ongoing series of recurring issues with xeno-test
that pleads for a reshuffle. I would really like to see something
simpler in there, which may not cover all aspects that xeno-test
currently addresses, but which would at least work for all setups, and
particularly embedded ones.

We should rather see xeno-test as a simple validation tool to dig out
most common latency issues due to bad kernel settings. Further
validation via long running stress tests would be better accomplished
via the LTP-based suite we use internally to validate ports, within
standalone mini-rootfs; maybe at some point we could provide those
pre-built rootfs for download, for that particular purpose.

> Alternatively, you can run the latency test directly. Preferably using
> the same period as the problematic one with EML.
> 
-- 
Philippe.

Re: [Xenomai-help] help with xenomai configuration

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Tue, 2009-05-05 at 15:23 +0200, Gilles Chanteperdrix wrote:
>> henning.richter@domain.hid wrote:
>>> Hi,
>>>
>>> I use a KUbuntu 8.10 with kernel 2.6.27.7, xenomai 2.4.6.1 and the latest
>>> rtnet version.
>>> I set up the EthercatMasterLibrary and send some Frames (size of ~1200
>>> byte) cylical to my Beckhoff devices.
>>> Measuring the time (via rt_read_timer-function of timer.h) handing the
>>> frames over to the NIC last between 5 and 10 us. (its the low_level_send)
>>> Measuring the time at the application layer is takes ~250 - 350 us. So I am
>>> loosing quite a lot time in between.
>>>
>>> Maybe there is sth. wrong with my xenomai configuration.
>>> I run the 'xeno-test' (results below) but the test stop at generation load.
>> Yes, xeno-test has a known issue when run without bash, and ubuntu no
>> longer uses bash by default. So, try running xeno-test with bash.
>>
> 
> Gilles, we have an ongoing series of recurring issues with xeno-test
> that pleads for a reshuffle. I would really like to see something
> simpler in there, which may not cover all aspects that xeno-test
> currently addresses, but which would at least work for all setups, and
> particularly embedded ones.

Yes, I am ok. These issues with xeno-test are annoying.

> We should rather see xeno-test as a simple validation tool to dig out
> most common latency issues due to bad kernel settings. Further
> validation via long running stress tests would be better accomplished
> via the LTP-based suite we use internally to validate ports, within
> standalone mini-rootfs; maybe at some point we could provide those
> pre-built rootfs for download, for that particular purpose.

Yes, Ok too.

> 
>> Alternatively, you can run the latency test directly. Preferably using
>> the same period as the problematic one with EML.
>>


-- 
                                                 Gilles.