rtnet-developers — development-related list

Re: [RTnet-developers] stack/packet/af_packet.c hint

[Jan K. <jan...@si...>]

Wolfgang Köbler wrote:
> Hello,
> 
> I regularly get an assertion in 
> rtnet-0.9.9/stack/packet/af_packet.c function rt_packet_recvmsg(),
> line 302.
> 
> The relevant code is:
>>    rtskb = rtskb_dequeue_chain(&sock->incoming);
>>    RTNET_ASSERT(rtskb != NULL, return -EFAULT;);
> The assertion is:
>> kernel: [  273.609588] Assertion failed! .../rtnet-0.9.9/stack/packet/
>> af_packet.c:rt_packet_recvmsg:302 rtskb != NULL
> 
> AFAICS this seems to happen for every nonblocking recv with no data
> available. This is not a problem unless you call it frequently and the
> error message starts to take up lots of CPU time (and disk space). For
> my application, the error message crashed the system.
> 
> Workaround (patch attached):
>>    rtskb = rtskb_dequeue_chain(&sock->incoming);
>>    if (rtskb == NULL && timeout < 0)
>>        return -EWOULDBLOCK; /* workaround to avoid assertion for 
>>        nonblocking recv. with no data avail. */
>>    RTNET_ASSERT(rtskb != NULL, return -EFAULT;);
> I do not know if this is a bad workaround or proper solution. It works
> for me, though.
> 
> SVN has not changed compared to rtnet-0.9.9 at this piece of code.

Users reported this issue already a few times. Once it was a RTAI bug
(3.3-days or so). Last time the reason remained unclear, see
http://thread.gmane.org/gmane.linux.real-time.rtnet.user/2243/focus=2252

What is your setup? Maybe you can go the debug path sketched in the
thread above (applies both to RTAI and Xenomai).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[RTnet-developers] stack/packet/af_packet.c hint

[Wolfgang <wk...@ko...>]

Hello,

I regularly get an assertion in 
rtnet-0.9.9/stack/packet/af_packet.c function rt_packet_recvmsg(),
line 302.

The relevant code is:
>    rtskb = rtskb_dequeue_chain(&sock->incoming);
>    RTNET_ASSERT(rtskb != NULL, return -EFAULT;);
The assertion is:
> kernel: [  273.609588] Assertion failed! .../rtnet-0.9.9/stack/packet/
> af_packet.c:rt_packet_recvmsg:302 rtskb != NULL

AFAICS this seems to happen for every nonblocking recv with no data
available. This is not a problem unless you call it frequently and the
error message starts to take up lots of CPU time (and disk space). For
my application, the error message crashed the system.

Workaround (patch attached):
>    rtskb = rtskb_dequeue_chain(&sock->incoming);
>    if (rtskb == NULL && timeout < 0)
>        return -EWOULDBLOCK; /* workaround to avoid assertion for 
>        nonblocking recv. with no data avail. */
>    RTNET_ASSERT(rtskb != NULL, return -EFAULT;);
I do not know if this is a bad workaround or proper solution. It works
for me, though.

SVN has not changed compared to rtnet-0.9.9 at this piece of code.

Bye,
Wolfgang

Re: [RTnet-developers] examples/generic/linux_server.c bugfix

[Jan K. <jan...@we...>]

Wolfgang K=F6bler wrote:
> Hello,
>=20
> There is a bug in rtnet-0.9.9/examples/generic/linux_server.c as well
> as in current SVN.=20
>=20
> Details:
> The variable clientLength is not initialized before it is passed to
> recvfrom. Yet, according to "man 2 recvfrom" (debian etch) it should be=

> "initialized to the size of the buffer associated with from".
> I tried the program without my bugfix (below) and it did not work
> (AFAIR "recvfrom() invalid parameter" or wrong address displayed after
> RCV), with the fix it worked as expected.
>=20
> Fix:
> just add clientLength initialization. see attached patch.

Very true. Thanks, just applied it.

Jan

PS: Did you worked on the RTnet wiki entry page? Thanks for your
contribution! I have one suggestion, though: What about pushing the
detailed structure section into a dedicated page?

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Karl Reichert wrote:
> >> Jan Kiszka wrote:
> >>> Karl Reichert wrote:
> >>>> Jan Kiszka wrote:
> >>>>> Karl Reichert wrote:
> >>>>>> Jan Kiszka wrote:
> >>>>>>> Karl Reichert wrote:
> >>>>>>>> Jan Kiszka wrote:
> >>>>>>>>> Karl Reichert wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0
> >> 100
> >>>>> -s
> >>>>>>>>> 100 -l rtnet.log' I do not get any logfile.
> >>>>>>>>>
> >>>>>>>>> Everything is possible given that this features was never
> >>> intensively
> >>>>>>>>> used AFAIK (at least by myself). I do remember it once worked -
> >>> right
> >>>>>>>>> after I implemented it.
> >>>>>>>>>
> >>>>>>>>> Just to double-check: That tdmacfg command is the first one
> >> issued
> >>>>>>> after
> >>>>>>>>> "tdmacfg rteth0 master/slave", isn't it?
> >>>>>>>>>
> >>>>>>>>> Jan
> >>>>>>>>>
> >>>>>>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But
> >>> from
> >>>>> a
> >>>>>>> quick look at sourcecode of tdmacfg I can't find any reason why it
> >>>>> doesn't
> >>>>>>> works.
> >>>>>>>
> >>>>>>> [It's a shame, but I'm lacking a test environment...]
> >>>>>>> Please collect an "strace" dump of the related tdmacfg run. Let's
> >> see
> >>>>> if
> >>>>>>> that already gives some hints. Next step would then be gdb/ddd.
> >>>>>>>
> >>>>>>> Jan
> >>>>>>>
> >>>>>> Hi Jan,
> >>>>>>
> >>>>>> See below for strace log. Seems like it doesn't even tries to open
> a
> >>>>> file:
> >>>>>>
> >>>>>> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0
> 100
> >>> -s
> >>>>> 100 -l rtnet.log
> >>>>>> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100",
> >> "-s",
> >>>>> "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
> >>>>>> brk(0)                                  = 0x804b000
> >>>>>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file
> or
> >>>>> directory)
> >>>>>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> >> -1,
> >>>>> 0) = 0xb7f85000
> >>>>>> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file
> or
> >>>>> directory)
> >>>>>> open("/etc/ld.so.cache", O_RDONLY)      = 3
> >>>>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
> >>>>>> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
> >>>>>> close(3)                                = 0
> >>>>>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file
> or
> >>>>> directory)
> >>>>>> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> >>>>>> read(3,
> >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...,
> >>>>> 512) = 512
> >>>>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
> >>>>>> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_DENYWRITE,
> >>> 3,
> >>>>> 0) = 0xb7e3b000
> >>>>>> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
> >>>>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
> >>>>>> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
> >>>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
> >>>>>> close(3)                                = 0
> >>>>>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> >> -1,
> >>>>> 0) = 0xb7e3a000
> >>>>>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
> >>>>> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> >>> limit_in_pages:1,
> >>>>> seg_not_present:0, useable:1}) = 0
> >>>>>> mprotect(0xb7f76000, 4096, PROT_READ)   = 0
> >>>>>> munmap(0xb7f7c000, 34837)               = 0
> >>>>>> open("/dev/rtnet", O_RDWR)              = 3
> >>>>>> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
> >>>>> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the
> >> expected
> >>>>> size of the log file. It returns 0, and that can only mean that TDMA
> >>>>> considers the addressed Ethernet device as already calibrated.
> >> Possible
> >>>>> reasons:
> >>>>>  - some "slot" command was already issued on the device
> >>>>>  - device is configured as (primary) master
> >>>> Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0
> >>> master 10000 -i 1' before ...
> >>>> But still I don't get it: with above command I just start the master,
> >> to
> >>> assign a send slot, I also have to assign a slot. Can't I get a log
> for
> >>> this?
> >>>
> >>> Nope, because the primary master doesn't calibrate itself - usually.
> >>> Against which master should it do so? It only goes through calibration
> >>> if it is restarting after a failure and there is currently a backup
> >>> master running in the network.
> >>>
> >>> Jan
> >>>
> >> No, not the master, if there is no backup master, then of course not
> ...
> >> But with second command, assigning a sending slot for master, I thought
> it
> >> would also do calibration rounds. But from logical thinking it doesn't
> >> makes sense, because t_trans = 0 and t_offs = 0 ;)
> >>
> >> Thanks Jan, solved my question. So seems to be no bug in there :)
> >>
> >> Karl
> > 
> > Tried now a different setup: A master and a slave _not_ on the same
> machines, and still logging doesn't brings any effect. No log file is created.
> So seems like there is really a bug!
> 
> I'm not that sure, but I cannot prove the opposite: my test net is
> packed in boxes, ready to be shipped (I'm moving). Will take quite a
> while until it's up again, so you may have to dig on your own (strace,
> printk-debugging, etc.).

