Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Technology/Not real-time enough/List of Posts
Forum Topic - Not real-time enough: (10 Items)
   
Update
Mario Charest
09/21/2012 11:24 AM
post95739
Not real-time enough   
Any of the network guru want to take a look at my support caser CaseID0011655.  In a nutshell I have demonstrated a case
 where UDP packets will get drop be the stack eventhough we have a very high priority thread reading the packets.  The 
packets are dropped because the stack is apparently busy doing something else.

That seems very conter-intuitive and I would expect io-pkt-v4 NOT to dropped packet for that reason.
Armin Steinhoff
09/21/2012 11:39 AM
post95740
Re: Not real-time enough   
Hi Mario,

if you need a true real-time network based on Ethernet ... we will 
release in October the support of the fieldbus Varan: 
http://www.varan-bus.net/index_en.htm

Cheers

--Armin

http://www.steinhoff-automation.com


Mario Charest wrote:
> Any of the network guru want to take a look at my support caser CaseID0011655.  In a nutshell I have demonstrated a 
case where UDP packets will get drop be the stack eventhough we have a very high priority thread reading the packets.  
The packets are dropped because the stack is apparently busy doing something else.
>
> That seems very conter-intuitive and I would expect io-pkt-v4 NOT to dropped packet for that reason.
>
>
>
> _______________________________________________
>
> Technology
> http://community.qnx.com/sf/go/post95739
> To cancel your subscription to this discussion, please e-mail technology-networking-unsubscribe@community.qnx.com
>
Mario Charest
09/21/2012 12:07 PM
post95742
Re: Not real-time enough   
Oups sorry: 00116551.

 Thanks
Nick Reilly
09/21/2012 1:47 PM
post95747
Re: Not real-time enough   
Hi Mario,
Whilst some areas in io-pkt are multi-threaded, there is a single "stack context" used for some operations  within io-
pkt. I believe that the issue you are running in to is that packet reception in to the socket buffer and draining of the
 socket buffer out to the application both require the stack context. Also the receiving of packets into socket buffers 
is prioritised over the draining of the socket buffers out to the application.

If you do send enough packets in then you can end up with the socket buffer overflowing and the packet dropping. This 
will show with "netstat -p udp" showing an incrementing "dropped due to full socket buffers" count.

Unfortunately there isn't a quick fix that I can see for this issue.  The prioritisation of reception of packets over 
playout to the application is deeply embedded in io-pkt and was chosen to improve the "fastforward" throughput.

If this is just a small overflow then increasing the size of the socket buffer may help. Also try and ensure that the 
minimum number of packets are seen by io-pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast 
traffic that it sees.
Mario Charest
09/21/2012 2:49 PM
post95748
RE: Not real-time enough   
Thanks for the explanation.  The receive udp buffer is already set at 160k which I think is close to the maximum (not 
sure where this number comes from ), but given that we use jumbo frame its only about 17 packets.  Any way I could use a
 buffer bigger then 160k.  The increase potential latency wouldn`t be an issue for use.  I saw a post about using net.
inetd.udp.recvspace but apparently is causing problem (http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/
discussion.bsp.topc21336), that post got no response. 

Cheers,

> -----Message d'origine-----
> De : Nick Reilly [mailto:community-noreply@qnx.com]
> Envoyé : 21 septembre 2012 13:48
> À : technology-networking
> Objet : Re: Not real-time enough
> 
> Hi Mario,
> Whilst some areas in io-pkt are multi-threaded, there is a single "stack
> context" used for some operations  within io-pkt. I believe that the issue you
> are running in to is that packet reception in to the socket buffer and draining
> of the socket buffer out to the application both require the stack context. Also
> the receiving of packets into socket buffers is prioritised over the draining of
> the socket buffers out to the application.
> 
> If you do send enough packets in then you can end up with the socket buffer
> overflowing and the packet dropping. This will show with "netstat -p udp"
> showing an incrementing "dropped due to full socket buffers" count.
> 
> Unfortunately there isn't a quick fix that I can see for this issue.  The
> prioritisation of reception of packets over playout to the application is deeply
> embedded in io-pkt and was chosen to improve the "fastforward" throughput.
> 
> If this is just a small overflow then increasing the size of the socket buffer may
> help. Also try and ensure that the minimum number of packets are seen by io-
> pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast
> traffic that it sees.
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post95747
> To cancel your subscription to this discussion, please e-mail technology-
> networking-unsubscribe@community.qnx.com
Mario Charest
09/21/2012 2:56 PM
post95749
RE: Not real-time enough   
Was thinking, too bad there isn`t a simple API to get all the buffered UDP packets in one call instead of having to go 
through multiple read(), may not fix the issue but seems to me it could maybe reduce its likelyness.

