Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Packet delay during PROFINET realtime communication

Hey, We're having a recurring issue with a PROFINET communication between a main CPU and different clients. The main CPU receives data from the clients every 2 ms and sends back an acknowledge for each received packet. If the client does not get the acknowlege within a defined timeout (in this case 12 ms), it terminates the communication by sending an alert.

The captures were made by a Siemens technician. He configured a span port on the PROFINET switch where the CPU is connected to. For the client capture he installed another PROFINET switch between the client and our Cisco access switch. Both captures are showing the traffic of the uplink port to our Cisco environment.

The capture from the CPU side looks good. The CPU receives data packets from different clients and acknowleges them immediatly.

The capture from the client side shows, that the acknowleges from the CPU are missing at some certain point. After 12 ms the client sends the alert and 6 ms later all missing acknowleges from the CPU are comming in, including the response to the clients alert.

It's always this behaviour, but not for all clients at the same time. It happens randomly for each of the clients. We've already raised the timeout for the communication, and this just leads into more missing acknowledges until the client sends it alert.

The CPU and the clients are in the same VLAN. The CPU is connected to a PROFINET switch, which has a 1 Gbit/s copper uplink to one of our Cisco access switches. The clients are connected directly to different Cisco access switches. All Cisco access switches are having a 2 x 1 Gbit/s LACP uplink to the core switches in the data center. The RTT between Client and CPU is 1 ms.

It happens only during the working hours, so it sounds like an bandwidth issue on one of the uplinks (probably on the CPU side), and that the switch queues the small packets until the uplink is free again. But then I would assume, that the communication to the other PROFINET clients would terminate as well. And why are all the missing packets are comming in as soon as the alert was sent? There are also no other known delay issues at the employees clients which are connected to the access switches.

FYI: Due to the fact that the PROFILINK frames are sometimes too small for the Ethernet network, the access switch ports for the devices are configured as trunk port (with native and allowed VLAN = PROFINET VLAN) to add the VLAN header to all the frames. According to Cisco this is a known workaround for PROFINET communication over non-PROFINET switches.

CPU: ac:64:17:cf:44:cf Client: 10:df:fc:e3:20:84 Other clients: 10:df:fc:6c:5e:18, 10:df:fc:70:31:56, 10:df:fc:e0:62:4e, ac:64:17:84:2c:eb

Server Client

Any ideas? Thank you. Jas Man

Packet delay during PROFINET realtime communication

Hey, We're having a recurring issue with a PROFINET communication between a main CPU and different clients. The main CPU receives data from the clients every 2 ms and sends back an acknowledge for each received packet. If the client does not get the acknowlege within a defined timeout (in this case 12 ms), it terminates the communication by sending an alert.

The captures were made by a Siemens technician. He configured a span port on the PROFINET switch where the CPU is connected to. For the client capture he installed another PROFINET switch between the client and our Cisco access switch. Both captures are showing the traffic of the uplink port to our Cisco environment.

The capture from the CPU side looks good. The CPU receives data packets from different clients and acknowleges them immediatly.

The capture from the client side shows, that the acknowleges from the CPU are missing at some certain point. After 12 ms the client sends the alert and 6 ms later all missing acknowleges from the CPU are comming in, including the response to the clients alert.

It's always this behaviour, but not for all clients at the same time. It happens randomly for each of the clients. We've already raised the timeout for the communication, and this just leads into more missing acknowledges until the client sends it alert.

The CPU and the clients are in the same VLAN. The CPU is connected to a PROFINET switch, which has a 1 Gbit/s copper uplink to one of our Cisco access switches. The clients are connected directly to different Cisco access switches. All Cisco access switches are having a 2 x 1 Gbit/s LACP uplink to the core switches in the data center. The RTT between Client and CPU is 1 ms.

It happens only during the working hours, so it sounds like an bandwidth issue on one of the uplinks (probably on the CPU side), and that the switch queues the small packets until the uplink is free again. But then I would assume, that the communication to the other PROFINET clients would terminate as well. And why are all the missing packets are comming in as soon as the alert was sent? There are also no other known delay issues at the employees clients which are connected to the access switches.

FYI: Due to the fact that the PROFILINK frames are sometimes too small for the Ethernet network, the access switch ports for the devices are configured as trunk port (with native and allowed VLAN = PROFINET VLAN) to add the VLAN header to all the frames. According to Cisco this is a known workaround for PROFINET communication over non-PROFINET switches.

  • CPU: ac:64:17:cf:44:cf ac:64:17:cf:44:cf
  • Client: 10:df:fc:e3:20:84 10:df:fc:e3:20:84
  • Other clients: 10:df:fc:6c:5e:18, 10:df:fc:70:31:56, 10:df:fc:e0:62:4e, ac:64:17:84:2c:eb

    ServerCPU Capture ClientClient Capture

Any ideas? ideas?

Thank you.

Jas Man

Packet delay during PROFINET realtime communication

Hey, Hey,

We're having a recurring issue with a PROFINET communication between a main CPU and different clients. The main CPU receives data from the clients every 2 ms and sends back an acknowledge for each received packet. If the client does not get the acknowlege within a defined timeout (in this case 12 ms), it terminates the communication by sending an alert.

The captures were made by a Siemens technician. He configured a span port on the PROFINET switch where the CPU is connected to. For the client capture he installed another PROFINET switch between the client and our Cisco access switch. Both captures are showing the traffic of the uplink port to our Cisco environment.

The capture from the CPU side looks good. The CPU receives data packets from different clients and acknowleges them immediatly.

The capture from the client side shows, that the acknowleges from the CPU are missing at some certain point. After 12 ms the client sends the alert and 6 ms later all missing acknowleges from the CPU are comming in, including the response to the clients alert.

It's always this behaviour, but not for all clients at the same time. It happens randomly for each of the clients. We've already raised the timeout for the communication, and this just leads into more missing acknowledges until the client sends it alert.

The CPU and the clients are in the same VLAN. The CPU is connected to a PROFINET switch, which has a 1 Gbit/s copper uplink to one of our Cisco access switches. The clients are connected directly to different Cisco access switches. All Cisco access switches are having a 2 x 1 Gbit/s LACP uplink to the core switches in the data center. The RTT between Client and CPU is 1 ms.

It happens only during the working hours, so it sounds like an bandwidth issue on one of the uplinks (probably on the CPU side), and that the switch queues the small packets until the uplink is free again. But then I would assume, that the communication to the other PROFINET clients would terminate as well. And why are all the missing packets are comming in as soon as the alert was sent? There are also no other known delay issues at the employees clients which are connected to the access switches.

FYI: Due to the fact that the PROFILINK frames are sometimes too small for the Ethernet network, the access switch ports for the devices are configured as trunk port (with native and allowed VLAN = PROFINET VLAN) to add the VLAN header to all the frames. According to Cisco this is a known workaround for PROFINET communication over non-PROFINET switches.

  • CPU: ac:64:17:cf:44:cf
  • Client: 10:df:fc:e3:20:84
  • Other clients: 10:df:fc:6c:5e:18, 10:df:fc:70:31:56, 10:df:fc:e0:62:4e, ac:64:17:84:2c:eb

    CPU Capture Client Capture

Any ideas?

Thank you.

Jas Man