Just in case somebody cares: There is no bug at all, logging works fine with a slave now. To problem was sth with the rt_e1000 driver (see RTnet wiki for more information). So no bugfixing is needed ...

Karl
-- 
von Karl Reichert

NEU! +++ GMX empfiehlt DSL-Komplettpaket von 1&1  +++
Jetzt mit Best-Price-Garantie: http://www.gmx.net/de/go/dsl

[RTnet-developers] examples/generic/linux_server.c bugfix

[Wolfgang <wk...@ko...>]

Hello,

There is a bug in rtnet-0.9.9/examples/generic/linux_server.c as well
as in current SVN. 

Details:
The variable clientLength is not initialized before it is passed to
recvfrom. Yet, according to "man 2 recvfrom" (debian etch) it should be
"initialized to the size of the buffer associated with from".
I tried the program without my bugfix (below) and it did not work
(AFAIR "recvfrom() invalid parameter" or wrong address displayed after
RCV), with the fix it worked as expected.

Fix:
just add clientLength initialization. see attached patch.

Bye,
Wolfgang

Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Karl Reichert wrote:
>> Jan Kiszka wrote:
>>> Karl Reichert wrote:
>>>> Jan Kiszka wrote:
>>>>> Karl Reichert wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Karl Reichert wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> Karl Reichert wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0
>> 100
>>>>> -s
>>>>>>>>> 100 -l rtnet.log' I do not get any logfile.
>>>>>>>>>
>>>>>>>>> Everything is possible given that this features was never
>>> intensively
>>>>>>>>> used AFAIK (at least by myself). I do remember it once worked -
>>> right
>>>>>>>>> after I implemented it.
>>>>>>>>>
>>>>>>>>> Just to double-check: That tdmacfg command is the first one
>> issued
>>>>>>> after
>>>>>>>>> "tdmacfg rteth0 master/slave", isn't it?
>>>>>>>>>
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But
>>> from
>>>>> a
>>>>>>> quick look at sourcecode of tdmacfg I can't find any reason why it
>>>>> doesn't
>>>>>>> works.
>>>>>>>
>>>>>>> [It's a shame, but I'm lacking a test environment...]
>>>>>>> Please collect an "strace" dump of the related tdmacfg run. Let's
>> see
>>>>> if
>>>>>>> that already gives some hints. Next step would then be gdb/ddd.
>>>>>>>
>>>>>>> Jan
>>>>>>>
>>>>>> Hi Jan,
>>>>>>
>>>>>> See below for strace log. Seems like it doesn't even tries to open a
>>>>> file:
>>>>>>
>>>>>> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100
>>> -s
>>>>> 100 -l rtnet.log
>>>>>> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100",
>> "-s",
>>>>> "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
>>>>>> brk(0)                                  = 0x804b000
>>>>>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
>>>>> directory)
>>>>>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
>> -1,
>>>>> 0) = 0xb7f85000
>>>>>> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
>>>>> directory)
>>>>>> open("/etc/ld.so.cache", O_RDONLY)      = 3
>>>>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
>>>>>> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
>>>>>> close(3)                                = 0
>>>>>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
>>>>> directory)
>>>>>> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
>>>>>> read(3,
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...,
>>>>> 512) = 512
>>>>>> fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
>>>>>> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
>>> 3,
>>>>> 0) = 0xb7e3b000
>>>>>> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
>>>>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
>>>>>> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
>>>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
>>>>>> close(3)                                = 0
>>>>>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
>> -1,
>>>>> 0) = 0xb7e3a000
>>>>>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
>>>>> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
>>> limit_in_pages:1,
>>>>> seg_not_present:0, useable:1}) = 0
>>>>>> mprotect(0xb7f76000, 4096, PROT_READ)   = 0
>>>>>> munmap(0xb7f7c000, 34837)               = 0
>>>>>> open("/dev/rtnet", O_RDWR)              = 3
>>>>>> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
>>>>> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the
>> expected
>>>>> size of the log file. It returns 0, and that can only mean that TDMA
>>>>> considers the addressed Ethernet device as already calibrated.
>> Possible
>>>>> reasons:
>>>>>  - some "slot" command was already issued on the device
>>>>>  - device is configured as (primary) master
>>>> Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0
>>> master 10000 -i 1' before ...
>>>> But still I don't get it: with above command I just start the master,
>> to
>>> assign a send slot, I also have to assign a slot. Can't I get a log for
>>> this?
>>>
>>> Nope, because the primary master doesn't calibrate itself - usually.
>>> Against which master should it do so? It only goes through calibration
>>> if it is restarting after a failure and there is currently a backup
>>> master running in the network.
>>>
>>> Jan
>>>
>> No, not the master, if there is no backup master, then of course not ...
>> But with second command, assigning a sending slot for master, I thought it
>> would also do calibration rounds. But from logical thinking it doesn't
>> makes sense, because t_trans = 0 and t_offs = 0 ;)
>>
>> Thanks Jan, solved my question. So seems to be no bug in there :)
>>
>> Karl
> 
> Tried now a different setup: A master and a slave _not_ on the same machines, and still logging doesn't brings any effect. No log file is created. So seems like there is really a bug!

I'm not that sure, but I cannot prove the opposite: my test net is
packed in boxes, ready to be shipped (I'm moving). Will take quite a
while until it's up again, so you may have to dig on your own (strace,
printk-debugging, etc.).