> -----Message d'origine-----
> De : Nick Reilly [mailto:community-noreply@qnx.com]
> Envoyé : 21 septembre 2012 13:48
> À : technology-networking
> Objet : Re: Not real-time enough
> 
> Hi Mario,
> Whilst some areas in io-pkt are multi-threaded, there is a single "stack
> context" used for some operations  within io-pkt. I believe that the issue you
> are running in to is that packet reception in to the socket buffer and draining
> of the socket buffer out to the application both require the stack context. Also
> the receiving of packets into socket buffers is prioritised over the draining of
> the socket buffers out to the application.
> 
> If you do send enough packets in then you can end up with the socket buffer
> overflowing and the packet dropping. This will show with "netstat -p udp"
> showing an incrementing "dropped due to full socket buffers" count.
> 
> Unfortunately there isn't a quick fix that I can see for this issue.  The
> prioritisation of reception of packets over playout to the application is deeply
> embedded in io-pkt and was chosen to improve the "fastforward" throughput.
> 
> If this is just a small overflow then increasing the size of the socket buffer may
> help. Also try and ensure that the minimum number of packets are seen by io-
> pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast
> traffic that it sees.
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post95747
> To cancel your subscription to this discussion, please e-mail technology-
> networking-unsubscribe@community.qnx.com
Mario Charest
09/21/2012 3:03 PM
post95750
RE: Not real-time enough   
UDP is on NIC2 and QNET is on NICE1 so I guess having two io-pkt would help in our case. I don`t like the idea though 
because it creates major headache for us, but if that is the only solution ;-(

> -----Message d'origine-----
> De : Nick Reilly [mailto:community-noreply@qnx.com]
> Envoyé : 21 septembre 2012 13:48
> À : technology-networking
> Objet : Re: Not real-time enough
> 
> Hi Mario,
> Whilst some areas in io-pkt are multi-threaded, there is a single "stack
> context" used for some operations  within io-pkt. I believe that the issue you
> are running in to is that packet reception in to the socket buffer and draining
> of the socket buffer out to the application both require the stack context. Also
> the receiving of packets into socket buffers is prioritised over the draining of
> the socket buffers out to the application.
> 
> If you do send enough packets in then you can end up with the socket buffer
> overflowing and the packet dropping. This will show with "netstat -p udp"
> showing an incrementing "dropped due to full socket buffers" count.
> 
> Unfortunately there isn't a quick fix that I can see for this issue.  The
> prioritisation of reception of packets over playout to the application is deeply
> embedded in io-pkt and was chosen to improve the "fastforward" throughput.
> 
> If this is just a small overflow then increasing the size of the socket buffer may
> help. Also try and ensure that the minimum number of packets are seen by io-
> pkt e.g. ensure the driver isn't in promiscuous mode and limit the broadcast
> traffic that it sees.
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post95747
> To cancel your subscription to this discussion, please e-mail technology-
> networking-unsubscribe@community.qnx.com
Nick Reilly
09/21/2012 3:19 PM
post95751
Re: RE: Not real-time enough   
I think unfortunately splitting in to two io-pkt stacks may be the best.

As you are jumbos you're not going to get that many more packets in without hitting 27386. Adding a whole new API 
involving even more locking stuff on the sockbuf would likely be counter productive, you could always switch to TCP 
instead.
Mario Charest
09/21/2012 3:50 PM
post95755
RE: RE: Not real-time enough   

> -----Message d'origine-----
> De : Nick Reilly [mailto:community-noreply@qnx.com]
> Envoyé : 21 septembre 2012 15:19
> À : technology-networking
> Objet : Re: RE: Not real-time enough
> 
> I think unfortunately splitting in to two io-pkt stacks may be the best.
> 
> As you are jumbos you're not going to get that many more packets in without
> hitting 27386.

 27386???

> Adding a whole new API involving even more locking stuff on
> the sockbuf would likely be counter productive, you could always switch to
> TCP instead.

Can't, the sender is not under our control.

> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post95751
> To cancel your subscription to this discussion, please e-mail technology-
> networking-unsubscribe@community.qnx.com
Nick Reilly
09/21/2012 3:49 PM
post95756
Re: RE: RE: Not real-time enough   
> > As you are jumbos you're not going to get that many more packets in without
> > hitting 27386.
> 
>  27386???

The tracking number for the known issue with increasing net.inet.udp.recvspace that was mentioned in the other post you 
quoted.

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems