Leonardo Pappagallo wrote: >> 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. > > I compiled RTnet in standard mode : > ./configure --with-rtai=<PATH-TO-RTAI> --enable-allpci > In this case, is it possible to load noMAC module without recompiling RTnet? > If is it not possible, could you tell me how have i to do? > > you know that when you compile RTnet in above mode, when I execute the > command : ./rtnet start, the tdma.ko module is loaded by default. > > how could I load noMAC module with the same command (./rtnet start), > without loading tdma module?
It's much simpler, just just have to start a minimalistic RTnet manually: insmod rtnet insmod rt_<DRIVER> insmod rtcfg (just for starting the timer) rtifconfig rteth0 up <IP> rtping <REMOTE_IP> (no need for NoMAC - avoid loading RTmac/TDMA or also attaching it to some RT-NIC already does the job) > >> 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 > > I wrote this code: > [...] Code looks ok - besides that there is no mlockall(). This means that code and data pages are mapped into your real-time applications' address spaces ON DEMAND! This could explain the initial delays. > >>> User space or kernel space application? > > I work in user-space > I build the application with Kdevelop in KDE 3.3 > I have a linux debian > I compile the code in C++ ptimized mode > > > >> 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. > > sorry, I don't undestand above paragraph. > can you explain it better? I meant that the extreme delays during the first round is not what I would expect in an overload situation, the delay should be smaller (not more than 1 cycle) in that case. Jan
signature.asc
Description: OpenPGP digital signature
