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? > > 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. > 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? 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! > I am using the last svn version (21.3). > > Jochen > > Jan
signature.asc
Description: OpenPGP digital signature
