Wolfgang Grandegger wrote: > ... > OK, now I have another strange behaviour when TDMA is loaded. With > rtnet, rt_3c59x/rt_mpc52xx_fec and rtcfg loaded I get: > > [EMAIL PROTECTED] modules]# 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=430.2 us > 64 bytes from 10.0.0.2: icmp_seq=2 time=408.4 us > 64 bytes from 10.0.0.2: icmp_seq=3 time=394.6 us > > and also the round-trip-test returns reasonable values: > > # showtime > Roundtrip = 413us (min: 413us, max: 413us) > Roundtrip = 339us (min: 339us, max: 413us) > Roundtrip = 349us (min: 339us, max: 413us) > > But with TDMA running (via "rtnet start") I get on the RTnet slave: > > Stage 1: searching for master...+/usr/realtime/sbin/rtcfg rteth0 > client -c > +/bin/sh -c > TDMACFG=/usr/realtime/sbin/tdmacfg;IPADDR=10.0.0.2;NETMASK_OPT=""; > $TDMACFG rteth0 slot 0 500;ifconfig vnic0 up $IPADDR $NETMASK_OPT
Mmh, this internal batch of commands should not be dumped to the screen. What shell do you use on your target box? standard or busybox bash? At least those two are tested and should work. Anyway, cosmetic effect. > TDMA: calibrated master-to-slave packet delay: 61557080 us (min/max: > 61309526/61 804640 us) > Well, this is alarming. Something goes wrong during the calibration, at least when printing the results. Could you capture the calibration phase on the slave with RTcap+tcpdump and send me the result? > > and then ping returns rather long delay and big fluctuations: > > [EMAIL PROTECTED] modules]# 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=5394.8 us > 64 bytes from 10.0.0.2: icmp_seq=2 time=9436.8 us > 64 bytes from 10.0.0.2: icmp_seq=3 time=8433.4 us > > I use TDMA_CYCLE=5000 and TDMA_OFFSET=500. Therefore a packet should be > sent every 5ms. > At least the three round-trips above are normal. Note that your ping is out of sync with the TDMA cycle, thus the ping request first have to wait up to a full cycle to get sent. And then the reply may also have to be defered on the target side (depends on the slot order of ping sender and receiver and on the time between the slots). Jan ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
