I encountered issues similar to This Thread, and began troubleshooting based on the recommendations there. In specific I am testing a single GigE camera operating at ~320Mb/s, and the UIs I’m using to test (eBUS player, VimbaViewer) are getting spikes of packet resends, enough that it’s causing our own software to lose the stream fairly quick. I’ve connected the camera on port 9, and the control computer on port 10.
After getting familiar with the interface, I found that I was unable to make adjustments to ports 0, 9, and 10, with reasons listed as not implemented for SERDAS ports, or not implemented for SFP ports, depending on the specific operation. I am not quite able to bridge the gap with what’s available on the support forum.
Yes, I’ve connected to the CLI. Attached is a picture of the serial terminal, where the problem presents itself on the ports I’m trying to use refusing any interface option except for link.
Question though, you mentioned you saw issues as in the thread you referred to, but those issues were solved by turning off EEE. Can you explain why you want to change the SERDES mode?
Regarding the issues in the other thread, I didn’t initially realize that user was using the 1G PHY lines. It was just superficially the most similar issue to what I had, that of random packet loss and resend alerts unique to using the Ubiswitch in our architecture, so I went forward and attempted to mimic that solution.
I don’t recognise that 250256 part number? The part number for our 10G SFP is SFP-10G-T.
I’ll assume you are using our 10G SFP. If that’s the case, you shouldn’t need to change the SERDES ports. UbiSwitch by default puts the 10G ports in 10GBASE-R mode, which is the right mode for those 10G SFPs.
Can you explain a little more about the issue you’re seeing. Changing the SERDES mode isn’t going to fix anything if you’re using 10G SFPs (if anything, it will stop the 10G SFPs from working because they only work when UbiSwitch puts the SERDES ports in 10gbase-r mode).
Yes, sorry that was the serial number not the part number. It is the 10g-t unit.
The issue we’ve been seeing is that the video stream is losing packets, unique to using the Ubiswitch to connect our cameras, whether we’re using maxed out or more normal data rates. We’re using a Goldeye-G008 SWIR TEC1, and before moving over to Ubiswitch we connected directly to the camera without this issue.
This solution does work. The setup I was provided connects the camera via one of the SFP ports, but I can recommend changing it. Is there some reason the SFP port is mishandling the video stream on input but not output? I’m mostly just curious at this point but our technical lead has been looking at some sensors with much higher data rates that may necessitate streaming to SFP instead of PHY ports and I’d like to get ahead of that if there may be issues.
Oh I see, thanks for clarifying. So the issue is on the SFP ports using our SFP modules.
Your cameras are 1000BASE-T, and the SFPs are 10G/1000/100/10BASE-T. The backplane side of the SFP (the part inside the SFP cage on the board) is running at 10GBASE-R.
What should be happening is…
The 1000BASE-T camera and 10G SFP auto-negotiate down to 1000BASE-T
The 1000BASE-T data is “packaged” into the 10GBASE-R backplane connection, into UbiSwitch
In theory there should be no issues with that, but we have occasionally seen issues with it. To solve it, can you try the following.
Try setting the SFP ports to USXGMII. I know I said don’t try this initially but I didn’t know you were using the 10G SFPs at 1G.
Try using a 1G SFP in the SFP cage, then set UbiSwitch to put the SFP ports to sgmii or 1000base-x (the specific SFP port mode you need will depend on the specific SFP you pick; but it will just be one of those options).
Option 2 is very likely to solve this issue but I am curious if option 1 solves it, because we haven’t actually tested that!
I tried switching it to USXGMII, but without the ability to read back from the port I can’t know that the command actually did anything. It doesn’t appear to have worked from what I can tell.
I will see if we have any 1G SFP’s lying around or get a couple if the budget allows, and get back to you if there are further issues. Thanks again for your assistance, Josh.
I’m not able to make use of traffic monitoring apps so I can’t really say. I opened up the communication controls in the app on the control computer but didn’t see any settings changes or modifications, and the camera itself didn’t disconnect or halt streaming when doing the command ‘port x mac mode uxsgmii’, but this kind of work is a little closer to the metal than I’m personally used to so I’m not sure that I should expect some kind of interruption.
Getting back to your team now that I have acquired the 1G module, specifically the 1G Copper Hi Fiber noted as compatible on other support topics. I have found that solution 2 does not appear to work after having tested with both the 1000basex and sgmii mac modes, with and without power cycling prior to connection attempts.
It is actually fairly difficult to switch to PHY ports at the moment due to form factor constraints, so this limitation is hindering integration. Is there anything else I may be able to do to get the SFPs to negotiate correctly, or at least know that something is happening? We initially purchased these switches at least eight months and possibly over a year ago, have there been recent software/firmware updates that I could push through the UART that more reliably interact with SFPs or provide better diagnostic information?
‘Not working’ is exactly what you suggested. I am seeing no indicator for port 9 having a connection to the camera after confirming the swap to 1G SFP is on port 9. The command I’m using to swap modes comes directly from the docs, though I can’t be sure it’s doing anything.
port 9 mac mode 1000basex
I can confirm that port 0 has our 10G connection to the control computer, port 9 has the 1G Hi Fiber SFP and connection to the GigE camera. To verify, I’ve reconnected the ethernet cables on both ends for both connections. I have also made sure to have the SM1 trace cut to set the switch up for 1G mode.
Hmm, we don’t suggest using the SM1 trace cut mode anymore, that was implemented before the software was available. Probably not an issue though as our software will just ignore that and go with whatever you send it in the CLI.
Can you try switching between these two modes a few times and tell me what you see on the port 9 LED.
port 9 mac mode 1000basex port 9 mac mode sgmii
Finally, to see if there is an issue between the SFP and that camera (rather than the SFP and UbiSwitch) have you tested that SFP connected to the camera when the SFP is plugged into, say a PC? This will allow us to eliminate the SFP ↔ Camera connection as the source of the issue.
Also let me know the cabling between the SFP and the camera
Have to give a call back about the connectivity issue - some of my things were shuffled around at my workstation and the Ethernet-USB converter on the control computer side was switched out with a different one. After swapping back I can confirm that the changes suggested DID actually work, so I can only thank you guys for being so prompt about providing clear solutions. This has been a significantly more enjoyable bit of support-seeking than is typical.
