DP83869HM: 1000Base-X to 1000Base-T Media Converter

Hi Gareth,

How are you calculating the data rate seen by each PHY? Are you able to detect if there are packet errors, CRC errors/undersized/or dropped packets? 

The PHY should just act as a pass through in converting the copper to fiber signal, so if it operating normally in 1Gbps mode, I would not expect it to be decreasing the data rate of the stream.

Regards,
Justin 

Hi Justin,

Using the EXFO AXS-200/850 I have carried out a bit-error-rate-test, a traffic gen. & monitoring test and a RFC_2544 test.  This is when 2 boards picked at random are communicating with each other.  I did do loopback tests on each board individually to make sure there were no errors before testing the pair together.

I had some trouble attaching the reports so instead I have copied the contents of the RFC report below:

EXFO Electro-Optical Engineering Inc.

User Information:
Report Date: 1/7/2021 11:51:53

------------Test Configuration------------
Type: RFC 2544
Throughput Test Time(MM:SS) 00:01
Throughtput Max Rate (Mbps) 1000.0
Throughput Threshold (Mbps) 1000.0
Back-to-Back Max.Dur.(MM:SS) 2
Back-to-Back Threshold (%) 100.0
Frame Loss Test Time(MM:SS) 00:01
Frame Loss Max. Rate (Mbps) 1000.0
Frame Loss Threshold (%) 0.1
Latency Maximum Rate (Mbps) N/A
Latency Test Time (MM:SS) 00:01
Latency Threshold (ms) 125.0
Test Interface:
Port: Electrical 1Gbps Full
Source MAC Address: 00:03:01:FF:25:63
IP Version: IPv4
IP Address: 10.10.0.0
Source UDP Port: 49184
VLAN ID/Priority:
None
Stream Info:
Dest. MAC Address: 00:03:01:FF:25:63
Dest. IP Address: 10.10.0.0
Dest. UDP Port: 7
Remote ID: Disabled

---------------Test Results---------------
Start Time: 11:19:09
Status:
Throughput Completed
Back-to-Back Completed
Frame Loss Completed
Latency Completed
Duration:
RFC 2544 0d 00:32:05
Throughput 0d 00:07:15
Back-to-Back 0d 00:19:35
Frame Loss 0d 00:03:44
Latency 0d 00:01:25
Pass/Fail Verdict:
Throughput Fail
Back-to-Back Fail
Frame Loss Fail
Latency Pass

------------------Alarms------------------
Alarm Seconds
LOS N/A
Link Down 0
Frequency 0

------------------Errors------------------
Error Count Error Count
Symbol 88402689 Jabber 4532
Undersize 0 Late Coll. N/A
FCS 36802 Runt 70
Collision N/A Exc. Coll. N/A
Alignment --

----------------Statistics----------------
Throughput (Mbps,All Layer):
64: 943.82
128: 961.038
256: 982.206
512: 988.847
1024: 994.285
1280: 993.883
1518: 994.182
Back-to-Back (Mbps,All Layer):
64: 0.128
128: 0.03
256: 0.112
512: 0.055
1024: 0.125
1280: 0.047
1518: 0.062
Frame Loss (% Loss):
64: 0.399
128: 0.577
256: 0.754
512: 1.317
1024: 2.528
1280: 3.142
1518: 3.676
Latency (ms, S. & F.):
64: 0.00144
128: 0.00088
256: < 0.0005
512: < 0.0005
1024: < 0.0005
1280: < 0.0005
1518: < 0.0005

------------System Information------------
Module Information:
Module ID: AXS-850
Revision Number: 67
Serial Number: 418803
Calibration Date: 2/8/2010
Software Information:
Software Version: 1.5.0.36

So it is definitely dropping frames or receiving invalid frames back through the system during the test, which does not happen when looping back on a single board.  If the data is just passively passing through from copper to fibre back to copper again (actually it's copper -> fibre -> copper -> fibre -> copper), why would there be such a difference between using 1 board and 2 boards unless there is some kind of timing issue between the boards?

Best regards

Gareth

Hi Gareth,

I would like to confirm I understand the setup, you have two custom DP83869 media converter boards, and one DP83869 EVM. 

It would appear to me there is a timing issue between some link over the system. Can you enable the Ethernet packet generator on one side of the link and evaluate the data on the other end, without looping back? Putting the far end DP83869 media converter in a reverse loopback mode would also help to isolate the location of the packet errors.

Regards,
Justin 

Hi Justin,

Correct, I have 1 DP83868EVM evaluation board and I am using 2 of my custom boards using the DP83869 device.

Unfortunately we only have 1 piece of test equipment and it relies on looping back the signal at the far end.  We are currently looking at whether there is something clever we can do with a Network port on a Laptop/PC that will allow us to interrogate the frames/packets/data rate at the far end of the system. I have also tried different ways to clock the boards in order to eliminate any timing mismatch and have found that the data rate/error count can vary (even improve) with certain set-ups but still not able to achieve 1Gb/s.

I did notice that the capacitors I am using on the clocking circuit are slightly higher than they should be; the CL of my crystal is 9pF but the caps either side of it are 22pF.  I am going to try some lower values: 20pF, 18pF, 15pF and 12pF to see which value gives the best performance.  Maybe the right capacitor value will even fix the problem.

Best regards

Gareth

Hi Gareth,

Please let me know the results of the BER tests with the corrected loading capacitors on the XI pin. This will have an effect on the MDI link quality and is a good catch. Please also let me know if you are able to put the far end PHY in a reverse loopback mode to isolate the copper to external loopback from the test and see if the errors persist?

Regards,
Justin 

Hi Justin,

No problem.  It will take me a day or two to get the replacement parts in and try them.  I haven't been able to monitor data at the far end yet but will continue to work on that in the mean time.

Best regards

Gareth

Hi Gareth,

Thank you, I will look for your update. 

Regards,
Justin