Hello
matrix_df hotmail wrote:
> Hello Jan
>
> I have encountered several problems:
>
> 1) when you restart rtnet with (sbin/rtnet stop and sbin/rtnet start),
> each time you get one "ifup" more which makes cpu load.
>
> ##################################################################
> Cpu(s): 43.4% us, 56.6% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi,
> 0.0% si
> Mem: 256140k total, 242716k used, 13424k free, 3616k buffers
> Swap: 514072k total, 104k used, 513968k free, 82516k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 26354 root 20 -5 11580 8652 1128 R 7.3 3.4 0:13.51 ifup
> 21523 root 20 -5 13776 10m 1128 R 6.6 4.2 0:22.61 ifup
> 7277 root 20 -5 0 0 0 Z 2.0 0.0 0:00.06 ifup
<defunct>
> ##################################################################
Hmm, is that ifup hooked on some vnic or on a rtcap stub (is rtcap
switched on?)? Do you start them, or is some automatic interface
detection of your distribution running? Can you kill the processes?
Ok, I checked this, it seem that linux (centos) tries to load the driver for
the unloaded ethernet
card used by rtnet.
[EMAIL PROTECTED] rtnet]# ps -Af |grep ifup
root 29472 29462 14 01:36 ? 00:01:07 /bin/bash /sbin/ifup
/etc/syscon
fig/network-scripts/ifcfg-eth2
root 14805 29472 0 01:44 ? 00:00:00 /bin/bash /sbin/ifup
/etc/syscon
fig/network-scripts/ifcfg-eth2
This seems to be happen each time you stop and start rtnet.
Is there a known solution for this?
>
> 2) ping is really bad:
> ##################################################################
> [EMAIL PROTECTED] rtnet]# sbin/rtping 10.0.0.2
> Real-time PING 10.0.0.2 56(84) bytes of data.
> 64 bytes from 10.0.0.2: icmp_seq=1 time=2457.3 us
> 64 bytes from 10.0.0.2: icmp_seq=2 time=2490.0 us
> 64 bytes from 10.0.0.2: icmp_seq=3 time=2550.3 us
> ...
> --- 10.0.0.2 rtping statistics ---
> 41 packets transmitted, 41 received, 0% packet loss
> worst case rtt = 5264.1 us
> #########################################################
>
Real-time doesn't mean real fast. What you see here is the effect of
cyclic transmission in well defined timeslots. With the default setup,
you have a 5 ms period, and the worst case goes up to
period+slot_offset+some_jitter in case a ping reply is guaranteed for
the same cycle (i.e. the time between request and reply slot is
sufficient like here). When you need more responsiveness, lower the period.
The precise optimal period and time slot layout heavily depends on your
(RT-)application traffic characteristics. Once you know them, you can
start tuning the default setup.
Ok, this sound logical.
It looks so odd, that the response time differs that much from 270 to 5167
us.
But this cyclic transmission in well definied timeslots could be the answer.
Perhaps I should take a look into the source code of rtping to get an idea
how the response time
is stopped.
64 bytes from 10.0.0.2: icmp_seq=63 time=386.4 us
64 bytes from 10.0.0.2: icmp_seq=64 time=326.9 us
64 bytes from 10.0.0.2: icmp_seq=65 time=269.9 us
64 bytes from 10.0.0.2: icmp_seq=66 time=5167.7 us
64 bytes from 10.0.0.2: icmp_seq=67 time=5138.4 us
64 bytes from 10.0.0.2: icmp_seq=68 time=5091.4 us
> 3) just to check this:
> the e100.ko module is also loaded when rtnet loads rt_eepro100
> is this normal?
>
> tdma 16004 1
> rtmac 9120 1 tdma
> rtcfg 40000 0
> rt_loopback 2692 1
> rt_eepro100 17032 2
> rtpacket 4608 0
> rtipv4 22240 1 rtcfg
> rtnet 30840 7
> tdma,rtmac,rtcfg,rt_loopback,rt_eepro100,rtpacket,rtipv4
> e100 36612 0
> rtai_rtdm 17316 6
> tdma,rtcfg,rt_eepro100,rtpacket,rtipv4,rtnet
> rtai_sem 16000 4 tdma,rtcfg,rtnet,rtai_rtdm
> rtai_lxrt 74824 8
> tdma,rtcfg,rt_loopback,rt_eepro100,rtipv4,rtnet,rtai_rtdm,rtai_sem
> rtai_hal 30072 6
> rtmac,rt_eepro100,rtnet,rtai_rtdm,rtai_sem,rtai_lxrt
> r128 41984 1
> parport_pc 24388 1
> lp 10568 0
> parport 31048 2 parport_pc,lp
> epic100 17796 0
> mii 4992 2 e100,epic100
> tulip 47264 0
> floppy 55876 0
>
Do you remove that driver before starting RTnet?
Yes, always.
Or does the distribution try to bring up some interface automatically and
reloads
the module? It's strange that e100 and rt_eepro100 when being loaded in
this order doesn't compete for the NIC PCI interface. Actually, this
shouldn't work!
Yes, it seem that the linux system loads this driver, see answer one also.
Jochen
> I am using the last svn version (21.3).
>
> Jochen
>
>
Jan
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
