Advice on iperf3 test results

DavidR1 said:
There's nothing wrong at all with having multiple switches (PoE or otherwise) in your network topology. It's the norm in offices and datacenters and there's many people here doing something similar (myself included).

Cable 3 has really lousy throughput though unfortunately, even if it's showing better loss numbers compared to the other runs. Even if "it works", that's going to limit traffic over that link between the office and your router - Blue Iris, some cameras, and possibly a wired office computer, etc. Frankly, a powerline adapter or even wireless link offers better connectivity. And without knowing what the problem is, who's to say it won't get worse or stop working altogether after you've decided to make it a key part of your infrastructure?

Since there's already construction happening, it makes sense (to me at least - it's not my money or mess in my living space) to do things right rather than complicating an already problematic install. Based on how you had your current cabling installed, I assume you don't have accessible attic/basement space to run wires? A cable installer can run things through finished spaces with minimal repairs needed, if it came to that, and you'll already have someone doing drywall and paint so they should be able to do the touch-up at minimal added expense. A qualified cable installer will also punch down a patch panel and wall jacks where needed, and you'll be guaranteed properly working runs when they're finished.

Sorry this has turned a basic installation plan into such a nightmare project for you. If you were local, I'd happily volunteer to stop by with everything needed to figure it out and complete the installation, but solving it over the internet is a challenge. It's honestly never this complicated; there's clearly something we're missing....
Click to expand...
Appreciate the info - and totally agree that there is nothing stopping it getting worse and eventually stopping working. Wasn't in my plan but I I think I will remove this as my headache and just ask new cables to be run by the pros and get them to do the crimping/patch panelling and also the cam installs if I have one or ore cams by then. Hopefully they'll give me some suggestions for the cable runs which will have minimal disruption and aesthetic impact.

But because I'm still curious I will still create a new cable from my reel and crimp again to see if I still have the issue. If I do, it might suggest connector issues so I might even get some different RJ45 connectors and try again. Appreciate your help!
 
I realize I'm repeating myself but It's worth doing a few more crimps for testing purposes; you've got little to lose except the time invested and a few connectors. If the cable itself is good (i.e., meets specs, not counterfeit, etc.), there's no reason why you shouldn't be able to get good results on anything you're able to make yourself. There's nothing I can see in your pictures that would prevent the cables from working.

While there's any number of possible issues hidden out of sight in the walls/floors/ceilings (cables stapled by the installer, snags, etc.), having issues with the short patch cord you made limits the variables considerably. The same is true of putting connectors on the remaining wire in the spool; it keeps it simple. If there are still issues, then the problem must lie with either the spool of cable itself, the connectors being used, or some part of your crimping process.

If it's still not possible to get a good cable out of some of what's left on the spool, I'd sacrifice an old patch cord that I knew was good for the cause. I'd cut the ends off, one at a time, just to put your connectors on it using the crimp tool you have on hand. (What tool are you using BTW?) If still no luck, I'd spend a few dollars on some new connectors and try once more with those. You've come this far and it's a small investment compared to all new runs...and I hate not knowing why something doesn't work like it should.

I do wish that you had access to real network cards for your testing, but as long as you're getting consistent results when you retest a given wire, I suppose they have to be trusted. I'd recheck that part of this whole process too if you're not completely fed up at this point. Disable any wireless connections and make sure there's as little else running on those laptops while you test.

If you do spend further time on this, please keep us informed as to what you find -- and best of luck!
 
  • Like
Reactions: alastairstevenson and freddyq
sticking my noise in .
look at using rj45 passthru platinum connectors and crimp tool. I have not used the tool, but it looks like a good idea.


 
As an Amazon Associate IPCamTalk earns from qualifying purchases.
SouthernYankee said:
sticking my noise in .
look at using rj45 passthru platinum connectors and crimp tool. I have not used the tool, but it looks like a good idea.


Click to expand...
Yes I do like the look of those pass-through style connectors I think they will provide more assurance of the wires being correctly in place and also ensure I can get the cable jacket under the gripper in the connector which keeps it in place.

The crimping tool I have is this one: RJ45 Ethernet Network Cable Crimping Plug Tool Kit LAN Crimper Cutter Cat5e Cat6 6393851656224 | eBay
 
