May-9th-2019, 11:08 AM
(This post was last modified: May-9th-2019, 11:09 AM by Armin@netPI.)
Hello Andi,
I want to share with you the information I collected.
I have to tell you that indeed netX and the container's ethernet port implementation will drop ethernet frames at higher bus loads. The interface cannot be compared to a native ethernet port such as eth0 supported by netPI as well ... netX ethernet port is and will be always a bottleneck and is driven through a user space driver and not kernel driver as it is usual.
The reason lies in the very nature of the design. First of all the 25Mhz speed of the SPI interface between raspberry CPU and netX is a limiting factor. As next the established mailbox system to collect incoming traffic and to it send out consumes a lot of time for handshaking in between and all this is executed in polling mode and not in interrupt mode. Another reason is the 8 traffice message deep ethernet frame buffer established between both chips. If it is overloaded then frames are dropped as well.
Of course even if frames are dropped with TCP/IP based communications there is no problem at all since the protocol includes recovery mechanisms to resend lost packages or to detect them. I agree that it will slow down the effective data rate, but it works fine. So overall the cifx0 is an interface that can be well used as service interface e.g. Codesys PLC programming port. If there is a needs for a high performance interface cifx0 is not suitable.
P.S: what I was never able to see are lost ping packages if there is no other network load active over the same network.
Thx
Armin
I want to share with you the information I collected.
I have to tell you that indeed netX and the container's ethernet port implementation will drop ethernet frames at higher bus loads. The interface cannot be compared to a native ethernet port such as eth0 supported by netPI as well ... netX ethernet port is and will be always a bottleneck and is driven through a user space driver and not kernel driver as it is usual.
The reason lies in the very nature of the design. First of all the 25Mhz speed of the SPI interface between raspberry CPU and netX is a limiting factor. As next the established mailbox system to collect incoming traffic and to it send out consumes a lot of time for handshaking in between and all this is executed in polling mode and not in interrupt mode. Another reason is the 8 traffice message deep ethernet frame buffer established between both chips. If it is overloaded then frames are dropped as well.
Of course even if frames are dropped with TCP/IP based communications there is no problem at all since the protocol includes recovery mechanisms to resend lost packages or to detect them. I agree that it will slow down the effective data rate, but it works fine. So overall the cifx0 is an interface that can be well used as service interface e.g. Codesys PLC programming port. If there is a needs for a high performance interface cifx0 is not suitable.
P.S: what I was never able to see are lost ping packages if there is no other network load active over the same network.
Thx
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)