Jan

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
> > Karl Reichert wrote:
> > > Jan Kiszka wrote:
> > >> Karl Reichert wrote:
> > >>> Jan Kiszka wrote:
> > >>>> Karl Reichert wrote:
> > >>>>> Jan Kiszka wrote:
> > >>>>>> Karl Reichert wrote:
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0
> 100
> > >> -s
> > >>>>>> 100 -l rtnet.log' I do not get any logfile.
> > >>>>>>
> > >>>>>> Everything is possible given that this features was never
> > intensively
> > >>>>>> used AFAIK (at least by myself). I do remember it once worked -
> > right
> > >>>>>> after I implemented it.
> > >>>>>>
> > >>>>>> Just to double-check: That tdmacfg command is the first one
> issued
> > >>>> after
> > >>>>>> "tdmacfg rteth0 master/slave", isn't it?
> > >>>>>>
> > >>>>>> Jan
> > >>>>>>
> > >>>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But
> > from
> > >> a
> > >>>> quick look at sourcecode of tdmacfg I can't find any reason why it
> > >> doesn't
> > >>>> works.
> > >>>>
> > >>>> [It's a shame, but I'm lacking a test environment...]
> > >>>> Please collect an "strace" dump of the related tdmacfg run. Let's
> see
> > >> if
> > >>>> that already gives some hints. Next step would then be gdb/ddd.
> > >>>>
> > >>>> Jan
> > >>>>
> > >>> Hi Jan,
> > >>>
> > >>> See below for strace log. Seems like it doesn't even tries to open a
> > >> file:
> > >>>
> > >>>
> > >>> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100
> > -s
> > >> 100 -l rtnet.log
> > >>> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100",
> "-s",
> > >> "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
> > >>> brk(0)                                  = 0x804b000
> > >>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> > >> directory)
> > >>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1,
> > >> 0) = 0xb7f85000
> > >>> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> > >> directory)
> > >>> open("/etc/ld.so.cache", O_RDONLY)      = 3
> > >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
> > >>> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
> > >>> close(3)                                = 0
> > >>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> > >> directory)
> > >>> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> > >>> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...,
> > >> 512) = 512
> > >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
> > >>> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> > 3,
> > >> 0) = 0xb7e3b000
> > >>> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
> > >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
> > >>> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
> > >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
> > >>> close(3)                                = 0
> > >>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1,
> > >> 0) = 0xb7e3a000
> > >>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
> > >> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> > limit_in_pages:1,
> > >> seg_not_present:0, useable:1}) = 0
> > >>> mprotect(0xb7f76000, 4096, PROT_READ)   = 0
> > >>> munmap(0xb7f7c000, 34837)               = 0
> > >>> open("/dev/rtnet", O_RDWR)              = 3
> > >>> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
> > >> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the
> expected
> > >> size of the log file. It returns 0, and that can only mean that TDMA
> > >> considers the addressed Ethernet device as already calibrated.
> Possible
> > >> reasons:
> > >>  - some "slot" command was already issued on the device
> > >>  - device is configured as (primary) master
> > > 
> > > Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0
> > master 10000 -i 1' before ...
> > > 
> > > But still I don't get it: with above command I just start the master,
> to
> > assign a send slot, I also have to assign a slot. Can't I get a log for
> > this?
> > 
> > Nope, because the primary master doesn't calibrate itself - usually.
> > Against which master should it do so? It only goes through calibration
> > if it is restarting after a failure and there is currently a backup
> > master running in the network.
> > 
> > Jan
> > 
> 
> No, not the master, if there is no backup master, then of course not ...
> But with second command, assigning a sending slot for master, I thought it
> would also do calibration rounds. But from logical thinking it doesn't
> makes sense, because t_trans = 0 and t_offs = 0 ;)
> 
> Thanks Jan, solved my question. So seems to be no bug in there :)
> 
> Karl

Tried now a different setup: A master and a slave _not_ on the same machines, and still logging doesn't brings any effect. No log file is created. So seems like there is really a bug!

Karl
-- 
von Karl Reichert

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

[RTnet-developers] Companies in Japan that can develop RT / RTnet modules?

[Romain L. <rom...@be...>]

Hello,

Does anybody know some companies *in Japan* that can develop custom RTnet 
modules (or even at least RT modules) in outsourcing?

The ideal target for development would be RTnet / Xenomai, but we don't mind 
targetting RTnet / RTAI, or even any other RTOS without RTnet (hopefully, 
Xenomai would still be usable as the runtime thanks to its several "skins").

We need to outsource the development of network and radiocommunication RT 
modules for experimental validation.

Please keep me in CC: in answers, since I am no more subscribed to the 
mailing-lists.

Regards,

--
Romain Lenglet

[RTnet-developers] [RFT] RTnet over 2.6.22 and .23

[Jan K. <jan...@we...>]

For early adopters:

The Subversion repos contains the updates to use RTnet over 2.6.22 and
upcoming 2.6.23. I performed successful real-life tests a couple of
weeks ago on a 2.6.22-rcX kernel. Later versions were compile-tested
against 2.6.22.x and 2.6.23-rc2. Testing currently relies on Xenomai
2.4-rc1 and is limited to x86 platforms.

The next maintenance release (0.9.10) is scheduled around the official
roll-out of Xenomai 2.4 (*) in a "few" weeks, but earlier feedback on
the updates is welcome!

Jan

(*) 2.4 will ease the life of RTnet application developers by
auto-cleaning file descriptors on program termination and will allow to
use RTnet along with more RTOS skins like VxWorks.

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Jan Kiszka wrote:
> >>>>>> Karl Reichert wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100
> >> -s
> >>>>>> 100 -l rtnet.log' I do not get any logfile.
> >>>>>>
> >>>>>> Everything is possible given that this features was never
> intensively
> >>>>>> used AFAIK (at least by myself). I do remember it once worked -
> right
> >>>>>> after I implemented it.
> >>>>>>
> >>>>>> Just to double-check: That tdmacfg command is the first one issued
> >>>> after
> >>>>>> "tdmacfg rteth0 master/slave", isn't it?
> >>>>>>
> >>>>>> Jan
> >>>>>>
> >>>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But
> from
> >> a
> >>>> quick look at sourcecode of tdmacfg I can't find any reason why it
> >> doesn't
> >>>> works.
> >>>>
> >>>> [It's a shame, but I'm lacking a test environment...]
> >>>> Please collect an "strace" dump of the related tdmacfg run. Let's see
> >> if
> >>>> that already gives some hints. Next step would then be gdb/ddd.
> >>>>
> >>>> Jan
> >>>>
> >>> Hi Jan,
> >>>
> >>> See below for strace log. Seems like it doesn't even tries to open a
> >> file:
> >>>
> >>>
> >>> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100
> -s
> >> 100 -l rtnet.log
> >>> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s",
> >> "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
> >>> brk(0)                                  = 0x804b000
> >>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> >> directory)
> >>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> >> 0) = 0xb7f85000
> >>> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> >> directory)
> >>> open("/etc/ld.so.cache", O_RDONLY)      = 3
> >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
> >>> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
> >>> close(3)                                = 0
> >>> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> >> directory)
> >>> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> >>> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...,
> >> 512) = 512
> >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
> >>> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3,
> >> 0) = 0xb7e3b000
> >>> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
> >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
> >>> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
> >> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
> >>> close(3)                                = 0
> >>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> >> 0) = 0xb7e3a000
> >>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
> >> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1,
> >> seg_not_present:0, useable:1}) = 0
> >>> mprotect(0xb7f76000, 4096, PROT_READ)   = 0
> >>> munmap(0xb7f7c000, 34837)               = 0
> >>> open("/dev/rtnet", O_RDWR)              = 3
> >>> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
> >> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the expected
> >> size of the log file. It returns 0, and that can only mean that TDMA
> >> considers the addressed Ethernet device as already calibrated. Possible
> >> reasons:
> >>  - some "slot" command was already issued on the device
> >>  - device is configured as (primary) master
> > 
> > Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0
> master 10000 -i 1' before ...
> > 
> > But still I don't get it: with above command I just start the master, to
> assign a send slot, I also have to assign a slot. Can't I get a log for
> this?
> 
> Nope, because the primary master doesn't calibrate itself - usually.
> Against which master should it do so? It only goes through calibration
> if it is restarting after a failure and there is currently a backup
> master running in the network.
> 
> Jan
> 

No, not the master, if there is no backup master, then of course not ...
But with second command, assigning a sending slot for master, I thought it would also do calibration rounds. But from logical thinking it doesn't makes sense, because t_trans = 0 and t_offs = 0 ;)

Thanks Jan, solved my question. So seems to be no bug in there :)

Karl
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Karl Reichert wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 10=
0
>> -s
>>>>>> 100 -l rtnet.log' I do not get any logfile.
>>>>>>
>>>>>> Everything is possible given that this features was never intensiv=
ely
>>>>>> used AFAIK (at least by myself). I do remember it once worked - ri=
ght
>>>>>> after I implemented it.
>>>>>>
>>>>>> Just to double-check: That tdmacfg command is the first one issued=