As an eBay Associate IPCamTalk earns from qualifying purchases.
As an Amazon Associate IPCamTalk earns from qualifying purchases.
OK @DavidR1 @alastairstevenson so think I have a bit of a breakthrough! I took some new cable from my reel and crimped from fresh, this time I made sure I got the outer jacket well inside the connector and under the gripper. Once crimped, it felt a lot sturdier than the other cable as a result.

I then ran the same test as before, old Sony connected to my switch with a machine-terminated CAT5e cable (same one used in previous test) and running as iperf server. Dell (with ethernet to USB adapter) connected to switch using newly crimped CAT6 cable and running as iperf client. UDP results as follows:

[ 5] local 192.168.0.56 port 60834 connected to 192.168.0.8 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 66.6 MBytes 558 Mbits/sec 8520
[ 5] 1.00-2.00 sec 73.8 MBytes 619 Mbits/sec 9440
[ 5] 2.00-3.00 sec 78.4 MBytes 656 Mbits/sec 10030
[ 5] 3.00-4.00 sec 73.8 MBytes 619 Mbits/sec 9450
[ 5] 4.00-5.00 sec 81.6 MBytes 686 Mbits/sec 10450
[ 5] 5.00-6.00 sec 82.0 MBytes 688 Mbits/sec 10490
[ 5] 6.00-7.00 sec 82.7 MBytes 693 Mbits/sec 10590
[ 5] 7.00-8.00 sec 82.0 MBytes 689 Mbits/sec 10500
[ 5] 8.00-9.00 sec 81.3 MBytes 682 Mbits/sec 10410
[ 5] 9.00-10.00 sec 72.0 MBytes 604 Mbits/sec 9220
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 774 MBytes 649 Mbits/sec 0.083 ms 2470/99100 (2.5%)
[ 5] Sent 99100 datagrams

Clearly much better bandwidth and packet loss than before! :cool:

TCP results:

[ 5] local 192.168.0.56 port 54976 connected to 192.168.0.8 port 5201
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 110 MBytes 923 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec
[ 5] 2.00-3.00 sec 113 MBytes 947 Mbits/sec
[ 5] 3.00-4.00 sec 113 MBytes 945 Mbits/sec
[ 5] 4.00-5.02 sec 67.1 MBytes 554 Mbits/sec
[ 5] 5.02-6.00 sec 4.62 MBytes 39.3 Mbits/sec
[ 5] 6.00-7.00 sec 95.0 MBytes 799 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 937 Mbits/sec
[ 5] 8.00-9.00 sec 113 MBytes 948 Mbits/sec
[ 5] 9.00-10.00 sec 113 MBytes 948 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 952 MBytes 799 Mbits/sec sender
[ 5] 0.00-10.00 sec 952 MBytes 799 Mbits/sec receiver

Again, looking much more typical now.

So it looks like my crimping job is possibly to blame here. With that being the case, I will attempt to re-crimp each of my camera cables in the same way and then re-test. In terms of which end I attempt to re-crimp, I'm tempted to start with the outside (camera) end given those may have been damaged by the weather even though they've been wrapped up and protected the whole time. I'll re-test after the re-crimp and if results are still bad I'll re-crimp the inside end. I suppose if results are still bad, it would suggest the cable has been damaged in between somewhere which would at least give me comfort that cable re-runs are the only way to sort this.

Thoughts...?
 
That's a much more normal looking set of results.
And quite intriguing as to why they are better.

Did you just use the entire remaining cable for the test?
I do doubt though that just doing the strain relief better by it catching the jacket is the reason for the improvement.

Although another variable is the location and run of the problematic cables, there is also the poor result on your 30cm cable that would be unexplained by location.

Did you say you had or could borrow a cable continuity tester?
Checking the bad cables for continuity before making changes might be worth doing.
I still think a bad crimp would show as an open circuit as opposed to giving poor throughput.

A stray thought - on the original poor test results, what was the link speed as indicated by the network interface properties at each end?
Something I should know but don't - when one of the 4 pairs on a gigabit connection is broken, does the standard revert to a phased reduced link speed or to the next lower standard ie 100BaseT?
 
alastairstevenson said:
That's a much more normal looking set of results.
And quite intriguing as to why they are better.

