Leonardo Pappagallo wrote: > Hi all, > > I have linux kernel 2.6.8.1, RTAI 3.1 and rtnet 0.8.3. > > I try to realize a network with 3 pc, 1 master that sends packets to > slaves in broadcast mode and 2 slaves that trasmit packets in two > slots. > The configuration file rtnet.conf is: > > # Primary master > master: > ip 192.0.0.241 > cycle 600 > slot 0 0 > > # Slave A > slave: > ip 192.0.0.235 > slot 0 100 > > # Slave B > slave: > ip 192.0.0.244 > slot 0 120 > > my machines are: > master : PIII 450Mhz > slaveA: PIII 533Mhz > slaveB: PMobile 1600Mhz > > UDP packet size is 15byte, then a frame sends to channel has a size of 64byte. > The time to send a frame is approximately 6us about 100Mb ethernet.
Note that those 6 us is the pure time on the cable and does not include any hardware and (foremost) software related delays. If you want some real numbers of typical round trip times, switch off RTmac/TDMA for a while and do a rtping e.g. This is important in order to schedule enough time (=slot offset) between the arrival of the master's packet and the time the slave are intended to reply. Put some load on your systems during this test to reach worst-case regions. > > When the systems run i have noticed that the first packet is delayed > and the steady state is reached only after some cycles (6000us to > slaveA, 3000us to slaveB). > > sequence of the transmission about channel is: > > time event > 0 SOF > 19us Master send a broadcast UDP packet 00, side of 15byte > 600us SOF > 1200us SOF > 1800us SOF > 2400us SOF > 3000us SOF > 3150us SlaveB responds with a UDP packet > 3600us SOF > 4200us SOF > 4800us SOF > 5400us SOF > 6000us SOF > 6120us SlaveA responds with a UDP packet > 6600us SOF > 6620us Master sends UDP packet 01 > 6700us SlaveA responds with a UDP packet > 6720us SlaveB responds with a UDP packet > 7200us SOF > 7220us Master sends UDP packet 02 > 7300us SlaveA responds with a UDP packet > 7320us SlaveB responds with a UDP packet > etc.. > This behaviour is really strange and untypical. But as some of your application code is involved in the loop, I cannot say anything more without having a look at it as well. User space or kernel space application? Maybe it happens to contain some non-RT functions which introduce such latencies. > > 1) Anyone could tell me why this behaviour? > My opinion is that the real behaviour would be the next: > time event > 0 SOF > 19us Master send a broadcast UDP packet 00, side of 15byte > 100us SlaveA responds with a UDP packet > 120us SlaveB responds with a UDP packet > 600us SOF > 720us Master send a broadcast UDP packet 01, side of 15byte > 800us SlaveA responds with a UDP packet > 820us SlaveB responds with a UDP packet > etc.. > > this behaviour no change when I have different UDP packet size (96byte > or 256byte) > > > 2) could I have a cycle time slower than 600us? > now I can't use a cycle time slower than 600us, as the example above. > 600 us is indeed quite stressing, you should examine your system load and the timing behaviour over a longer, loaded period very carefully (the worst case counts...). Anyway, if the cycle period would already be too high, you should rather observe more frequent cycle misses by one, not by 5 or so. > 3) If It could be possible what is the real cycle time limit? > > thanks for all, best regards. > > Jan
signature.asc
Description: OpenPGP digital signature
