Jan Kiszka wrote:
> Jan Kiszka wrote:
> > Karl Reichert wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Jan Kiszka wrote:
> >>>>>> Karl Reichert wrote:
> >>>> ...
> >>>>>>> I put the freeze after the sleep now, please see attached files.
> >>> This
> >>>> is
> >>>>>> what printk gives:
> >>>>>>> [ 7605.737664] [REK debug] tdma->current_cycle_start =
> >>>>>> 1191326103544417349
> >>>>>>> [ 7605.737708] [REK debug] job->offset = 2300000
> >>>>>> So you sleep about 2300 us after the Sync frame reception. But your
> >>>>>> frozen backtrace doesn't cover the full period, just look at the
> >>>>>> timestamps. Once you can see the full period of 2300 us from
> falling
> >>>>>> asleep until waking up and maybe also sending the packet (play with
> >>>>>> back_trace_points and post_trace_points), you can be sure that the
> >>>> local
> >>>>>> timing is correct.
> >>>>> I'm sorry, I do not know how to read those files and where to look
> >>> for.
> >>>> The wiki page is a little bit short about this topic. So I attached
> my
> >>>> frozen and max file again, this time with post_ pre_ and back_ points
> >>> set to
> >>>> 1000. Please tell me where I can see that I really sleep 2300 us.
> Thanks
> >>> in
> >>>> advance ...
> >>>>
> >>>> See comments below. In short: timing looks ok.
> >>> Thanks for the detailed explanatory notes! I added a copy of this to
> >>> Xenomai Wiki dealing with iPipe Tracer. Hope this will help other
> users to
> >>> understand how to read those files.
> >>>
> >>>>>> Then you will have to look at the data again that is received and
> >>>>>> transmitted.
> >>>>> What do you mean by that? Which data? I guess you aren't talking
> about
> >>>> ethernet frames, as I already checked them via wireshark. So which
> data
> >>> is
> >>>> worth to check?
> >>>>
> >>>> Compare the wireshark result (which you took on the wire? Or on one
> of
> >>>> the nodes? Sorry, don't recall anymore) with the data one node sees:
> >>>> which cycle number it receives via Sync and what it then writes out.
> >>>> Next is what the other side receives. Simply track the flow and build
> >>>> your own picture of what is as expected, what might be abnormal.
> >>> I checked this with printk and wireshark and the result is, that
> >>> everything is fine like it should:
> >>> The sync frame is received and the request calibration frame sent by
> the
> >>> slave contains TDMA_current_cycle_no + 1, which means the slave
> request the
> >>> reply calibration frame in the next TDMA cycle. But the problem still
> >>> remains ... the request calibration frame is sent much to late, so
> that the
> >>> desired reply tdma cycle lies in the past.
> >>> So I don't see the reason why this doesn't works now ... we sleep the
> >>> desired time as ipipe tracer showed, we have the right tdma cycle
> value ...
> >>> where the heck is the problem?
> >> I also did a trace on the master now, to see if any problems occur
> there. But as one can see in attached trace file, everything is fine, the
> driver receives the frame ~400us before freeze, so this is not the reason.
> >> I don't have any idea now what the reason for this behavoir could be.
> >> - slave is sleeping desired time
> >> - master is working fast enough (see attached file)
> >> - tdma->current_cycle holds the right value
> >>
> >> any ideas?
> >
> > I'm lacking the full picture, need to catch up with the details tonight
> > or so.
>
> OK, this disease needs to be cured before it becomes chronic: To help me
> getting that full picture, could you send me a current and complete
> Wireshark trace, taken with a third station sniffing the communication
> between master and slave? If there is no hub available to create the
> appropriate setup, the two traces taken on both master and slave at the
> same problematic time would be an alternative.
>
Very good news: I found the reason for this behavoir/bug now!
I'm using the attaced rtnet_start script to start the slave (can't use the
provided one because I don't want RTcfg).
The last command is 'tdmacfg rteth0 slot 0 2300 -s 100 -l rtnet.log'
If I use this script as attached, I get this weird behavoir that the slave
request and calibration reply in a cycle from the past.
If I comment this last comment and enter it manually on console (after
sucessfull run of rtnet_start), everything works fine. Also a 'sleep 3' between
the last command and the precending works fine.
So the reason seems to be, that 'tdmacfg rteth0 slave -c 100 -i 1' returns but
in background still sth is going on. Now running the last command to fast
(without sleep), it can only send the calibration request after this background
stuff is done. And this is why the cycle lies in the past ...
So far my understanding. Maybe just a hint which should be added in the
TDMA.spec or sth that is worth to change on tdmacfg-tool sourcecode.
Thanks anyway for all your help and support, Jan!
Karl
--
von Karl Reichert
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
# RTnet Start Skript
# created by REK, Carmeq GmbH
#!/bin/bash
#set -v on
#set -x on
echo Creating rtnet device ...
if test \! -c /dev/rtnet; then
mknod /dev/rtnet c 10 240
echo rtnet device created
fi
echo Removing non-realtime driver module ...
ifconfig eth0 down 2> /dev/null
rmmod e1000 2> /dev/null
echo non-realtime driver removed
echo Loading realtime driver modules ...
insmod /usr/local/rtnet/modules/rtnet.ko || exit 1
echo rtnet.ko OK
insmod /usr/local/rtnet/modules/rtpacket.ko || exit 1
echo rtpacket.ko OK
insmod /usr/local/rtnet/modules/rt_e1000.ko || exit 1
echo rt_e1000.ko OK
###############################################################################
# start of configuration depending on use of loopback and/or captureing device
###############################################################################
#comment following line if no loopback interface
insmod /usr/local/rtnet/modules/rt_loopback.ko || exit 1
echo rt_loopback.ko OK
#comment following line if no capture interface
insmod /usr/local/rtnet/modules/rtcap.ko || exit 1
echo rtcap.ko OK
#comment following line if no loopback interface
/usr/local/rtnet/sbin/rtifconfig rtlo up || exit 1
echo rtlo is up
#comment following line if no capture interface
ifconfig rteth0 up || exit 1
ifconfig rteth0-mac up || exit 1
#comment following line if no capture interface
#OR capture interface but no loopback interface
ifconfig rtlo up || exit 1
###############################################################################
# end of configuration depending on use of loopback and/or captureing device
###############################################################################
echo Loading discipline modules ...
insmod /usr/local/rtnet/modules/rtmac.ko
echo rtmac.ko OK
insmod /usr/local/rtnet/modules/tdma.ko
echo tdma.ko OK
/usr/local/rtnet/sbin/rtifconfig rteth0 up
echo rteth0 is up
###############################################################################
# start of TDMA configuration (all values in ms)
###############################################################################
echo Setting up TDMA discipline ...
#put your TDMA cycle time here (last number)
#/usr/local/rtnet/sbin/tdmacfg rteth0 master 2000 -c 1 -i 1 || exit 1
/usr/local/rtnet/sbin/tdmacfg rteth0 slave -c 100 -i 1 || exit 1
echo cycle setup OK
#put your TDMA offset related to scheduled cycle start here (last number)
#sleep 3
/usr/local/rtnet/sbin/tdmacfg rteth0 slot 0 2300 -s 100 -l rtnet.log || exit 1
echo offset setup OK
###############################################################################
# end of TDMA configuration
###############################################################################
echo !!!!!!!!!!!!!!!!!!!!!
echo !!! RTnet STARTED !!!
echo !!!!!!!!!!!!!!!!!!!!!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