Did you just use the entire remaining cable for the test?
I do doubt though that just doing the strain relief better by it catching the jacket is the reason for the improvement.

Although another variable is the location and run of the problematic cables, there is also the poor result on your 30cm cable that would be unexplained by location.

Did you say you had or could borrow a cable continuity tester?
Checking the bad cables for continuity before making changes might be worth doing.
I still think a bad crimp would show as an open circuit as opposed to giving poor throughput.

A stray thought - on the original poor test results, what was the link speed as indicated by the network interface properties at each end?
Something I should know but don't - when one of the 4 pairs on a gigabit connection is broken, does the standard revert to a phased reduced link speed or to the next lower standard ie 100BaseT?
Click to expand...
No I didn't use the entire remaining cable, I just cut another 35-40 inch length and used that.

In terms of tester, I have something like this if that's what you mean by continuity tester? I haven't tested the cables using it but I can do...

And re link speed, unfortunately I didn't check although I could get those speeds. One other thing I did do this time was switch wifi off on both laptops. I didn't specifically check that both had switched to LAN connection when I did the last set of tests but I'm fairly sure they had. Anyway, as I think you suggested I just turned it off this time to be 100% sure.
 
alastairstevenson said:
Yes, that's what I was thinking of. It's an open/short/one-to-one wiring tester.


Yes, easy enough to do. You never know - it may show the 'missing link'.
Click to expand...
So need more time to test them all but just tested cable 3 and the 1 to 8 lights all cycle through in order on both the main and remote tester so all seems OK there. The instructions for the tester say the G light should also light after 8 and this G light represents a wrong connection, short circuit or open circuit. But this didn't light up so I then used the tester on the cable I just crimped which got the good results and the G light also doesn't light up for that :confused:
 
I read through the full thread, but just to "eliminate" any end-point weirdness: did you run the iperf test on a "premade" 1.5m CAT6 cable to verify there are no dropped package? If that's the case, maybe that old Sony is to blame for eating (recycling?) packets on the iperf itself.
I'm eager to know if you could improve more than the aforementionned 2.5% drop.

Good luck!
CC
 
catcamstar said:
I read through the full thread, but just to "eliminate" any end-point weirdness: did you run the iperf test on a "premade" 1.5m CAT6 cable to verify there are no dropped package? If that's the case, maybe that old Sony is to blame for eating (recycling?) packets on the iperf itself.
I'm eager to know if you could improve more than the aforementionned 2.5% drop.

Good luck!
CC
Click to expand...
Thanks for reading through @catcamstar...so for all the iperf tests where I used a premade cable, it was a CAT5e instead of CAT6 but I have since found a premade CAT6 cable so could use that with the CAT6 cable I crimped to see if that eliminates all the packet loss...
 
  • Like
Reactions: catcamstar
alastairstevenson said:
A stray thought - on the original poor test results, what was the link speed as indicated by the network interface properties at each end?

Something I should know but don't - when one of the 4 pairs on a gigabit connection is broken, does the standard revert to a phased reduced link speed or to the next lower standard ie 100BaseT?
Click to expand...

RE: A broken wire, you'll get a 100Mbit link.

SimulatedBrokenCable.pngBluePairBroken_100Mbit.PNG

Early tests showed some cables with more than 100Mbit, so those at least would have negotiated a 1Gbit connection.

freddyq said:
So need more time to test them all but just tested cable 3 and the 1 to 8 lights all cycle through in order on both the main and remote tester so all seems OK there. The instructions for the tester say the G light should also light after 8 and this G light represents a wrong connection, short circuit or open circuit. But this didn't light up so I then used the tester on the cable I just crimped which got the good results and the G light also doesn't light up for that :confused:
Click to expand...

G on a basic continuity tester is going to be for [G]round (shielded cables). You can ignore it for your situation.
 
  • Like
Reactions: alastairstevenson and freddyq
freddyq said:
I then ran the same test as before, old Sony connected to my switch with a machine-terminated CAT5e cable (same one used in previous test) and running as iperf server. Dell (with ethernet to USB adapter) connected to switch using newly crimped CAT6 cable and running as iperf client. UDP results as follows:
Click to expand...

If you're going to run your tests through your switch as opposed to directly connecting the machines, you should retest on a different port anytime you get a poor result just to see if anything changes. The switch is an added variable and the more variables you eliminate, the more likely you are to identify the root cause of your problems.

