Replies: 8
Views: 94
Part Number: DP83869HM
Hello,
I am having some trouble with my design using the DP83869HM. My design is based on the DP83869EVM evaluation board. I have set my design so a simple jumper setting can switch the board from 100M Media Converter to 1G Media Converter.
I am using an EXFO AXS-200/850 Ethernet Test set with an EXFO ETS-1000L Ethernet loopback module to generate and analyse Ethernet traffic though the system.
The EXFO test equipment measures data rate and bit errors. There is no problem what-so-ever in 100M media converter mode. The data rate happily runs at 100 Mb/s and is completely error free.
Similarly, when I use a single board operating at 1G Media Converter and loopback the fibre signal (either with or without the EXFO loopback module) there is also no problem; it runs consistently at 1 Gb/s and is error free. I only begin to run into issues when trying to use 2 of my boards in the system. In this case when they are set to 1G Media Converter, the best data rate I can achieve floats around 998 - 999 Mb/s. I can run the test at a reduced data rate and there is no problem, but I simply have been unable to achieve a maximum data rate of 1Gb/s with 2 boards.
Admittedly, I only have 1 evaluation board so I am unable to test if 2 evaluation boards connected together work any better.
My question is why would the data rate drop to 998Mb/s? Is this a timing issue between boards?
Best regards
Gareth Foster
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
In reply to Justin Lazaruk:
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?
Gareth
In reply to Gareth Foster:
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.
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.
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?
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.
Thank you, I will look for your update.
We appear to have had some success, and it looks likely that the issue we were seeing was more to do with the limitations of our loopback module more than anything else and perhaps our test was asking too much of it.
We very recently acquired another EXFO test module; the FTB-8510B Packet Blazer (we are using it on a FTB-200 base). This has dual RJ45 and SFP ports. With this equipment we are able to run bi-directional BER and RFC 2544 tests (no loopback). This can be considered a more real world set-up.
With this setup there were no drops in data rate or other errors and so we can only consider this to be a success.
Unfortunately I cannot explain why exactly the loopback was the cause of the failure, but I can only assume it is to do with the complexities of the signal on the copper side of gigabit ethernet. Is this a common problem do you know?