>>>> after
>>>>>> "tdmacfg rteth0 master/slave", isn't it?
>>>>>>
>>>>>> Jan
>>>>>>
>>>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But fr=
om
>> a
>>>> quick look at sourcecode of tdmacfg I can't find any reason why it
>> doesn't
>>>> works.
>>>>
>>>> [It's a shame, but I'm lacking a test environment...]
>>>> Please collect an "strace" dump of the related tdmacfg run. Let's se=
e
>> if
>>>> that already gives some hints. Next step would then be gdb/ddd.
>>>>
>>>> Jan
>>>>
>>> Hi Jan,
>>>
>>> See below for strace log. Seems like it doesn't even tries to open a
>> file:
>>>
>>>
>>> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100 =
-s
>> 100 -l rtnet.log
>>> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s",=

>> "100", "-l", "rtnet.log"], [/* 34 vars */]) =3D 0
>>> brk(0)                                  =3D 0x804b000
>>> access("/etc/ld.so.nohwcap", F_OK)      =3D -1 ENOENT (No such file o=
r
>> directory)
>>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1=
,
>> 0) =3D 0xb7f85000
>>> access("/etc/ld.so.preload", R_OK)      =3D -1 ENOENT (No such file o=
r
>> directory)
>>> open("/etc/ld.so.cache", O_RDONLY)      =3D 3
>>> fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D34837, ...}) =3D 0
>>> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0xb7f7c000
>>> close(3)                                =3D 0
>>> access("/etc/ld.so.nohwcap", F_OK)      =3D -1 ENOENT (No such file o=
r
>> directory)
>>> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) =3D 3
>>> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...=
,
>> 512) =3D 512
>>> fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D1307104, ...}) =3D 0
>>> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, =
3,
>> 0) =3D 0xb7e3b000
>>> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) =3D 0xb7f76000
>>> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) =3D 0xb7f79000
>>> close(3)                                =3D 0
>>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1=
,
>> 0) =3D 0xb7e3a000
>>> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
>> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pag=
es:1,
>> seg_not_present:0, useable:1}) =3D 0
>>> mprotect(0xb7f76000, 4096, PROT_READ)   =3D 0
>>> munmap(0xb7f7c000, 34837)               =3D 0
>>> open("/dev/rtnet", O_RDWR)              =3D 3
>>> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) =3D 0
>> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the expecte=
d
>> size of the log file. It returns 0, and that can only mean that TDMA
>> considers the addressed Ethernet device as already calibrated. Possibl=
e
>> reasons:
>>  - some "slot" command was already issued on the device
>>  - device is configured as (primary) master
>=20
> Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0 mas=
ter 10000 -i 1' before ...
>=20
> But still I don't get it: with above command I just start the master, t=
o assign a send slot, I also have to assign a slot. Can't I get a log for=
 this?

Nope, because the primary master doesn't calibrate itself - usually.
Against which master should it do so? It only goes through calibration
if it is restarting after a failure and there is currently a backup
master running in the network.

Jan

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Hi,
> >>>>>
> >>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100
> -s
> >>>> 100 -l rtnet.log' I do not get any logfile.
> >>>>
> >>>> Everything is possible given that this features was never intensively
> >>>> used AFAIK (at least by myself). I do remember it once worked - right
> >>>> after I implemented it.
> >>>>
> >>>> Just to double-check: That tdmacfg command is the first one issued
> >> after
> >>>> "tdmacfg rteth0 master/slave", isn't it?
> >>>>
> >>>> Jan
> >>>>
> >>> Yes it is. Searched whole / for rtnet.log, nothing is there. But from
> a
> >> quick look at sourcecode of tdmacfg I can't find any reason why it
> doesn't
> >> works.
> >>
> >> [It's a shame, but I'm lacking a test environment...]
> >> Please collect an "strace" dump of the related tdmacfg run. Let's see
> if
> >> that already gives some hints. Next step would then be gdb/ddd.
> >>
> >> Jan
> >>
> > 
> > Hi Jan,
> > 
> > See below for strace log. Seems like it doesn't even tries to open a
> file:
> > 
> > 
> > 
> > root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100 -s
> 100 -l rtnet.log
> > execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s",
> "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
> > brk(0)                                  = 0x804b000
> > access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> > mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f85000
> > access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or
> directory)
> > open("/etc/ld.so.cache", O_RDONLY)      = 3
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
> > mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
> > close(3)                                = 0
> > access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> > open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"...,
> 512) = 512
> > fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
> > mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0xb7e3b000
> > mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
> > mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
> > close(3)                                = 0
> > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7e3a000
> > set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0
> > mprotect(0xb7f76000, 4096, PROT_READ)   = 0
> > munmap(0xb7f7c000, 34837)               = 0
> > open("/dev/rtnet", O_RDWR)              = 3
> > ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
> 
> This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the expected
> size of the log file. It returns 0, and that can only mean that TDMA
> considers the addressed Ethernet device as already calibrated. Possible
> reasons:
>  - some "slot" command was already issued on the device
>  - device is configured as (primary) master

Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0 master 10000 -i 1' before ...

But still I don't get it: with above command I just start the master, to assign a send slot, I also have to assign a slot. Can't I get a log for this?

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

Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Hi,
>>>>>
>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 =
-s
>>>> 100 -l rtnet.log' I do not get any logfile.
>>>>
>>>> Everything is possible given that this features was never intensivel=
y
>>>> used AFAIK (at least by myself). I do remember it once worked - righ=
t
>>>> after I implemented it.
>>>>
>>>> Just to double-check: That tdmacfg command is the first one issued
>> after
>>>> "tdmacfg rteth0 master/slave", isn't it?
>>>>
>>>> Jan
>>>>
>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But from=
 a
>> quick look at sourcecode of tdmacfg I can't find any reason why it doe=
sn't
>> works.
>>
>> [It's a shame, but I'm lacking a test environment...]
>> Please collect an "strace" dump of the related tdmacfg run. Let's see =
if
>> that already gives some hints. Next step would then be gdb/ddd.
>>
>> Jan
>>
>=20
> Hi Jan,
>=20
> See below for strace log. Seems like it doesn't even tries to open a fi=
le:
>=20
>=20
>=20
> root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100 -s=
 100 -l rtnet.log
> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s", "=
100", "-l", "rtnet.log"], [/* 34 vars */]) =3D 0
> brk(0)                                  =3D 0x804b000
> access("/etc/ld.so.nohwcap", F_OK)      =3D -1 ENOENT (No such file or =
directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, =
0) =3D 0xb7f85000
> access("/etc/ld.so.preload", R_OK)      =3D -1 ENOENT (No such file or =
directory)
> open("/etc/ld.so.cache", O_RDONLY)      =3D 3
> fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D34837, ...}) =3D 0
> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) =3D 0xb7f7c000
> close(3)                                =3D 0
> access("/etc/ld.so.nohwcap", F_OK)      =3D -1 ENOENT (No such file or =
directory)
> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) =3D 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"..., =
512) =3D 512
> fstat64(3, {st_mode=3DS_IFREG|0644, st_size=3D1307104, ...}) =3D 0
> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,=
 0) =3D 0xb7e3b000
> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MA=
P_DENYWRITE, 3, 0x13b) =3D 0xb7f76000
> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP=
_ANONYMOUS, -1, 0) =3D 0xb7f79000
> close(3)                                =3D 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, =
0) =3D 0xb7e3a000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0, limit:1048=
575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not=
_present:0, useable:1}) =3D 0
> mprotect(0xb7f76000, 4096, PROT_READ)   =3D 0
> munmap(0xb7f7c000, 34837)               =3D 0
> open("/dev/rtnet", O_RDWR)              =3D 3
> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) =3D 0

This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the expected
size of the log file. It returns 0, and that can only mean that TDMA
considers the addressed Ethernet device as already calibrated. Possible
reasons:
 - some "slot" command was already issued on the device
 - device is configured as (primary) master
 - calibration rounds were set to 0 ("tdmacfg ... -c 0")
 - some bug is sabotaging this procedure subtly

