Thank you for the info so far. Just to give a little more specifics on my application ... The ATTO NS12 NIC has two SFP+ interfaces. It uses an 82599EB ethernet controller. We are using Finisar dual rate 1G/10G SFP+ single mode modules. We have two computers, each with an NS12. We are are creating one 1G link and one 10G link between the computers. I was already using ethtool to restrict the advertised rate to 1G for one port and 10G for the other port. So it sounds like I was already doing all that was possible to configure things so the links will come up as fast as possible except the option of disabling laser functions that was mentioned? What are the tradeoffs in disabling laser functions?
The links between the two computers include experimental wireless segments which is where the 100 msec latency in each direction comes from. From an ethernet point of view, the ethernet link is from one NIC to the other NIC. It would be very helpful to have a clear understanding of exactly what is required to establish a solid link light. As I have mentioned, sometimes it can take a while to get a link light. Also, if we encounter non-ideal conditions on the wireless segment such as non-zero BER, the NIC link light will flicker. Please let me know if there is a mode of operation of the 82599 with SFP+ modules that would best tolerate these harsh conditions. Also, please let me know if there is a limit to the latency that can exist between the two NICs and still be able to establish an ethernet link. Skidmore, Donald C writes: > > >> -----Original Message----- >> From: Waskiewicz Jr, Peter P [mailto:[email protected]] >> Sent: Monday, March 11, 2013 10:19 PM >> To: [email protected] >> Cc: [email protected]; Tantilov, Emil S >> Subject: Re: [E1000-devel] ixgbe for 82599, how to disable autoneg? >> >> On 3/11/2013 8:38 PM, [email protected] wrote: >> > My understanding is that this does not disable auto-negotiation but >> > rather just sets what is advertised during auto-negotiation as supported >> rates. >> > >> > We are working with an rather odd experimental system where we are >> > trying to create a 10G link between two 82599 based NICs (ATTO >> > FastFrame NS12 with dual SFP+ modules) over an optical link with 100 >> > msec of latency in each direction. We are experiencing long delays in >> > getting a link light that we believe is related to auto-negotiation. >> > We would like to try running without auto-negotiation. It appears the >> > 82599 controller supports, so >> > >> > Does the 82599 support 1GbE and 10GbE via SFP+ without auto- >> negotiation? >> > >> > I was hoping to get some guidance on how to go about modifying the >> > ixgbe driver so that I can try 1G and 10G without auto-negotiation. >> >> Ah, so you're using dual-speed optics. What you're referring to isn't auto- >> negotiation per se, it's what we call Smart Speed. Since 10G fiber doesn't >> have a speed auto-negotiation via spec, we came up with this algorithm to do >> the speed detection and downshift. >> >> I would search the code (ixgbe_82599.c for example) and set smart_speed in >> the PHY struct to smart_speed_off when in the case of multispeed_fiber. >> >> Hope this helps, >> -PJ >> > > Smartspeed may well be causing some latency but it would only come into play > on a backplane device. And since you mentioned SFP+ it leads me to believe > that you're not on one. PJ point was very valid however in that 10G doesn't > do autoneg for say. For multi-speed fiber we instead "try" all the speeds > that you have advertised (like Emil mentioned before). So in the case of > 0x1020 (10G and 1G) we will try 10G - 1G - 10G. So this could well be > causing latency on your 1G connection if we first attempt a 10G. You could > prevent this by only advertising the speed you want to connect to likewise > have your peer do the same. > > Now from your example code you sent I don't believe would work, once again > I'm assuming you are using SFP+ fiber. If that is the case your example was > using KX and KX4 which I don't believe would work. > > If you are only worried about getting link light up faster and don't care > about auto try, you could also disable the laser functions in > ixgbe_init_mac_link_ops_82599() much like we do if MNG FW is running. Then > the link would turn on (assuming we could get link) in probe and not turn off > with a 'ifconfig down'. > > Thanks, > Don Skidmore <[email protected]> ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
