What port is the one being converted from gig to 10g, server<>9200L or 9200L<>9500?
You wrote earlier "throughput testing from the LAN and to the internet" and now "tests to a server on the LAN running at 1G, the laptop we are doing the testing on is also running at 1G", so @carl_townshend could you clarify what link is changed and what host(s) are then impacted.
As to my comment about "bottlenecks", it may have been misunderstood. Moving from gig to 10g removes the gig "bottleneck" compared to 10g, which would normally be considered a "good thing". But, that's not aways the case.
NICs should always be able to handle a single frame at line rate. The device having that NIC may not be able to keep up with processing sustained frames/packets. Just as a microburst can overrun a buffer, causing drops, while overall average utilization is low, it can do the same to frame/packet processing.
So, there are cases where increasing bandwidth causes increased drops. It's counter intuitive, unless you understand increasing bandwidth also increases PPS.
If drops are being increased due to additional PPS demand, devices (at least Cisco switches and routers) will often show that somewhere in their stats, but not as egress drops.
If this issue is strictly tied to Internet, finding a too PPS stressed Internet device can be practically impossible (unless you're the ISP).
If problem can be seen internal to your network, you have a good chance finding it.
BTW, the PPS issue, decades ago, was much more common. Which is why, back then, vendors, including Cisco, would often just provide a PPS for 1500 byte packets, but often not for smaller packets. The reason being device could support wire-rate for that sized packets, but not for below some smaller size.
I'll also mention this issue is much more relevant to CPU based routers, rather than L3 switches, but even the latter can have issues in some rare cases. (As such cases can be used for DoS attacks, I'll skip details.)