If you think the latter, tracking the issue down should now continue at
kernel level, checking eg. the TDMA_FLAG_CALIBRATED flag.

Jan

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Hi,
> >>>
> >>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s
> >> 100 -l rtnet.log' I do not get any logfile.
> >>
> >> Everything is possible given that this features was never intensively
> >> used AFAIK (at least by myself). I do remember it once worked - right
> >> after I implemented it.
> >>
> >> Just to double-check: That tdmacfg command is the first one issued
> after
> >> "tdmacfg rteth0 master/slave", isn't it?
> >>
> >> Jan
> >>
> > 
> > Yes it is. Searched whole / for rtnet.log, nothing is there. But from a
> quick look at sourcecode of tdmacfg I can't find any reason why it doesn't
> works.
> 
> [It's a shame, but I'm lacking a test environment...]
> Please collect an "strace" dump of the related tdmacfg run. Let's see if
> that already gives some hints. Next step would then be gdb/ddd.
> 
> Jan
> 

Hi Jan,

See below for strace log. Seems like it doesn't even tries to open a file:



root@rtnet:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100 -s 100 -l rtnet.log
execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s", "100", "-l", "rtnet.log"], [/* 34 vars */]) = 0
brk(0)                                  = 0x804b000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e3b000
mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e3a000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f76000, 4096, PROT_READ)   = 0
munmap(0xb7f7c000, 34837)               = 0
open("/dev/rtnet", O_RDWR)              = 3
ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
ioctl(3, NCP_IOC_CONN_LOGGED_IN, 0x804a760) = 0
exit_group(0)                           = ?
Process 4095 detached



Karl
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Hi,
>>>
>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s=

>> 100 -l rtnet.log' I do not get any logfile.
>>
>> Everything is possible given that this features was never intensively
>> used AFAIK (at least by myself). I do remember it once worked - right
>> after I implemented it.
>>
>> Just to double-check: That tdmacfg command is the first one issued aft=
er
>> "tdmacfg rteth0 master/slave", isn't it?
>>
>> Jan
>>
>=20
> Yes it is. Searched whole / for rtnet.log, nothing is there. But from a=
 quick look at sourcecode of tdmacfg I can't find any reason why it doesn=
't works.

[It's a shame, but I'm lacking a test environment...]
Please collect an "strace" dump of the related tdmacfg run. Let's see if
that already gives some hints. Next step would then be gdb/ddd.

Jan

Re: [RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Hi,
> > 
> > found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s
> 100 -l rtnet.log' I do not get any logfile.
> 
> Everything is possible given that this features was never intensively
> used AFAIK (at least by myself). I do remember it once worked - right
> after I implemented it.
> 
> Just to double-check: That tdmacfg command is the first one issued after
> "tdmacfg rteth0 master/slave", isn't it?
> 
> Jan
> 

Yes it is. Searched whole / for rtnet.log, nothing is there. But from a quick look at sourcecode of tdmacfg I can't find any reason why it doesn't works.

Karl
-- 
von Karl Reichert

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Hi,
>=20
> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s 1=
00 -l rtnet.log' I do not get any logfile.

Everything is possible given that this features was never intensively
used AFAIK (at least by myself). I do remember it once worked - right
after I implemented it.

Just to double-check: That tdmacfg command is the first one issued after
"tdmacfg rteth0 master/slave", isn't it?

Jan

[RTnet-developers] bug: log file isn't written

[Karl R. <Kar...@gm...>]

Hi,

found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s 100 -l rtnet.log' I do not get any logfile.

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

Re: [RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I'm currently working on getting RTnet working on an Infineon
> TriCore
> >>>>> 1130 and found some issues, which could be solved in the next major
> >>>>> TDMA version comming with RTnet. Would like to discuss these issues
> >>>>> to see other's opinion about that.
> >>>>>
> >>>>> The TriCore1 architecture is a little bit tricky. When you want to
> >>>>> send a frame over Ethernet, the host (the "cpu") has to write it
> into
> >>>>> a shared memory (available via FPI bus). Then the host writes a
> >>>>> special register to tell the DMUT (Data Management Unit Transmit) to
> >>>>> get this Frame from shared memory and write it into Transmit Buffer
> >>>>> TB. The TX block of the MAC takes the frame from TB and sends it to
> >>>>> MII, which will put it on the wire. All this can be found in detail
> >>>>> in [1], chapter 31.
> >>>>>
> >>>>> Here comes the problem: When sending request calibration frames, one
> >>>>> has to provide a transmission time stamp as close as possible to the
> >>>>> real transmission time. As the TriCore does not support changing the
> >>>>> frame after writing it into shared memory (by host), there is no way
> >>>>> for providing a real transmission time stamp. Only option is to put
> >>>>> the scheduled transmission time there which will have the effect,
> >>>>> that transmission time on the wire t_trans is always calculated to
> >>>>> long because the real transmission is done later.
> >>>> Unless you have to make the steps of writing to the shared mem +
> >>>> triggering the transmission preemptible, the solution is simple: just
> >>>> push out the local time taken right _before_ you start writing the
> >>>> frame. For your arch, that is the point "as close as possible" to the
> >>>> real tx date.
> >>>>
> >>>>> To fix this issue there will be a few possibilities, one comes here:
> >>>>> One could change TDMA.spec and allow slaves to send a two-parted
> >>>>> request calibration frame. First one has a don't care Transmission
> >>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
> >>>>> will notice their transmission time stamp in their TXISR, and send
> it
> >>>>> in the second ReqCalFrm. This would make the whole process much more
> >>>>> precise, but of course requires changes in TDMA.spec.
> >>>> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> >>>> the timestamp of the first one), IIRC. Would be possible to extend
> the
> >>>> specs, but there should be real hard needs for it.
> >>>>
> >>>> Again, as long as the tx timestamp is taken at a fixed date before
> real
> >>>> tx, TDMA can handle this (may one should clarify the spec in this
> >> regard).
> >>>> Jan
> >>>>
> >>> Well, the problem is that FPI bus is a shared bus, which will have the
> >> effect that in some cases it may take longer until the frame is on the
> wire
> >> and in some cases it may take less time. As a result, the tx timestamp
> is
> >> _not_ taken at a fixed date before real tx.
> >>
> >> OK, that sounds almost like a "hard need". What are the other users on
> >> this bus, and who is controlling the access (host or devices)? And what
> >> dimension would the jitter then have (10 of microseconds, more, or
> less)?
> >>
> >> Jan
> >>
> > Other users can be in general every device also connected to FPI bus. In
> my case, some memory is also connected to FPI, which has the effect, that
> host and all devices using this memory accessing the bus. As those devices
> may read/write async from/into the memory, there is no way to ensure stable
> times accessing this bus.
> > The dimension of the jitter is very depending on the situation. In my
> case, using only host and Ethernet-Controller, this value is always around 11
> µs, jitter is less then 2 µs. But this is really depending on the use
> case. If there would be other devices using the bus (USB, serial ...), the
> jitter will be much higher for sure. Would be worth to do some tests for
> that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.
> 
> Thinking about this a bit further: When you can face such high jitters
> on the FPI bus, won't your RX timestamps be impacted by them as well?
No, they don't because rx timestamp is taken by host in MACRXISR and there is no connection to FPI bus cause the interrupt isn't affected in any way with FPI.

> And will you compensate for the TX jittery also by uploading the final
> frames early enough before the scheduled slot time during normal
> operation?
> 
Yes, that's my strategy: Putting the frame already so close to MACTX unit that only transmit enable signal is set when slot starts.

> If you FPI bus is really that indeterministic as you fear, the whole
> system would be fairly unsuited for RT applications. I think I heard
> that Tricore is used heavily in industrial and automotive, isn't it? Are
> there better peripheral interfaces then? Well, at least for you
> scenario, those 2 us jitter would be _far_ better than what you get on
> any RTOS-managed platform, so no need to worry. Still, this requires
> some more analysis to be sure - and that means it may cost time... :)
> 
> Jan
It is deterministic, but only in special cases. You can asign priorities to units, so the unit with highest FPI priority will get the bus no matter what and then of course the jitter is very low and deterministic. Problems occur whenever you need more then one unit communication over FPi because in some cases it is necessary to not give highest priority to ETH unit.
So, to say it more clear: In my case, in my current situation, using only ETH unit and therefore having a very small jitter of only 2 us, a new TDMA draft is _not_ needed. But when one thinks a bit further those problems have to be faced. Using more units with the need for real time behavior will cause higher latency and let this problem grow.
So my idea was not really an urgent case, more sth to discuss when you look in the future ...

