hi is it possible to connect a 10 gbase kr phy via 10 gbase t sfp+ pluggable to another 10gbase t sfp+ pluggable in a pc which supports different protocols (i hope also kr) ? or should i use a 10gbase-cu sfp+ cable? thank you
or is the 10gbase KR not used anymore? it says https://standards.ieee.org/standard/802_3ap-2007.html is replaced? or not more active?
teasnakl wrote: > hi is it possible to connect a 10 gbase kr phy via 10 gbase t sfp+ > pluggable 10GBASE-T and SFP+ are two different things. 10GBASE-T is the standard for transmitting 10 GBit Ethernet over 4 pairs of twisted pair copper. SFP+ is the socket you can plug in 10 GBit fiber modules or direct attach cables. I guess with "10 gbase t sfp+ pluggable" you mean a SFP+ direct attach cable, correct? > pluggable to another 10gbase t sfp+ pluggable in a pc which supports > different protocols (i hope also kr) ? > or should i use a 10gbase-cu sfp+ cable? 10GBASE-KR is a standard explicitly for backplanes. You can't directly connect it to any of the other 10 Gbit Ethernet standards. So if you have a PHY for 10GBASE-KR, then you need another 10GBASE-KR PHY on the other side of the connection. If you want to connect it to a PC, you'd need some media converter that has a 10GBASE-KR connection on one side and for example a SFP+ slot on the other side.
Gerd E. wrote: > 10GBASE-KR is a standard explicitly for backplanes. You can't directly > connect it to any of the other 10 Gbit Ethernet standards. So if you > have a PHY for 10GBASE-KR, then you need another 10GBASE-KR PHY on the > other side of the connection. If you want to connect it to a PC, you'd > need some media converter that has a 10GBASE-KR connection on one side > and for example a SFP+ slot on the other side. in my opinion this is not true. 10GBASE-KR is for backplane application and has improvements on signal quality and an optional forward error correction. But everything is automatically handled with auto-negotation. If the phy does additionally support you can connect it directly to a SFP+ module via the so called SFI interface. So, what phy are you using? this will help a lot to answer your question.
tja wrote: > So, what phy are you using? this will help a lot to answer your > question. vsc8489 Datasheet explain modes:
1111: 10BASE-T (not supported)
1110: 100BASE-TX (not supported)
1100: 1000BASE-T (not supported)
1010: 10GBASE-KX4 (not supported)
1001: 10GBASE-T (not supported)
Gerd E. wrote: > SFP+ is the socket you can plug in 10 GBit fiber modules or direct > attach cables. yes and 10 GBase T for "standard" RJ45 Twisted Pair Gerd E. wrote: > 10GBASE-KR is a standard explicitly for backplanes. You can't directly > connect it to any of the other 10 Gbit Ethernet standards. So if you > have a PHY for 10GBASE-KR, then you need another 10GBASE-KR PHY on the > other side of the connection. If you want to connect it to a PC, you'd > need some media converter that has a 10GBASE-KR connection on one side > and for example a SFP+ slot on the other side. thank you yes this is what i suspected, actually the pc-card maybe supports the KR-protocol, but even the ethtool doesnt say it xD For a first test i could change my phy to SR mode, which is supported by my pc-card. I dont need SFP+ Fiber dont I? I can do it with SFP+ 10GBase T? I will check it :)
> I dont need SFP+ Fiber dont I? I can do it with SFP+ 10GBase T? > I will check it :) PHY( SR Mode) -> SFP+ for 10GBase T-> SFP+ for 10GBase T-> Ethernet Card I dont really know if this makes sense.
teasnakl wrote: > PHY( SR Mode) -> SFP+ for 10GBase T-> SFP+ for 10GBase T-> Ethernet Card this is absolutely fine and will work. So the TO don't need the KR option.
Hi thank you. tja wrote: > the TO What is the T0? And do you know why this is ok? Will the SFP transceiver just to the translation?
TO = thread opener ;-) the interface between phy and sfp+ is specified and called SFI. Any SFP+ module has absolutely the same electrical interface standard. So in general for the phy it isn't important what type connected: 10GBASE-SR, 10GBASE-ER, 10GBASE-LR, 10GBASE-T, etc. So connection between phy and SFP+ is fine. Next step: 10GBASE-T at your hardware and 10GBASE-T at your network adapter in your PC. Between them there is the electrical interface standard with a PAM (pulse amplitude coding). Buter after the SFP+ there is the SFI interface with NRZ coding again. You can believe it or not, but it will work. And when you don't believe then take the datasheet, literate especially you should read the IEEE 802.3 specification where everything is described in detail. Good luck
Hi tja, I still don't understand the compability yet, but SFI might be a good solution! Thank you :D I will/need-to check out SFI,SerDes,IEEE and so on! Until then i ask myself: E.g. 10GBase-T descirbes twisted pair cable. When plugging a SFP+ inside, the SFI should transform the twisted pair signals to SFP+... and e.g. 10GBase CX4 also to SFP+. ... I mean: phy(some ethernet standard)->sfi->sfp+-> cable I found these books which maybe tells something about it. Hadn't time to read into it now. https://www.google.de/books/edition/High_Speed_Serdes_Devices_and_Applicatio/Cx3r0H-4AhEC?hl=de&gbpv=1&dq=serdes+frame+interface&pg=PA204&printsec=frontcover https://www.google.de/books/edition/Network_Infrastructure_and_Architecture/YVQID9pY1rIC?hl=de&gbpv=1&dq=serdes+frame+interface&pg=PA250&printsec=frontcover
correct, the SFP+ does all the signal translation. Check: https://www.10gtek.com/templates/wzten/pdf/SFF-8431-(SFP+%20MSA).pdf https://en.wikipedia.org/wiki/10_Gigabit_Ethernet
Thank you, I began to check the IEEE standards. Starting with PMA ... I just got maybe 10% of understanding. It looks like the PMA is directly connected to the Pins. E.g. at 10GBase T the 4 differential pairs... I will check more :D
oh this is why it also confusing a PMD is not "mandotory" everywhere.
I am still not 100 % sure. If my PHY is only able to do Clause 73 Auto-Negotiation. Because if the SFP+ does some translation but has no intelligence two systems won't fit like Backplane Ethernet (KR,Kr and so on, but no 10GBaseT) and my 10GbE Ethernet NIC(no KR and stuff my PHY supports.) ... But a 16 ms signal-burst-signal should be sent be each of them right? Check this out, in Clause 73 it says: >"While implementation of Auto-Negotiation is mandatory for Backplane >Ethernet PHYs, the use of >Auto-Negotiation is optional. Parallel detection shall be provided for >legacy devices that do not support >Auto-Negotiation." And whatever that means: >"If Clause 37 Auto-Negotiation is performed after Clause 73 >Auto->Negotiation, then the >advertised abilities used in the Clause 37 Auto-Negotiation shall match >those advertised abilities used in the >Clause 73 Auto-Negotiation."
sry for bad quotations
Interesting: - I checked my PHY design and saw that there is only one RX and TX pair connected to the SFP+ port! I think all SFP+ have only one RX and TX pair. E.g. the 10GBase T Standard wants 2 pairs of RX and TX! So How is that working? I think the data are transformed from 8 to 4 lanes at the SFP+. So if the phy understands this one pair protocol it will be fine. Is this the solution of my question? So I think the 4 lanes of my PHY are translated into 8 lanes of my RJ45-cable and than back at the SFP+ plug in my NIC. So my NIC should understand my PHY. If I would use a DAC the 4 wires would attache directly to the pcb. what do you think? ---
ah i didnt thought about why my phy only understand 4 pair ethernet... but it must have something to do with the standards. every standard uses the same PMA with only 4 lanes. So 10 GBase or KX4 has 8 lanes. The phy dont support it. My NIC supports it... I dont know how!
There is some misunderstanding here. 10GBASE-T uses all 4 pairs in both directions. The necessary signal processing is complicated and power hungry. An SFP+ module for 10GBASE-T is complicated internally. 10GBASE-T is very different from all other 10G ethernet.
I dont need SFP+ Fiber dont I? I can do it with SFP+ 10GBase T?
I checked my PHY design and saw that there is only one RX and TX pair connected to the SFP+ port! https://teatv.ltd/dl/ https://hellodear.in
: Edited by User