I got this issue resolved.
I did a lot of reading. Yes, it appears sometimes Cisco devices don't play nice with 3rd party SFPs. My environment and timeframe did not allow to get Cisco branded SFPs in.
I looked at what I had and found a 20x1G line card laying around and decided to throw that in a blank slot. I had been working off of a 10G line card in all of the steps in my original post. Once I had everything physically connected and moved my config over to the needed card/ports, line and protocol status went up/up and beautiful green link lights came alive.
It appears that you cannot simply drop the speed on a 10G line card down to match lower bandwidths. I will update with a better explanation if/when I find one.
As far as I am concerned, the most common SFP problems are Poor performance, No connectivity and Corrupted software.
For the first one, the possible cause of this problem include that cabling distance is exceeded or port statistics show excessive frame check sequence (FCS), late-collision, or alignment errors.
Resolution:
Reduce the cable length to within the recommended distances. See your SFP module documentation for cabling guidelines.
For the comnectivity issue, maybe you have used the incorrect ot bad cable, or STP (Shielded Twisted Pair) checking for possible loops.
Resolution:
Verify the pinouts are correct for the proper application of cables. Replace the cable with a tested good cable. Wait 30 seconds for the port LED to turn green.
For the third issue—corrupted software, this include three situation including the port is placed in error-disabled state after SFP is inserted, device does not recognize the SFP module, and excessive errors found in port statistics.
Resolution:
Remove the SFP module from the switch and replace it with a Cisco-approved module. Use the irrdisable recovery cause GBIC-invalid global configuration command to verify the port status, and enter a time interval to recover from the error-disable state. The best advice is to use the Cisco original SFP or 100% Cisco compatible SFP (If you decide to use a third-party SFP, please ensure that your supplier is assured) that is adapted to the switch.
Hope this might help you!
Best Answer
Latency of 10GBASE-SR/-LR vs SFP+ DAC is very closely the same - in contrast to 10GBASE-T which adds appr. 1.5 μs.
Majorly, latency is caused by the line encoding overhead. In the case of -R PHYs, that's 64b66b code which requires little processing. SFP+ cages are directly fed with an -R data stream, which DACs then couple onto copper twinax and SFP+ modules use to modulate their lasers. Again, very little processing, same low latency for both.
Hypothetically, DAC could be faster because of the potentially higher velocity factor (VF) and, accordingly, lower propagation delay. The kind of twinax used is at the vendor's discretion, but even if that had a VF of .9 in comparison to fiber's .67, the delay difference for a long DAC of 10 m against fiber would be around 12 ns (10 / c * [1/VFfiber - 1/VFtwinax]).
It makes more sense to tailor the patch cables than to worry about that (12 ns is about 2.5 m worth of fiber) but either is rather moot.