Karl
-- 
von Karl Reichert

NEU! +++ GMX empfiehlt DSL-Komplettpaket von 1&1  +++
Surfen und Telefonieren!*: http://www.gmx.net/de/go/dsl

Re: [RTnet-developers] some suggestions for the next TDMA version

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Hello,
>>>>>
>>>>> I'm currently working on getting RTnet working on an Infineon TriCore
>>>>> 1130 and found some issues, which could be solved in the next major
>>>>> TDMA version comming with RTnet. Would like to discuss these issues
>>>>> to see other's opinion about that.
>>>>>
>>>>> The TriCore1 architecture is a little bit tricky. When you want to
>>>>> send a frame over Ethernet, the host (the "cpu") has to write it into
>>>>> a shared memory (available via FPI bus). Then the host writes a
>>>>> special register to tell the DMUT (Data Management Unit Transmit) to
>>>>> get this Frame from shared memory and write it into Transmit Buffer
>>>>> TB. The TX block of the MAC takes the frame from TB and sends it to
>>>>> MII, which will put it on the wire. All this can be found in detail
>>>>> in [1], chapter 31.
>>>>>
>>>>> Here comes the problem: When sending request calibration frames, one
>>>>> has to provide a transmission time stamp as close as possible to the
>>>>> real transmission time. As the TriCore does not support changing the
>>>>> frame after writing it into shared memory (by host), there is no way
>>>>> for providing a real transmission time stamp. Only option is to put
>>>>> the scheduled transmission time there which will have the effect,
>>>>> that transmission time on the wire t_trans is always calculated to
>>>>> long because the real transmission is done later.
>>>> Unless you have to make the steps of writing to the shared mem +
>>>> triggering the transmission preemptible, the solution is simple: just
>>>> push out the local time taken right _before_ you start writing the
>>>> frame. For your arch, that is the point "as close as possible" to the
>>>> real tx date.
>>>>
>>>>> To fix this issue there will be a few possibilities, one comes here:
>>>>> One could change TDMA.spec and allow slaves to send a two-parted
>>>>> request calibration frame. First one has a don't care Transmission
>>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
>>>>> will notice their transmission time stamp in their TXISR, and send it
>>>>> in the second ReqCalFrm. This would make the whole process much more
>>>>> precise, but of course requires changes in TDMA.spec.
>>>> Yeah, that's how NTP and PTP work as well (follow-up message carrying
>>>> the timestamp of the first one), IIRC. Would be possible to extend the
>>>> specs, but there should be real hard needs for it.
>>>>
>>>> Again, as long as the tx timestamp is taken at a fixed date before real
>>>> tx, TDMA can handle this (may one should clarify the spec in this
>> regard).
>>>> Jan
>>>>
>>> Well, the problem is that FPI bus is a shared bus, which will have the
>> effect that in some cases it may take longer until the frame is on the wire
>> and in some cases it may take less time. As a result, the tx timestamp is
>> _not_ taken at a fixed date before real tx.
>>
>> OK, that sounds almost like a "hard need". What are the other users on
>> this bus, and who is controlling the access (host or devices)? And what
>> dimension would the jitter then have (10 of microseconds, more, or less)?
>>
>> Jan
>>
> Other users can be in general every device also connected to FPI bus. In my case, some memory is also connected to FPI, which has the effect, that host and all devices using this memory accessing the bus. As those devices may read/write async from/into the memory, there is no way to ensure stable times accessing this bus.
> The dimension of the jitter is very depending on the situation. In my case, using only host and Ethernet-Controller, this value is always around 11 µs, jitter is less then 2 µs. But this is really depending on the use case. If there would be other devices using the bus (USB, serial ...), the jitter will be much higher for sure. Would be worth to do some tests for that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.

Thinking about this a bit further: When you can face such high jitters
on the FPI bus, won't your RX timestamps be impacted by them as well?
And will you compensate for the TX jittery also by uploading the final
frames early enough before the scheduled slot time during normal operation?

If you FPI bus is really that indeterministic as you fear, the whole
system would be fairly unsuited for RT applications. I think I heard
that Tricore is used heavily in industrial and automotive, isn't it? Are
there better peripheral interfaces then? Well, at least for you
scenario, those 2 us jitter would be _far_ better than what you get on
any RTOS-managed platform, so no need to worry. Still, this requires
some more analysis to be sure - and that means it may cost time... :)

Jan

Re: [RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Jan Kiszka wrote:
> >>>> Karl Reichert wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I'm currently working on getting RTnet working on an Infineon
> TriCore
> >>>>> 1130 and found some issues, which could be solved in the next major
> >>>>> TDMA version comming with RTnet. Would like to discuss these issues
> >>>>> to see other's opinion about that.
> >>>>>
> >>>>> The TriCore1 architecture is a little bit tricky. When you want to
> >>>>> send a frame over Ethernet, the host (the "cpu") has to write it
> into
> >>>>> a shared memory (available via FPI bus). Then the host writes a
> >>>>> special register to tell the DMUT (Data Management Unit Transmit) to
> >>>>> get this Frame from shared memory and write it into Transmit Buffer
> >>>>> TB. The TX block of the MAC takes the frame from TB and sends it to
> >>>>> MII, which will put it on the wire. All this can be found in detail
> >>>>> in [1], chapter 31.
> >>>>>
> >>>>> Here comes the problem: When sending request calibration frames, one
> >>>>> has to provide a transmission time stamp as close as possible to the
> >>>>> real transmission time. As the TriCore does not support changing the
> >>>>> frame after writing it into shared memory (by host), there is no way
> >>>>> for providing a real transmission time stamp. Only option is to put
> >>>>> the scheduled transmission time there which will have the effect,
> >>>>> that transmission time on the wire t_trans is always calculated to
> >>>>> long because the real transmission is done later.
> >>>> Unless you have to make the steps of writing to the shared mem +
> >>>> triggering the transmission preemptible, the solution is simple: just
> >>>> push out the local time taken right _before_ you start writing the
> >>>> frame. For your arch, that is the point "as close as possible" to the
> >>>> real tx date.
> >>>>
> >>>>> To fix this issue there will be a few possibilities, one comes here:
> >>>>> One could change TDMA.spec and allow slaves to send a two-parted
> >>>>> request calibration frame. First one has a don't care Transmission
> >>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
> >>>>> will notice their transmission time stamp in their TXISR, and send
> it
> >>>>> in the second ReqCalFrm. This would make the whole process much more
> >>>>> precise, but of course requires changes in TDMA.spec.
> >>>> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> >>>> the timestamp of the first one), IIRC. Would be possible to extend
> the
> >>>> specs, but there should be real hard needs for it.
> >>>>
> >>>> Again, as long as the tx timestamp is taken at a fixed date before
> real
> >>>> tx, TDMA can handle this (may one should clarify the spec in this
> >> regard).
> >>>> Jan
> >>>>
> >>> Well, the problem is that FPI bus is a shared bus, which will have the
> >> effect that in some cases it may take longer until the frame is on the
> wire
> >> and in some cases it may take less time. As a result, the tx timestamp
> is
> >> _not_ taken at a fixed date before real tx.
> >>
> >> OK, that sounds almost like a "hard need". What are the other users on
> >> this bus, and who is controlling the access (host or devices)? And what
> >> dimension would the jitter then have (10 of microseconds, more, or
> less)?
> >>
> >> Jan
> >>
> > Other users can be in general every device also connected to FPI bus. In
> my case, some memory is also connected to FPI, which has the effect, that
> host and all devices using this memory accessing the bus. As those devices
> may read/write async from/into the memory, there is no way to ensure stable
> times accessing this bus.
> > The dimension of the jitter is very depending on the situation. In my
> case, using only host and Ethernet-Controller, this value is always around 11
> µs, jitter is less then 2 µs. But this is really depending on the use
> case. If there would be other devices using the bus (USB, serial ...), the
> jitter will be much higher for sure. Would be worth to do some tests for
> that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.
> > 
> 
> Well, then let's draft a straight forward protocol extension: Some new
> frame type shall be introduced, let's call it "Prologue Frame". It shall
> look like this:
> 
> Version: 0x0202
> Frame ID: 0x0020
> <no further fields>
> 
> That frame is intended to serve as the timestamping reference for the
> follow-up frames (sync, calibration request/reply). This means that,
> instead of the RX timestamp of the succeeding frame, the RX time of the
> prologue frame will be considered by the receiver. This, of course, also
> means that the frame will _always_ be paired with a standard TDMA frame.
> 
> It shall be an optional frame, ie. both the sender and the receiver
> don't need to issue/interpret it. If the receiver ignores it, the error
> of the succeeding original frame would rise, but TDMA should still work
> safely (this claim needs more thoughts, though). If the sender doesn't
> issue it, all would work as before anyway.
> 
> I can't provide a helping hand on the implementation right now. So if
> you are interested in drafting such an extension, only review can be
> provided. The best test-case would be on your side anyway :).
> 
> Jan
> 
Hmm ... sounds logical to me, should work at all. I don't have any time for implementation right now, too. But we should keep this in mind for the future. I could create a draft of TDMA.spec and maybe also of the RTnet implementation, but not now. I am very busy to at the moment, sorry. But we should keep this idea in mind and work on that later.

