- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Hello TI-support-Team,
we have a customer that faces some issues with your TI PHY DP83867 and Cisco-Switches.
TI already confirmed this issue at customer's and also our side, so I am creating this ticket to get attention for this topic and to initiate the search for a solution.
Here is our customer's issue description:
they have problems with the PHY DP83867 on SA7.
The problem is called 'IPG/IFG 8 Byte issue', TI already confirmed the topic.
Here you will find some detailed explanation why we see the CRC-errors (loss of data-packages) on the conga-SA7:
On the module we use our Audio-over-IP (AoIP) - device.
AoIP is made of Low-Latency-network with many small packages (>3kHz, package size about 256B, UDP).
When using a Cisco-switch (e.g. from the Series SG350= we see the CRC-errors on RX.
The Switch uses the IEEE-Standard with 8 Byte in RX and uses - dependent on the number and size of the packages, less then 12 Byte IFG/IPG, also 8 Bytes.
These reduces the latency and increases the throughput with small packages.
Also IPG gets used for the orientation, Cisco describes this in their documentation.
The Cisco-switch is reommended by many manufacturers of AoIP-devices. That's why it is used by many end-users. Devices with a different PHY do not have Problems with 8 Byte IFG/IPG. The IEEE-standard for 1GBE also says that RX 8Byte has to be supported.
The CRC-errors are recognized in the Linux Kernel through the MAC and then the packages are lost. The CRC-check can be done by SW and HW. It has no effects on the number of CRC-errors. The Kernel module of the MAC increases the statistics. You can see this with an easy tool like ethtool.
We have done this test with VTM-register. This affects the error, see TI-forum:
| DP83867CS: size-dependent packet loss with minimum IPG Part Number: DP83867CS Other Parts Discussed in Thread: DP83867CR , We'd like to understand the minimum IPG supported by this part. Based on a forum post for the e2e.ti.com |
Unfortunately the error is not gone completely. With the undocumented setting 0x3 (see forum) we get the most least errors, so we get about 1 error / hour. 0x2 leads to more or different errors.
TI already confirmed the issues with IPG/IFG 8 Byte on the used PHY.
Maybe it manages up to 10 or 11 Bytes but on lower values it fails.
Here is a description for the test to reproduce the CRS-errors:
When using the Cisco-switch with SA7 you get ~2% errors, that can be shown with ethtool -S.
With a direct connection or using a different switch (normal, no low latency, not managed), you cannot see the CRC-erorrs, as only 12 Byte IFG/IPG are used.
Setting the SA7 to 100MBt/s you will also not see the errors with a Cisco-switch, as the IPG/IFG is much higher.
SA7 (Server):
iperf3 -s -p 5000
PC (Client):
iperf3 -c IP_ADDRESS -p 5000 -u -b 5.85M -P 16 -l 201 --pacing-timer 125000 -t 60 -S 46
The load in the network corresponds to a 'nomal' AoIP-load 50-70 MBit/s)
With a 60s-test you will see about 90 errors (90 packages get lost).
Can you please have a look at this and let me know when the problem will approximately be solved on your side?
Thank you and Best Regards,
Anja Maier
Hi Anja,
I was able to get another Processor board, such that the setup was:
Proc Board <-Ethernet Cable-> Proc Board
Where the DP83867 is on both ends of the link. The command:
iperf3 -c IP_ADDRESS -u -b 5.85M -P 16 -l 201 --pacing-timer 125000 -t 60 -S 46
still ran with 0 errors.
Figure 1 - Client and Server after run
Please let me know when you have further details from the customer, regarding the purpose of the command and what exactly it is doing.
Regards,
Alvaro