Test to ensure direct connectivity between your two laptops works with one of your machine-terminated cables first. If both ends follow the standards like they should, you will be fine with a standard patch cable. You will need to assign a static IP address on the wired LAN interface at either end while testing since neither would have an address automatically assigned via DHCP by your router.

I don't know your level of expertise when it comes to computers; I made assumptions early on just because typical users don't ask questions about iperf results nor terminate their own network cabling. Feel free to ask if you have questions before you start so you don't wind up a situation where you can't get back online because you've made changes to your network configuration.
 
DavidR1 said:
RE: A broken wire, you'll get a 100Mbit link.

View attachment 50732View attachment 50733

Early tests showed some cables with more than 100Mbit, so those at least would have negotiated a 1Gbit connection.



G on a basic continuity tester is going to be for [G]round (shielded cables). You can ignore it for your situation.
Click to expand...
Thanks! So continuity test OK on cable 3 at least and I also checked the RJ45 ends on that cable and they aren't as bad as the short cable I sent pics of. I'm going to run the iperf test again on that cable and this time the other pre made cable I'll use will be a CAT6...
 
DavidR1 said:
If you're going to run your tests through your switch as opposed to directly connecting the machines, you should retest on a different port anytime you get a poor result just to see if anything changes. The switch is an added variable and the more variables you eliminate, the more likely you are to identify the root cause of your problems.

Test to ensure direct connectivity between your two laptops works with one of your machine-terminated cables first. If both ends follow the standards like they should, you will be fine with a standard patch cable. You will need to assign a static IP address on the wired LAN interface at either end while testing since neither would have an address automatically assigned via DHCP by your router.

I don't know your level of expertise when it comes to computers; I made assumptions early on just because typical users don't ask questions about iperf results nor terminate their own network cabling. Feel free to ask if you have questions before you start so you don't wind up a situation where you can't get back online because you've made changes to your network configuration.
Click to expand...
Actually I did wonder this about going through the switch but forgot to question it. There is no reason I need to do that, I can connect the cables straight into the laptops so can do that when I re-run the iperf tests on cable 3. But must admit I don't quite understand what you mean about assigning the IP addresses. My level of knowledge is probably somewhere in between. I'm not a complete noob, I am a bit of a techy and like to get stuck in with this stuff but I don't do it regularly, only when the need arises so that's why i guess knowledge can become rusty or limited.

Any chance you could provide some simple steps in terms of what I need to do to run the iperf tests with the laptops connected directly to each other?
 
  • Like
Reactions: catcamstar
freddyq said:
Actually I did wonder this about going through the switch but forgot to question it. There is no reason I need to do that, I can connect the cables straight into the laptops so can do that when I re-run the iperf tests on cable 3. But must admit I don't quite understand what you mean about assigning the IP addresses. My level of knowledge is probably somewhere in between. I'm not a complete noob, I am a bit of a techy and like to get stuck in with this stuff but I don't do it regularly, only when the need arises so that's why i guess knowledge can become rusty or limited.

Any chance you could provide some simple steps in terms of what I need to do to run the iperf tests with the laptops connected directly to each other?
Click to expand...

Typical home networks use DHCP from a "router" to assign IP addresses to devices on the internal network. I put router in quotes because in most cases, the device is actually some all-in-one consumer-oriented router/NAT/firewall/switch/wireless-access-point/VPN-endpoint/frozen-drink-blender type of deal. Sometimes it's provided by the ISP, and other times it's bought by the end user. What any particular space might have varies by provider, type of service, geographical location, and level of geekiness present in the home.

You indicated in your first post that you've got at least a "router, switch and other stuff", and it seems you typically use WiFi so something acts as an access point. Without knowing exactly what you're using or how your network is set up, it's possible that you manually assign static IP addresses for some or all devices on your network, or you might just let some device provide the network configuration automatically for any device you plug in or connect to your WiFi. If assigning IP addresses doesn't sound familiar, then you're most likely letting something on your network take care of that for you via DHCP.

