Thread: [RTnet-developers] Ethernet IP
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers
|
From: Glen W. <gl...@je...> - 2010-09-28 14:23:31
|
Hi Guys, Woule you see any reason while we could not the open source Ethernet IP project on top of RTNet? Basically this builds on Linux stack but I want to run my stuff inside of it real time. For that I need a real time driver for the ethenet that emulates linux. Ethernet IP project: https://sourceforge.net/projects/opener/ Glen -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2010-09-28 20:39:54
Attachments:
signature.asc
|
Am 28.09.2010 16:22, Glen Wernersbach wrote: > Hi Guys, > > Woule you see any reason while we could not the open source Ethernet IP > project on top of RTNet? > > Basically this builds on Linux stack but I want to run my stuff inside of it > real time. For that I need a real time driver for the ethenet that emulates > linux. > > Ethernet IP project: > https://sourceforge.net/projects/opener/ I cannot asses what you could gain this way (do Ethernet IP devices provide real-time qualities via UDP/TCP?), but porting that stack over RTnet's UDP/TCP services should be feasible. The portability layer of opener looks rather thin and should be well covered by Xenomai's POSIX skin. However, our TCP implementation is still fresh, so you /may/ run into some of it current limitations. If you find such quirks, please let us know. Jan |
|
From: Glen W. <gl...@je...> - 2010-09-28 21:18:01
|
Jan, My basic concern was to keep the data flowing from the NIC to my program as close to hard real time as possible. I know doing Linux calls can break hard real time especially when I want to receive a UDP packet every 1ms. The only thing Ethernet IP really gives you real time is optional support for the Ethernet 1588 timing standard so you know what the jitter was in receiving the packet over the Ethernet line. The 1588 support is not yet implemented in opener. The rest is just a protocol for handling critical data over TCP and UDP. Unfortunately, I have a device that needs to work on Allen Bradley controllers which only support this real time protocol. All I want to do is replace the Linux calls in networkhandler.c (socket,bind,listen...) with RTAI real time calls. Glen On 9/28/10 4:39 PM, "Jan Kiszka" <jan...@we...> wrote: > Am 28.09.2010 16:22, Glen Wernersbach wrote: >> Hi Guys, >> >> Woule you see any reason while we could not the open source Ethernet IP >> project on top of RTNet? >> >> Basically this builds on Linux stack but I want to run my stuff inside of it >> real time. For that I need a real time driver for the ethenet that emulates >> linux. >> >> Ethernet IP project: >> https://sourceforge.net/projects/opener/ > > I cannot asses what you could gain this way (do Ethernet IP devices > provide real-time qualities via UDP/TCP?), but porting that stack over > RTnet's UDP/TCP services should be feasible. The portability layer of > opener looks rather thin and should be well covered by Xenomai's POSIX > skin. However, our TCP implementation is still fresh, so you /may/ run > into some of it current limitations. If you find such quirks, please let > us know. > > Jan > -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2010-09-28 21:44:50
Attachments:
signature.asc
|
Am 28.09.2010 23:17, Glen Wernersbach wrote: > Jan, > > My basic concern was to keep the data flowing from the NIC to my program as > close to hard real time as possible. I know doing Linux calls can break hard > real time especially when I want to receive a UDP packet every 1ms. Is that UDP packet part of your control loop? Why do you need the whole opener stack then? Or is there more? > > The only thing Ethernet IP really gives you real time is optional support > for the Ethernet 1588 timing standard so you know what the jitter was in > receiving the packet over the Ethernet line. The 1588 support is not yet > implemented in opener. The rest is just a protocol for handling critical > data over TCP and UDP. Unfortunately, I have a device that needs to work on > Allen Bradley controllers which only support this real time protocol. > > All I want to do is replace the Linux calls in networkhandler.c > (socket,bind,listen...) with RTAI real time calls. Additionally, you will have to configure the socket resources, namely how many buffers each socket should pre-allocate for its real-time operation (that's the major difference to normal networking stack that do on-demand allocations). See the examples. Jan |
|
From: Glen W. <gl...@je...> - 2010-09-28 21:56:23
|
In EthernetIp tcp is used for non critical data such as parameters and to set what the contents of the UDP packets are. I can only control the EthernetIP implantation on my device. Thanks, Glen -- Glen Wernersbach President & CTO Jetsoft Development Co 629 Old St. Rt. 74 - Suite 210 Cincinnati Ohio 45244 Custom Programming Web Site: www.JetsoftDev.com Retail Product Web Site: www.ScanHelp.com Phone: 513-528-6660 Fax: 513-528-3470 On Sep 28, 2010, at 5:35 PM, Jan Kiszka <jan...@we...> wrote: > Am 28.09.2010 23:17, Glen Wernersbach wrote: >> Jan, >> >> My basic concern was to keep the data flowing from the NIC to my program as >> close to hard real time as possible. I know doing Linux calls can break hard >> real time especially when I want to receive a UDP packet every 1ms. > > Is that UDP packet part of your control loop? Why do you need the whole > opener stack then? Or is there more? > >> >> The only thing Ethernet IP really gives you real time is optional support >> for the Ethernet 1588 timing standard so you know what the jitter was in >> receiving the packet over the Ethernet line. The 1588 support is not yet >> implemented in opener. The rest is just a protocol for handling critical >> data over TCP and UDP. Unfortunately, I have a device that needs to work on >> Allen Bradley controllers which only support this real time protocol. >> >> All I want to do is replace the Linux calls in networkhandler.c >> (socket,bind,listen...) with RTAI real time calls. > > Additionally, you will have to configure the socket resources, namely > how many buffers each socket should pre-allocate for its real-time > operation (that's the major difference to normal networking stack that > do on-demand allocations). See the examples. > > Jan > |
|
From: Glen W. <gl...@je...> - 2011-01-28 20:41:09
|
Jan, On you last comment below about pre allocating buffers, I am trying to find where in the RTAI examples it show that? Glen On 9/28/10 5:35 PM, "Jan Kiszka" <jan...@we...> wrote: > Am 28.09.2010 23:17, Glen Wernersbach wrote: >> Jan, >> >> My basic concern was to keep the data flowing from the NIC to my program as >> close to hard real time as possible. I know doing Linux calls can break hard >> real time especially when I want to receive a UDP packet every 1ms. > > Is that UDP packet part of your control loop? Why do you need the whole > opener stack then? Or is there more? > >> >> The only thing Ethernet IP really gives you real time is optional support >> for the Ethernet 1588 timing standard so you know what the jitter was in >> receiving the packet over the Ethernet line. The 1588 support is not yet >> implemented in opener. The rest is just a protocol for handling critical >> data over TCP and UDP. Unfortunately, I have a device that needs to work on >> Allen Bradley controllers which only support this real time protocol. >> >> All I want to do is replace the Linux calls in networkhandler.c >> (socket,bind,listen...) with RTAI real time calls. > > Additionally, you will have to configure the socket resources, namely > how many buffers each socket should pre-allocate for its real-time > operation (that's the major difference to normal networking stack that > do on-demand allocations). See the examples. > > Jan > -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2011-01-28 21:13:14
Attachments:
signature.asc
|
On 2011-01-28 21:40, Glen Wernersbach wrote: > Jan, > > On you last comment below about pre allocating buffers, I am trying to find > where in the RTAI examples it show that? It's lacking in those few RTAI examples. Check xenomai/posix and watch out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable. Jan |
|
From: Glen W. <gl...@je...> - 2011-01-28 21:33:11
|
Thanks. I will check. Verdict is still out if I can used RTAI , RTNET and TCP Here are my current troubles: 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying funciton not implemented. 2. If I skip accept and just use the original FD, I get data but when I try to rt_dev_send() back to this FD, I get a crash and a "Ooops" output 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output. Works on the TCP socket. The program works with standard linux commands. Glen On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote: > On 2011-01-28 21:40, Glen Wernersbach wrote: >> Jan, >> >> On you last comment below about pre allocating buffers, I am trying to find >> where in the RTAI examples it show that? > > It's lacking in those few RTAI examples. Check xenomai/posix and watch > out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable. > > Jan > -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2011-01-28 22:42:52
Attachments:
signature.asc
|
On 2011-01-28 22:32, Glen Wernersbach wrote: > Thanks. > > I will check. > > Verdict is still out if I can used RTAI , RTNET and TCP > Here are my current troubles: > > 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn > specifying funciton not implemented. Maybe rt_dev_accept is not properly wired up in RTAI user land though it should simply translate to an IOCTL on the rtnet fd. Check the call path, specifically if RTnet receives the IOCTL in rt_tcp_ioctl. > 2. If I skip accept and just use the original FD, I get data but when I try > to rt_dev_send() back to this FD, I get a crash and a "Ooops" output Please provide backtraces. > 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output. Our UDP does not implement shutdown, but you shouldn't get an oops. Again, we need backtraces (frame pointers enabled, please). Jan |
|
From: Glen W. <gl...@je...> - 2011-02-08 04:24:28
|
Well, I installed Xenomai and RTNET on a different distribution and basically got the same issues as in the email below. If I run accept() after select(), I get a -1 Invalid Argument error. The rest is exactly alike. I get these errors, even when I get the code as close as I can to the RTTCP_SERVER example. So there is either some problem with my insmods, some obscure program setting or I have just found problems with TCP on RTNET. At least the errors are in the same place both on RTAI and XENO_POSIX Glen On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote: > Thanks. > > I will check. > > Verdict is still out if I can used RTAI , RTNET and TCP > Here are my current troubles: > > 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying > funciton not implemented. > 2. If I skip accept and just use the original FD, I get data but when I try to > rt_dev_send() back to this FD, I get a crash and a "Ooops" output > 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output. > Works on the TCP socket. > > The program works with standard linux commands. > > Glen > > > On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote: > >> On 2011-01-28 21:40, Glen Wernersbach wrote: >>> Jan, >>> >>> On you last comment below about pre allocating buffers, I am trying to find >>> where in the RTAI examples it show that? >> >> It's lacking in those few RTAI examples. Check xenomai/posix and watch >> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable. >> >> Jan >> -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2011-02-08 11:47:52
Attachments:
signature.asc
|
On 2011-02-08 05:24, Glen Wernersbach wrote: > Well, I installed Xenomai and RTNET on a different distribution and > basically got the same issues as in the email below. > > If I run accept() after select(), I get a -1 Invalid Argument error. Do you use select() to wait on a connection request? This is obviously not yet supported by RTnet. > > The rest is exactly alike. > > I get these errors, even when I get the code as close as I can to the > RTTCP_SERVER example. Does the original example work for you? However, I think we better discuss your issues based on a self-contained test that exposed them for you. Jan > > So there is either some problem with my insmods, some obscure program > setting or I have just found problems with TCP on RTNET. > > At least the errors are in the same place both on RTAI and XENO_POSIX > > Glen > > > On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote: > >> Thanks. >> >> I will check. >> >> Verdict is still out if I can used RTAI , RTNET and TCP >> Here are my current troubles: >> >> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying >> funciton not implemented. >> 2. If I skip accept and just use the original FD, I get data but when I try to >> rt_dev_send() back to this FD, I get a crash and a "Ooops" output >> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output. >> Works on the TCP socket. >> >> The program works with standard linux commands. >> >> Glen >> >> >> On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote: >> >>> On 2011-01-28 21:40, Glen Wernersbach wrote: >>>> Jan, >>>> >>>> On you last comment below about pre allocating buffers, I am trying to find >>>> where in the RTAI examples it show that? >>> >>> It's lacking in those few RTAI examples. Check xenomai/posix and watch >>> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable. >>> >>> Jan >>> > |
|
From: Glen W. <gl...@je...> - 2011-02-08 12:18:32
|
I used select with a timeout. Select seems to work. It returns a positive number and a fdset. It is accept which does not seem to work in taking off the top packets and send or write oopses the machine. Accept does seem to work if I run it before select. We can try the example but then I have to set up another machine. Could any of thus be e1000 driver? -- Glen Wernersbach President & CTO Jetsoft Development Co 629 Old St. Rt. 74 - Suite 210 Cincinnati Ohio 45244 Custom Programming Web Site: www.JetsoftDev.com Retail Product Web Site: www.ScanHelp.com Phone: 513-528-6660 Fax: 513-528-3470 On Feb 8, 2011, at 6:47 AM, Jan Kiszka <jan...@we...> wrote: > On 2011-02-08 05:24, Glen Wernersbach wrote: >> Well, I installed Xenomai and RTNET on a different distribution and >> basically got the same issues as in the email below. >> >> If I run accept() after select(), I get a -1 Invalid Argument error. > > Do you use select() to wait on a connection request? This is obviously > not yet supported by RTnet. > >> >> The rest is exactly alike. >> >> I get these errors, even when I get the code as close as I can to the >> RTTCP_SERVER example. > > Does the original example work for you? > > However, I think we better discuss your issues based on a self-contained > test that exposed them for you. > > Jan > > >> >> So there is either some problem with my insmods, some obscure program >> setting or I have just found problems with TCP on RTNET. >> >> At least the errors are in the same place both on RTAI and XENO_POSIX >> >> Glen >> >> >> On 1/28/11 4:32 PM, "Glen Wernersbach" <gl...@je...> wrote: >> >>> Thanks. >>> >>> I will check. >>> >>> Verdict is still out if I can used RTAI , RTNET and TCP >>> Here are my current troubles: >>> >>> 1. rt_dev_Accept() seems to return ether -9,-22,-38 with the errorn specifying >>> funciton not implemented. >>> 2. If I skip accept and just use the original FD, I get data but when I try to >>> rt_dev_send() back to this FD, I get a crash and a "Ooops" output >>> 3. If I issue a rt_dev_shutdown() on a UDP socket, I get an "Ooops' output. >>> Works on the TCP socket. >>> >>> The program works with standard linux commands. >>> >>> Glen >>> >>> >>> On 1/28/11 4:13 PM, "Jan Kiszka" <jan...@we...> wrote: >>> >>>> On 2011-01-28 21:40, Glen Wernersbach wrote: >>>>> Jan, >>>>> >>>>> On you last comment below about pre allocating buffers, I am trying to find >>>>> where in the RTAI examples it show that? >>>> >>>> It's lacking in those few RTAI examples. Check xenomai/posix and watch >>>> out for RTNET_RTIOC_EXTPOOL. I think that should be trivially transferable. >>>> >>>> Jan >>>> >> > > |
|
From: Jan K. <jan...@we...> - 2011-02-08 12:24:25
Attachments:
signature.asc
|
On 2011-02-08 13:18, Glen Wernersbach wrote: > I used select with a timeout. Select seems to work. It returns a positive number and a fdset. > > It is accept which does not seem to work in taking off the top packets and send or write oopses the machine. > > Accept does seem to work if I run it before select. Given that this is not the pattern we tested so far (actually, the whole server side TCP implementation was only "for fun", real use cases were only clients so far) nor is it supposed to work based on the existing logic, you may have triggered a BUG path. > > We can try the example but then I have to set up another machine. Or provide your test for local reproduction. > > Could any of thus be e1000 driver? Test via rtlo instead. Jan |
|
From: Glen W. <gl...@je...> - 2011-02-08 14:28:22
|
Jan, The project I am trying to make real time is: http://sourceforge.net/projects/opener/ It is hard to give a test case because my other side of this is an Allen Bradley controller. This project does work in standard Linux but then I have to deal with OS latencies from the card to my real time program. Here is my current thought. The code as written in your example works. If I run accept() before select, accept() always returns the same file descriptor as was put it. Is this a a limitation of RTNET? Also, it appear that select() without accept() and you can read() successfully. I can probably work around the above. Now I need to focus on why Send or Write are "oops"ing. The only difference between my code and your example is that I am not setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try these this mourning. The only other reason this could be "oops"ing is that I am reading and writing on the same socket and your example does not. I will let you know. Glen P.S. At least now I know I can go back to RTAI if I want. The rest of our project works in RTAI. On 2/8/11 7:24 AM, "Jan Kiszka" <jan...@we...> wrote: > On 2011-02-08 13:18, Glen Wernersbach wrote: >> I used select with a timeout. Select seems to work. It returns a positive >> number and a fdset. >> >> It is accept which does not seem to work in taking off the top packets and >> send or write oopses the machine. >> >> Accept does seem to work if I run it before select. > > Given that this is not the pattern we tested so far (actually, the whole > server side TCP implementation was only "for fun", real use cases were > only clients so far) nor is it supposed to work based on the existing > logic, you may have triggered a BUG path. > >> >> We can try the example but then I have to set up another machine. > > Or provide your test for local reproduction. > >> >> Could any of thus be e1000 driver? > > Test via rtlo instead. > > Jan > -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@we...> - 2011-02-08 14:49:25
Attachments:
signature.asc
|
On 2011-02-08 15:27, Glen Wernersbach wrote: > Jan, > > The project I am trying to make real time is: > http://sourceforge.net/projects/opener/ > > It is hard to give a test case because my other side of this is an Allen I'm primarily interested in the connection setup pattern which should be extractable into a set of two simple test applications. > Bradley controller. This project does work in standard Linux but then I have > to deal with OS latencies from the card to my real time program. > > Here is my current thought. The code as written in your example works. If I > run accept() before select, accept() always returns the same file descriptor > as was put it. Is this a a limitation of RTNET? Yes, see Documentation/README.tcp. > > Also, it appear that select() without accept() and you can read() > successfully. Are you implementing a server or a client? A server without accept would be weird, and a client with it just as well. > > I can probably work around the above. Wrong approach, likely doomed to blow up at a different end later on. > > Now I need to focus on why Send or Write are "oops"ing. If you don't post it, you will have to parse it on your own... > > The only difference between my code and your example is that I am not > setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try > these this mourning. > > The only other reason this could be "oops"ing is that I am reading and > writing on the same socket and your example does not. We do in a less trivial application in the field. No complains from my colleagues so far. > > I will let you know. > > Glen > > P.S. At least now I know I can go back to RTAI if I want. The rest of our > project works in RTAI. OTOH, analysis is easier elsewhere. Jan |
|
From: Anders B. <and...@co...> - 2011-02-08 15:29:10
|
On 2011-02-08 15.49, Jan Kiszka wrote: > On 2011-02-08 15:27, Glen Wernersbach wrote: >> Jan, >> >> The project I am trying to make real time is: >> http://sourceforge.net/projects/opener/ >> >> It is hard to give a test case because my other side of this is an Allen > > I'm primarily interested in the connection setup pattern which should be > extractable into a set of two simple test applications. > >> Bradley controller. This project does work in standard Linux but then I have >> to deal with OS latencies from the card to my real time program. >> >> Here is my current thought. The code as written in your example works. If I >> run accept() before select, accept() always returns the same file descriptor >> as was put it. Is this a a limitation of RTNET? > > Yes, see Documentation/README.tcp. > >> >> Also, it appear that select() without accept() and you can read() >> successfully. > > Are you implementing a server or a client? A server without accept would > be weird, and a client with it just as well. > >> >> I can probably work around the above. > > Wrong approach, likely doomed to blow up at a different end later on. > >> >> Now I need to focus on why Send or Write are "oops"ing. > > If you don't post it, you will have to parse it on your own... > >> >> The only difference between my code and your example is that I am not >> setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try >> these this mourning. >> >> The only other reason this could be "oops"ing is that I am reading and >> writing on the same socket and your example does not. > > We do in a less trivial application in the field. No complains from my > colleagues so far. With raw sockets I have problems reading and writing from/to the same socket when done from different threads (on my todo list to track this down some time in the future), might this be the same problem? > >> >> I will let you know. >> >> Glen >> >> P.S. At least now I know I can go back to RTAI if I want. The rest of our >> project works in RTAI. > > OTOH, analysis is easier elsewhere. /Anders -- Anders Blomdell Email: and...@co... Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden |
|
From: Anders B. <and...@co...> - 2011-02-08 15:52:32
|
On 02/08/2011 04:03 PM, Jan Kiszka wrote: > On 2011-02-08 16:00, Anders Blomdell wrote: >>>> The only other reason this could be "oops"ing is that I am reading and >>>> writing on the same socket and your example does not. >>> >>> We do in a less trivial application in the field. No complains from my >>> colleagues so far. >> With raw sockets I have problems reading and writing from/to the same socket >> when done from different threads (on my todo list to track this down some time >> in the future), might this be the same problem? > > You mean one thread reads and another writes? Or both mixed? What kind of > problems? At least with one thread reading and one writing. Some errno which I cant exctly recall (9x, something, might have been EADDRINUSE, but I'm not sure). My workaround was to read from the socket with a timeout, that way I was able to do everything in one thread (yes, I know it's not a long term solution). /Anders -- Anders Blomdell Email: and...@co... Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden |
|
From: Jan K. <jan...@we...> - 2011-02-08 15:56:09
Attachments:
signature.asc
|
On 2011-02-08 16:52, Anders Blomdell wrote: > On 02/08/2011 04:03 PM, Jan Kiszka wrote: >> On 2011-02-08 16:00, Anders Blomdell wrote: >>>>> The only other reason this could be "oops"ing is that I am reading and >>>>> writing on the same socket and your example does not. >>>> >>>> We do in a less trivial application in the field. No complains from my >>>> colleagues so far. >>> With raw sockets I have problems reading and writing from/to the same >>> socket >>> when done from different threads (on my todo list to track this down >>> some time >>> in the future), might this be the same problem? >> >> You mean one thread reads and another writes? Or both mixed? What kind of >> problems? > At least with one thread reading and one writing. > Some errno which I cant exctly recall (9x, something, might have been > EADDRINUSE, but I'm not sure). 98 == EADDRINUSE. But that's only thrown by UDP and TCP, not AF_PACKET. > My workaround was to read from the socket > with a timeout, that way I was able to do everything in one thread (yes, > I know it's not a long term solution). Maybe there is same race and some missing locking. I would be interested to hear more details / see a test case when you find some time. Thanks, Jan |
|
From: Glen W. <gl...@je...> - 2011-02-09 14:19:07
|
Jan, I think I figured out the send error. With RTNET I cannot receive and send on the same socket. So I cannot with RTNET do the follow that works with Linux: 1. Socket 2. SetSocketOpts 3. Bind 4. Listen 5. Accept 6. Recv 7. Send 8. close ------ I can however with RTNET do the following: 1. Socket 2. SetSocketOpts 3. Bind 4. Listen 5. Accept 6. Recv 7. Close ------ 8. Socket 9. SetSocketOpts 10. Bind 11. Connect 12. Send 13. Close The second seemed to work. Does this makes sense to you? Glen On 2/8/11 9:49 AM, "Jan Kiszka" <jan...@we...> wrote: > On 2011-02-08 15:27, Glen Wernersbach wrote: >> Jan, >> >> The project I am trying to make real time is: >> http://sourceforge.net/projects/opener/ >> >> It is hard to give a test case because my other side of this is an Allen > > I'm primarily interested in the connection setup pattern which should be > extractable into a set of two simple test applications. > >> Bradley controller. This project does work in standard Linux but then I have >> to deal with OS latencies from the card to my real time program. >> >> Here is my current thought. The code as written in your example works. If I >> run accept() before select, accept() always returns the same file descriptor >> as was put it. Is this a a limitation of RTNET? > > Yes, see Documentation/README.tcp. > >> >> Also, it appear that select() without accept() and you can read() >> successfully. > > Are you implementing a server or a client? A server without accept would > be weird, and a client with it just as well. > >> >> I can probably work around the above. > > Wrong approach, likely doomed to blow up at a different end later on. > >> >> Now I need to focus on why Send or Write are "oops"ing. > > If you don't post it, you will have to parse it on your own... > >> >> The only difference between my code and your example is that I am not >> setting the same socket options SO_KEEPALIVE and SO_SNDTIMEO. I will try >> these this mourning. >> >> The only other reason this could be "oops"ing is that I am reading and >> writing on the same socket and your example does not. > > We do in a less trivial application in the field. No complains from my > colleagues so far. > >> >> I will let you know. >> >> Glen >> >> P.S. At least now I know I can go back to RTAI if I want. The rest of our >> project works in RTAI. > > OTOH, analysis is easier elsewhere. > > Jan > -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@si...> - 2011-02-09 14:24:48
|
On 2011-02-09 15:18, Glen Wernersbach wrote: > Jan, > > I think I figured out the send error. > > With RTNET I cannot receive and send on the same socket. > > So I cannot with RTNET do the follow that works with Linux: > 1. Socket > 2. SetSocketOpts > 3. Bind > 4. Listen > 5. Accept > 6. Recv > 7. Send > 8. close > ------ > > I can however with RTNET do the following: > 1. Socket > 2. SetSocketOpts > 3. Bind > 4. Listen > 5. Accept > 6. Recv > 7. Close > ------ > 8. Socket > 9. SetSocketOpts > 10. Bind > 11. Connect > 12. Send > 13. Close > > The second seemed to work. > > Does this makes sense to you? Not yet. You once said accept() fails, but your setup starts to diverge after recv() (by doing a send()). What errors do which services return? Did you check that you have sufficient buffers configured for your network load (RTNET_RTIOC_EXTPOOL)? Again, it's _much_ easier if you stick this simple setup in a generic test case. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: Glen W. <gl...@je...> - 2011-02-09 14:58:46
|
My current theory is that with RTNET you need a Connect() to do a Send(). Connect() only works if a socket is not in listen(). Not sure what happens yet if I change the send() to a sentto() if the first example On Xenomai , Sent() does not error. it just blocks. On RTAI, it produces an "oops". I have extended the pools via RTNET_RTIOC_EXTPOOL to both 30 and 1024 with no effect on above. On 2/9/11 9:24 AM, "Jan Kiszka" <jan...@si...> wrote: > On 2011-02-09 15:18, Glen Wernersbach wrote: >> Jan, >> >> I think I figured out the send error. >> >> With RTNET I cannot receive and send on the same socket. >> >> So I cannot with RTNET do the follow that works with Linux: >> 1. Socket >> 2. SetSocketOpts >> 3. Bind >> 4. Listen >> 5. Accept >> 6. Recv >> 7. Send >> 8. close >> ------ >> >> I can however with RTNET do the following: >> 1. Socket >> 2. SetSocketOpts >> 3. Bind >> 4. Listen >> 5. Accept >> 6. Recv >> 7. Close >> ------ >> 8. Socket >> 9. SetSocketOpts >> 10. Bind >> 11. Connect >> 12. Send >> 13. Close >> >> The second seemed to work. >> >> Does this makes sense to you? > > Not yet. You once said accept() fails, but your setup starts to diverge > after recv() (by doing a send()). What errors do which services return? > Did you check that you have sufficient buffers configured for your > network load (RTNET_RTIOC_EXTPOOL)? > > Again, it's _much_ easier if you stick this simple setup in a generic > test case. > > Thanks, > Jan -- Glen Wernersbach President & CTO Jetsoft Development Co. 629 Old St Rt. 74 Suite 210 Cincinnati, Oh 45244 Custom Programming Web Site: www.jetsoftdev.com Retail Products Web Site: www.scanhelp.com Phone: 513-528-6660 Fax: 513-528-3470 ---- "Support Dyslexia Research" |
|
From: Jan K. <jan...@si...> - 2011-02-09 15:25:40
|
On 2011-02-09 15:58, Glen Wernersbach wrote: > My current theory is that with RTNET you need a Connect() to do a Send(). That would be clearly a bug. I still can't see how this may happen, though. > > Connect() only works if a socket is not in listen(). You either accept connections or you establish them. I'm not sure if switching between both stats is even a valid transition. > > Not sure what happens yet if I change the send() to a sentto() if the first > example send, sendto, sendmsg, write - they all end up in the same handler internally. Target address is ignored. > > On Xenomai , Sent() does not error. it just blocks. On RTAI, it produces an > "oops". [/me still waiting for a kernel log] The fact that Xenomai blocks likely means, the socket is in TCP_ESTABLISHED state. "Just" the communication fails or something else prevents the RTnet side to consider its TX window open. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: Jan K. <jan...@si...> - 2011-02-09 16:35:34
|
On 2011-02-09 17:31, Glen Wernersbach wrote: > Jan, I did a kernel message while my send command was blocking > > It said > RTNET host 10.82.88.249 unreachable. > > 10.82.88.249 is the NIC I received the packette on. That, first of all, means you are lacking a host route from your RTnet node to that target. Check with rtroute, see README.routing for more info. But I was referring to that oops you mentioned under RTAI. It may point to an issue in the stack. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
|
From: Glen W. <gl...@je...> - 2011-02-09 16:54:20
|
I have 10.82.88.249 with my Mac address in my rtroute table. I can receive from it but can't send back to the same socket. I think this may be the connect() issue. I will be getting a kernel dump when I get back to rtai but I would like to get xenomai working if possible. -- Glen Wernersbach President & CTO Jetsoft Development Co 629 Old St. Rt. 74 - Suite 210 Cincinnati Ohio 45244 Custom Programming Web Site: www.JetsoftDev.com Retail Product Web Site: www.ScanHelp.com Phone: 513-528-6660 Fax: 513-528-3470 On Feb 9, 2011, at 11:35 AM, Jan Kiszka <jan...@si...> wrote: > On 2011-02-09 17:31, Glen Wernersbach wrote: >> Jan, I did a kernel message while my send command was blocking >> >> It said >> RTNET host 10.82.88.249 unreachable. >> >> 10.82.88.249 is the NIC I received the packette on. > > That, first of all, means you are lacking a host route from your RTnet > node to that target. Check with rtroute, see README.routing for more info. > > But I was referring to that oops you mentioned under RTAI. It may point > to an issue in the stack. > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > |
|
From: Jan K. <jan...@si...> - 2011-02-09 16:59:58
|
On 2011-02-09 17:53, Glen Wernersbach wrote: > I have 10.82.88.249 with my Mac address in my rtroute table. You mean with the right MAC of that remote host, no? > I can receive from it but can't send back to the same socket. > > I think this may be the connect() issue. Does rtping 10.82.88.249 work? > > I will be getting a kernel dump when I get back to rtai but I would like to get xenomai working if possible. > OK. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X