Karl
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [RTnet-developers] some suggestions for the next TDMA version

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Hello,
>>>>>
>>>>> I'm currently working on getting RTnet working on an Infineon TriCo=
re
>>>>> 1130 and found some issues, which could be solved in the next major=

>>>>> TDMA version comming with RTnet. Would like to discuss these issues=

>>>>> to see other's opinion about that.
>>>>>
>>>>> The TriCore1 architecture is a little bit tricky. When you want to
>>>>> send a frame over Ethernet, the host (the "cpu") has to write it in=
to
>>>>> a shared memory (available via FPI bus). Then the host writes a
>>>>> special register to tell the DMUT (Data Management Unit Transmit) t=
o
>>>>> get this Frame from shared memory and write it into Transmit Buffer=

>>>>> TB. The TX block of the MAC takes the frame from TB and sends it to=

>>>>> MII, which will put it on the wire. All this can be found in detail=

>>>>> in [1], chapter 31.
>>>>>
>>>>> Here comes the problem: When sending request calibration frames, on=
e
>>>>> has to provide a transmission time stamp as close as possible to th=
e
>>>>> real transmission time. As the TriCore does not support changing th=
e
>>>>> frame after writing it into shared memory (by host), there is no wa=
y
>>>>> for providing a real transmission time stamp. Only option is to put=

>>>>> the scheduled transmission time there which will have the effect,
>>>>> that transmission time on the wire t_trans is always calculated to
>>>>> long because the real transmission is done later.
>>>> Unless you have to make the steps of writing to the shared mem +
>>>> triggering the transmission preemptible, the solution is simple: jus=
t
>>>> push out the local time taken right _before_ you start writing the
>>>> frame. For your arch, that is the point "as close as possible" to th=
e
>>>> real tx date.
>>>>
>>>>> To fix this issue there will be a few possibilities, one comes here=
:
>>>>> One could change TDMA.spec and allow slaves to send a two-parted
>>>>> request calibration frame. First one has a don't care Transmission
>>>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
>>>>> will notice their transmission time stamp in their TXISR, and send =
it
>>>>> in the second ReqCalFrm. This would make the whole process much mor=
e
>>>>> precise, but of course requires changes in TDMA.spec.
>>>> Yeah, that's how NTP and PTP work as well (follow-up message carryin=
g
>>>> the timestamp of the first one), IIRC. Would be possible to extend t=
he
>>>> specs, but there should be real hard needs for it.
>>>>
>>>> Again, as long as the tx timestamp is taken at a fixed date before r=
eal
>>>> tx, TDMA can handle this (may one should clarify the spec in this
>> regard).
>>>> Jan
>>>>
>>> Well, the problem is that FPI bus is a shared bus, which will have th=
e
>> effect that in some cases it may take longer until the frame is on the=
 wire
>> and in some cases it may take less time. As a result, the tx timestamp=
 is
>> _not_ taken at a fixed date before real tx.
>>
>> OK, that sounds almost like a "hard need". What are the other users on=

>> this bus, and who is controlling the access (host or devices)? And wha=
t
>> dimension would the jitter then have (10 of microseconds, more, or les=
s)?
>>
>> Jan
>>
> Other users can be in general every device also connected to FPI bus. I=
n my case, some memory is also connected to FPI, which has the effect, th=
at host and all devices using this memory accessing the bus. As those dev=
ices may read/write async from/into the memory, there is no way to ensure=
 stable times accessing this bus.
> The dimension of the jitter is very depending on the situation. In my c=
ase, using only host and Ethernet-Controller, this value is always around=
 11 =B5s, jitter is less then 2 =B5s. But this is really depending on the=
 use case. If there would be other devices using the bus (USB, serial ...=
), the jitter will be much higher for sure. Would be worth to do some tes=
ts for that, but I'm lacking time ATM, I'm sorry. But they will be high, =
for sure.
>=20

Well, then let's draft a straight forward protocol extension: Some new
frame type shall be introduced, let's call it "Prologue Frame". It shall
look like this:

Version: 0x0202
Frame ID: 0x0020
<no further fields>

That frame is intended to serve as the timestamping reference for the
follow-up frames (sync, calibration request/reply). This means that,
instead of the RX timestamp of the succeeding frame, the RX time of the
prologue frame will be considered by the receiver. This, of course, also
means that the frame will _always_ be paired with a standard TDMA frame.

It shall be an optional frame, ie. both the sender and the receiver
don't need to issue/interpret it. If the receiver ignores it, the error
of the succeeding original frame would rise, but TDMA should still work
safely (this claim needs more thoughts, though). If the sender doesn't
issue it, all would work as before anyway.

I can't provide a helping hand on the implementation right now. So if
you are interested in drafting such an extension, only review can be
provided. The best test-case would be on your side anyway :).

Jan