Why does any of that matter? You'll lose that DHCP functionality when you plug the machines directly into one another after eliminating the switch from your test scenario. That means you'll need to do that part by hand or rely on address autoconfiguration (which is what's happening when you see a Windows machine with a 169.254.x.y address). I find it's best to work with known values all around to avoid confusion, so I prefer assigning the addresses manually from a private range.

When you're done testing directly and you move back to your wired LAN, the devices you've changed the network configuration on won't communicate with other hosts on the LAN because they're configured for a different network. (I'm oversimplifying here - there are situations where it could work - but hopefully it's enough to convey the idea.) To "get back on the network", you'll need to set them back to the way they were before you made changes - so it's important to know what that original state was. Again, most likely configured for DHCP which will take care of things like setting the IP address, netmask, DNS server(s) and default gateway such that things go back to "it just works."

And that way you're not mad that some guy on the internet broke your entire home network making you have to sit through an hour of your provider's tech support representative telling you to restart your cable modem or suggesting that you reboot your computer for the third time. :oops:


So, if you're going to eliminate everything else and test with directly connected machines, I would make note of the current settings used by your computers - presumably you can find the screens that look like this:

Ethernet_Adapters.PNG
Ethernet_Status.PNG
Ethernet_Properties.PNG

If you edit the properties for IPv4, you can see if you are configured to use DHCP like so:

IP_Address_Configuration.PNG

If not, you'll have settings there that you'll want to make a note of so you can change it back when done. To assign IP addresses manually, you simply enter the IP address you want to use - a different one for each device so there isn't a conflict - like so:

Static_IP_Dev1.PNGStatic_IP_Dev2.PNG

I've aribitrarily chosen these private addresses; there's nothing special about them. After each machine is set with a unique static IP address, they're no longer depending on any of your infrastructure for configuration or communication - just connect your patch cable between them and run your iperf tests using the IPs you just set. When you're done with all your testing, change the settings back to what they were in the beginning.
 
Last edited:
  • Like
Reactions: alastairstevenson
DavidR1 said:
Typical home networks use DHCP from a "router" to assign IP addresses to devices on the internal network. I put router in quotes because in most cases, the device is actually some all-in-one consumer-oriented router/NAT/firewall/switch/wireless-access-point/VPN-endpoint/frozen-drink-blender type of deal. Sometimes it's provided by the ISP, and other times it's bought by the end user. What any particular space might have varies by provider, type of service, geographical location, and level of geekiness present in the home.

You indicated in your first post that you've got at least a "router, switch and other stuff", and it seems you typically use WiFi so something acts as an access point. Without knowing exactly what you're using or how your network is set up, it's possible that you manually assign static IP addresses for some or all devices on your network, or you might just let some device provide the network configuration automatically for any device you plug in or connect to your WiFi. If assigning IP addresses doesn't sound familiar, then you're most likely letting something on your network take care of that for you via DHCP.

Why does any of that matter? You'll lose that DHCP functionality when you plug the machines directly into one another after eliminating the switch from your test scenario. That means you'll need to do that part by hand or rely on address autoconfiguration (which is what's happening when you see a Windows machine with a 169.254.x.y address). I find it's best to work with known values all around to avoid confusion, so I prefer assigning the addresses manually from a private range.

When you're done testing directly and you move back to your wired LAN, the devices you've changed the network configuration on won't communicate with other hosts on the LAN because they're configured for a different network. (I'm oversimplifying here - there are situations where it could work - but hopefully it's enough to convey the idea.) To "get back on the network", you'll need to set them back to the way they were before you made changes - so it's important to know what that original state was. Again, most likely configured for DHCP which will take care of things like setting the IP address, netmask, DNS server(s) and default gateway such that things go back to "it just works."

And that way you're not mad that some guy on the internet broke your entire home network making you have to sit through an hour of your provider's tech support representative telling you to restart your cable modem or suggesting that you reboot your computer for the third time. :oops:


So, if you're going to eliminate everything else and test with directly connected machines, I would make note of the current settings used by your computers - presumably you can find the screens that look like this:

View attachment 50740
View attachment 50741
View attachment 50742

If you edit the properties for IPv4, you can see if you are configured to use DHCP like so:

View attachment 50743

If not, you'll have settings there that you'll want to make a note of so you can change it back when done. To assign IP addresses manually, you simply enter the IP address you want to use - a different one for each device so there isn't a conflict - like so:

View attachment 50744View attachment 50745

I've aribitrarily chosen these private addresses; there's nothing special about them. After each machine is set with a unique static IP address, they're no long depending on any of your infrastructure for configuration or communication - just connect your patch cable between them and run your iperf tests using the IPs you just set. When you're done with all your testing, change the settings back to what they were in the beginning.
Click to expand...
I gotcha - all of that makes sense you'll be glad to know :) I'm using DHCP so going back to my original settings will be a bit simpler. So I will change the IP address settings on both laptops I've been using and assign IP addresses manually. I'll then first run the iperf tests using a pre-made CAT6 cable, then using my newly crimped CAT6 cable and then on cable 3 (I'm using cable 3 all the time because it's in my garage rather than sticking out of the front, side or back of my house so much easier to test :)
 
  • Like
Reactions: DavidR1
freddyq said:
I gotcha - all of that makes sense you'll be glad to know :) I'm using DHCP so going back to my original settings will be a bit simpler. So I will change the IP address settings on both laptops I've been using and assign IP addresses manually. I'll then first run the iperf tests using a pre-made CAT6 cable, then using my newly crimped CAT6 cable and then on cable 3 (I'm using cable 3 all the time because it's in my garage rather than sticking out of the front, side or back of my house so much easier to test :)
Click to expand...

Sounds like a plan. As a reminder, disable WiFi temporarily and close all other programs while testing. You don't need Windows updates or any other application crunching on something in the background. I don't know if you run any antivirus or other "security software" but I'd disable those too while testing just to know they're not a factor in any way.

Good call working in the garage to start. There's enough neighbors around the world worried about the sanity of certain IPCT members, what with them wandering around their yards and driveways at all hours... ;)
 
  • Like
Reactions: freddyq and alastairstevenson
DavidR1 said:
Sounds like a plan. As a reminder, disable WiFi temporarily and close all other programs while testing. You don't need Windows updates or any other application crunching on something in the background. I don't know if you run any antivirus or other "security software" but I'd disable those too while testing just to know they're not a factor in any way.

Good call working in the garage to start. There's enough neighbors around the world worried about the sanity of certain IPCT members, what with them wandering around their yards and driveways at all hours... ;)
Click to expand...
OK, strange and interesting results...maybe it's not my cables after all...

For these tests, the older Sony laptop is running as the iperf server and the newer Dell laptop is running as client. I'm using the -b 0 command to do the test using unlimited target bandwidth.

So first test was using a premade CAT6 cable. Results:

[ 5] local 192.168.0.57 port 51926 connected to 192.168.0.58 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 72.1 MBytes 603 Mbits/sec 9230
[ 5] 1.00-2.00 sec 54.9 MBytes 462 Mbits/sec 7030
[ 5] 2.00-3.00 sec 64.2 MBytes 538 Mbits/sec 8220
[ 5] 3.00-4.00 sec 85.3 MBytes 716 Mbits/sec 10920
[ 5] 4.00-5.00 sec 85.3 MBytes 716 Mbits/sec 10920
[ 5] 5.00-6.00 sec 85.8 MBytes 719 Mbits/sec 10980
[ 5] 6.00-7.00 sec 86.3 MBytes 725 Mbits/sec 11050
[ 5] 7.00-8.00 sec 85.8 MBytes 720 Mbits/sec 10980
[ 5] 8.00-9.00 sec 74.3 MBytes 623 Mbits/sec 9510
[ 5] 9.00-10.00 sec 84.8 MBytes 711 Mbits/sec 10850
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 779 MBytes 653 Mbits/sec 0.075 ms 441/99690 (0.44%)
[ 5] Sent 99690 datagrams

Looks pretty good as expected.

Next test with my newly crimped cable:

[ 5] local 192.168.0.57 port 63276 connected to 192.168.0.58 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 84.5 MBytes 708 Mbits/sec 10810
[ 5] 1.00-2.00 sec 87.9 MBytes 736 Mbits/sec 11250
[ 5] 2.00-3.00 sec 89.7 MBytes 753 Mbits/sec 11480
[ 5] 3.00-4.00 sec 89.0 MBytes 746 Mbits/sec 11390
[ 5] 4.00-5.00 sec 89.7 MBytes 753 Mbits/sec 11480
[ 5] 5.00-6.00 sec 89.7 MBytes 752 Mbits/sec 11480
[ 5] 6.00-7.00 sec 89.8 MBytes 753 Mbits/sec 11490
[ 5] 7.00-8.00 sec 90.5 MBytes 758 Mbits/sec 11580
[ 5] 8.00-9.00 sec 90.6 MBytes 760 Mbits/sec 11600
[ 5] 9.00-10.00 sec 89.5 MBytes 752 Mbits/sec 11460
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 891 MBytes 747 Mbits/sec 0.073 ms 5507/114020 (4.8%)
[ 5] Sent 114020 datagrams

Quite a lot more packet loss than the machine-terminated cable so I'm thinking definitely an issue with my cable or crimping or something else.

I thought I'd repeat the test on my cable a few times so the second time I got a similar amount of packet loss as the first but the third time I got quite a significant amount of loss:

[ 5] local 192.168.0.57 port 50180 connected to 192.168.0.58 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 87.1 MBytes 731 Mbits/sec 11150
[ 5] 1.00-2.00 sec 92.3 MBytes 775 Mbits/sec 11820
[ 5] 2.00-3.00 sec 92.3 MBytes 774 Mbits/sec 11810
[ 5] 3.00-4.00 sec 92.5 MBytes 775 Mbits/sec 11840
[ 5] 4.00-5.00 sec 92.2 MBytes 773 Mbits/sec 11800
[ 5] 5.00-6.00 sec 90.6 MBytes 761 Mbits/sec 11600
[ 5] 6.00-7.00 sec 89.4 MBytes 749 Mbits/sec 11440
[ 5] 7.00-8.00 sec 90.1 MBytes 756 Mbits/sec 11530
[ 5] 8.00-9.00 sec 89.7 MBytes 752 Mbits/sec 11480
[ 5] 9.00-10.00 sec 90.2 MBytes 756 Mbits/sec 11540
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 906 MBytes 760 Mbits/sec 0.084 ms 61041/116010 (53%)
[ 5] Sent 116010 datagrams

So I'm wondering what's changed given all I've done is re-run the test a few times. So I decided to plug the machine-terminated CAT6 back in and re-run the tests. Lo and behold I start seeing heavy packet losses even with that cable! For example:

[ 4] local 192.168.0.57 port 61626 connected to 192.168.0.58 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 87.0 MBytes 730 Mbits/sec 11140
[ 4] 1.00-2.00 sec 88.0 MBytes 738 Mbits/sec 11270
[ 4] 2.00-3.00 sec 86.8 MBytes 728 Mbits/sec 11110
[ 4] 3.00-4.00 sec 88.3 MBytes 740 Mbits/sec 11300
[ 4] 4.00-5.00 sec 89.5 MBytes 750 Mbits/sec 11450
[ 4] 5.00-6.00 sec 90.5 MBytes 760 Mbits/sec 11590
[ 4] 6.00-7.00 sec 87.8 MBytes 737 Mbits/sec 11240
[ 4] 7.00-8.00 sec 89.8 MBytes 753 Mbits/sec 11500
[ 4] 8.00-9.00 sec 89.7 MBytes 753 Mbits/sec 11480
[ 4] 9.00-10.00 sec 89.1 MBytes 747 Mbits/sec 11400
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 887 MBytes 744 Mbits/sec 0.078 ms 31158/113479 (27%)
[ 4] Sent 113479 datagrams

I re-ran the test a few times on the machine-terminated cable and I got similar or sometimes even worse packet loss, up to 40%.

So now I'm getting these dodgy results on a perfectly good machine-terminated CAT6 cable and I'm now suspecting one or both of the laptops and hardware within. More so the older Sony laptop because it's, well older, but at least I've got less reason to suspect my cables are the issue.

Not sure what you guys think is going on....?
 
freddyq said:
So now I'm getting these dodgy results on a perfectly good machine-terminated CAT6 cable and I'm now suspecting one or both of the laptops and hardware within. More so the older Sony laptop because it's, well older, but at least I've got less reason to suspect my cables are the issue.

Not sure what you guys think is going on....?
Click to expand...

This takes me back to my first post on this topic... :facepalm:

Old machines and USB adapters aren't my favorite!
 
You must log in or register to reply here.
Top Bottom