Re: [RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Hello,
> > 
> > I'm currently working on getting RTnet working on an Infineon TriCore
> > 1130 and found some issues, which could be solved in the next major
> > TDMA version comming with RTnet. Would like to discuss these issues
> > to see other's opinion about that.
> > 
> > The TriCore1 architecture is a little bit tricky. When you want to
> > send a frame over Ethernet, the host (the "cpu") has to write it into
> > a shared memory (available via FPI bus). Then the host writes a
> > special register to tell the DMUT (Data Management Unit Transmit) to
> > get this Frame from shared memory and write it into Transmit Buffer
> > TB. The TX block of the MAC takes the frame from TB and sends it to
> > MII, which will put it on the wire. All this can be found in detail
> > in [1], chapter 31.
> > 
> > Here comes the problem: When sending request calibration frames, one
> > has to provide a transmission time stamp as close as possible to the
> > real transmission time. As the TriCore does not support changing the
> > frame after writing it into shared memory (by host), there is no way
> > for providing a real transmission time stamp. Only option is to put
> > the scheduled transmission time there which will have the effect,
> > that transmission time on the wire t_trans is always calculated to
> > long because the real transmission is done later.
> 
> Unless you have to make the steps of writing to the shared mem +
> triggering the transmission preemptible, the solution is simple: just
> push out the local time taken right _before_ you start writing the
> frame. For your arch, that is the point "as close as possible" to the
> real tx date.
> 
> > 
> > To fix this issue there will be a few possibilities, one comes here:
> > One could change TDMA.spec and allow slaves to send a two-parted
> > request calibration frame. First one has a don't care Transmission
> > Time stamp (marked as don't care by a bit or sth similiar). Slaves
> > will notice their transmission time stamp in their TXISR, and send it
> > in the second ReqCalFrm. This would make the whole process much more
> > precise, but of course requires changes in TDMA.spec.
> 
> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> the timestamp of the first one), IIRC. Would be possible to extend the
> specs, but there should be real hard needs for it.
> 
> Again, as long as the tx timestamp is taken at a fixed date before real
> tx, TDMA can handle this (may one should clarify the spec in this regard).
> 
> Jan
> 
Well, the problem is that FPI bus is a shared bus, which will have the effect that in some cases it may take longer until the frame is on the wire and in some cases it may take less time. As a result, the tx timestamp is _not_ taken at a fixed date before real tx.

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

Re: [RTnet-developers] some suggestions for the next TDMA version

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Hello,
>>>
>>> I'm currently working on getting RTnet working on an Infineon TriCore=

>>> 1130 and found some issues, which could be solved in the next major
>>> TDMA version comming with RTnet. Would like to discuss these issues
>>> to see other's opinion about that.
>>>
>>> The TriCore1 architecture is a little bit tricky. When you want to
>>> send a frame over Ethernet, the host (the "cpu") has to write it into=

>>> a shared memory (available via FPI bus). Then the host writes a
>>> special register to tell the DMUT (Data Management Unit Transmit) to
>>> get this Frame from shared memory and write it into Transmit Buffer
>>> TB. The TX block of the MAC takes the frame from TB and sends it to
>>> MII, which will put it on the wire. All this can be found in detail
>>> in [1], chapter 31.
>>>
>>> Here comes the problem: When sending request calibration frames, one
>>> has to provide a transmission time stamp as close as possible to the
>>> real transmission time. As the TriCore does not support changing the
>>> frame after writing it into shared memory (by host), there is no way
>>> for providing a real transmission time stamp. Only option is to put
>>> the scheduled transmission time there which will have the effect,
>>> that transmission time on the wire t_trans is always calculated to
>>> long because the real transmission is done later.
>> Unless you have to make the steps of writing to the shared mem +
>> triggering the transmission preemptible, the solution is simple: just
>> push out the local time taken right _before_ you start writing the
>> frame. For your arch, that is the point "as close as possible" to the
>> real tx date.
>>
>>> To fix this issue there will be a few possibilities, one comes here:
>>> One could change TDMA.spec and allow slaves to send a two-parted
>>> request calibration frame. First one has a don't care Transmission
>>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
>>> will notice their transmission time stamp in their TXISR, and send it=

>>> in the second ReqCalFrm. This would make the whole process much more
>>> precise, but of course requires changes in TDMA.spec.
>> Yeah, that's how NTP and PTP work as well (follow-up message carrying
>> the timestamp of the first one), IIRC. Would be possible to extend the=

>> specs, but there should be real hard needs for it.
>>
>> Again, as long as the tx timestamp is taken at a fixed date before rea=
l
>> tx, TDMA can handle this (may one should clarify the spec in this rega=
rd).
>>
>> Jan
>>
> Well, the problem is that FPI bus is a shared bus, which will have the =
effect that in some cases it may take longer until the frame is on the wi=
re and in some cases it may take less time. As a result, the tx timestamp=
 is _not_ taken at a fixed date before real tx.

OK, that sounds almost like a "hard need". What are the other users on
this bus, and who is controlling the access (host or devices)? And what
dimension would the jitter then have (10 of microseconds, more, or less)?=


Jan

Re: [RTnet-developers] some suggestions for the next TDMA version

[Karl R. <Kar...@gm...>]

Jan Kiszka wrote:
> Karl Reichert wrote:
> > Jan Kiszka wrote:
> >> Karl Reichert wrote:
> >>> Hello,
> >>>
> >>> I'm currently working on getting RTnet working on an Infineon TriCore
> >>> 1130 and found some issues, which could be solved in the next major
> >>> TDMA version comming with RTnet. Would like to discuss these issues
> >>> to see other's opinion about that.
> >>>
> >>> The TriCore1 architecture is a little bit tricky. When you want to
> >>> send a frame over Ethernet, the host (the "cpu") has to write it into
> >>> a shared memory (available via FPI bus). Then the host writes a
> >>> special register to tell the DMUT (Data Management Unit Transmit) to
> >>> get this Frame from shared memory and write it into Transmit Buffer
> >>> TB. The TX block of the MAC takes the frame from TB and sends it to
> >>> MII, which will put it on the wire. All this can be found in detail
> >>> in [1], chapter 31.
> >>>
> >>> Here comes the problem: When sending request calibration frames, one
> >>> has to provide a transmission time stamp as close as possible to the
> >>> real transmission time. As the TriCore does not support changing the
> >>> frame after writing it into shared memory (by host), there is no way
> >>> for providing a real transmission time stamp. Only option is to put
> >>> the scheduled transmission time there which will have the effect,
> >>> that transmission time on the wire t_trans is always calculated to
> >>> long because the real transmission is done later.
> >> Unless you have to make the steps of writing to the shared mem +
> >> triggering the transmission preemptible, the solution is simple: just
> >> push out the local time taken right _before_ you start writing the
> >> frame. For your arch, that is the point "as close as possible" to the
> >> real tx date.
> >>
> >>> To fix this issue there will be a few possibilities, one comes here:
> >>> One could change TDMA.spec and allow slaves to send a two-parted
> >>> request calibration frame. First one has a don't care Transmission
> >>> Time stamp (marked as don't care by a bit or sth similiar). Slaves
> >>> will notice their transmission time stamp in their TXISR, and send it
> >>> in the second ReqCalFrm. This would make the whole process much more
> >>> precise, but of course requires changes in TDMA.spec.
> >> Yeah, that's how NTP and PTP work as well (follow-up message carrying
> >> the timestamp of the first one), IIRC. Would be possible to extend the
> >> specs, but there should be real hard needs for it.
> >>
> >> Again, as long as the tx timestamp is taken at a fixed date before real
> >> tx, TDMA can handle this (may one should clarify the spec in this
> regard).
> >>
> >> Jan
> >>
> > Well, the problem is that FPI bus is a shared bus, which will have the
> effect that in some cases it may take longer until the frame is on the wire
> and in some cases it may take less time. As a result, the tx timestamp is
> _not_ taken at a fixed date before real tx.
> 
> OK, that sounds almost like a "hard need". What are the other users on
> this bus, and who is controlling the access (host or devices)? And what
> dimension would the jitter then have (10 of microseconds, more, or less)?
> 
> Jan
> 
Other users can be in general every device also connected to FPI bus. In my case, some memory is also connected to FPI, which has the effect, that host and all devices using this memory accessing the bus. As those devices may read/write async from/into the memory, there is no way to ensure stable times accessing this bus.
The dimension of the jitter is very depending on the situation. In my case, using only host and Ethernet-Controller, this value is always around 11 µs, jitter is less then 2 µs. But this is really depending on the use case. If there would be other devices using the bus (USB, serial ...), the jitter will be much higher for sure. Would be worth to do some tests for that, but I'm lacking time ATM, I'm sorry. But they will be high, for sure.

Karl
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger