Advice on iperf3 test results

F

freddyq

Getting the hang of it
Nov 18, 2016
254
39
Hi all, looking for help interpreting iperf3 test results please...I had cat6 cable run to four locations around my house a couple of years ago as part of a renovation so that in future I could install PoE cams in these locations. I'm now ready to install the cams so ran some tests on each cable using iperf to ensure they're still OK. 3 of the cables have been tied up with the RJ45 end protected but they have been exposed to the elements so I just wanted to make sure cables are good before I buy the cams. The other cable has been in a garage.

The TCP test results for each cable seemed to be OK, returning 30+ Mbits/sec bandwidth on 2 cables and around 25 Mbits/sec on the other two (not sure why the difference btw so could do with an explanation of that).

With the UDP results however I noticed that the 'Lost/Total Datagrams' percentage seemed to be quite high on all but one of the cables, although I have no idea how I should be interpreting these results or whether I've run the UDP test wrong so wanted opinion from those much more knowledgeable than me on here! The results are below for each cable and I would greatly appreciate advice on whether these results may cause issues with IP cams or if I have nothing to worry about.

I used the "-b 0" command to set the target bandwidth to the max for the test. I did also run the same tests on all the cables with target bandwidth set to 100 Mbit/sec so can post those results if needed.

TIA!

Cable 1
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.06 sec 2.34 MBytes 18.6 Mbits/sec 300
[ 5] 1.06-2.01 sec 1.88 MBytes 16.5 Mbits/sec 240
[ 5] 2.01-3.00 sec 2.50 MBytes 21.2 Mbits/sec 320
[ 5] 3.00-4.00 sec 2.34 MBytes 19.7 Mbits/sec 300
[ 5] 4.00-5.01 sec 2.27 MBytes 18.8 Mbits/sec 290
[ 5] 5.01-6.04 sec 2.66 MBytes 21.6 Mbits/sec 340
[ 5] 6.04-7.01 sec 2.42 MBytes 21.0 Mbits/sec 310
[ 5] 7.01-8.02 sec 2.73 MBytes 22.6 Mbits/sec 350
[ 5] 8.02-9.03 sec 2.89 MBytes 24.0 Mbits/sec 370
[ 5] 9.03-10.04 sec 3.05 MBytes 25.3 Mbits/sec 390
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.04 sec 25.1 MBytes 20.9 Mbits/sec 5.404 ms 1063/3209 (33%)
[ 5] Sent 3209 datagrams

Cable 2
[ 5] local 192.168.0.21 port 62347 connected to 192.168.0.36 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 32.3 MBytes 270 Mbits/sec 4130
[ 5] 1.00-2.00 sec 33.4 MBytes 280 Mbits/sec 4270
[ 5] 2.00-3.00 sec 33.0 MBytes 278 Mbits/sec 4230
[ 5] 3.00-4.00 sec 31.0 MBytes 260 Mbits/sec 3970
[ 5] 4.00-5.00 sec 28.2 MBytes 237 Mbits/sec 3610
[ 5] 5.00-6.00 sec 29.5 MBytes 247 Mbits/sec 3780
[ 5] 6.00-7.00 sec 30.3 MBytes 255 Mbits/sec 3880
[ 5] 7.00-8.00 sec 32.7 MBytes 274 Mbits/sec 4180
[ 5] 8.00-9.00 sec 31.2 MBytes 262 Mbits/sec 3990
[ 5] 9.00-10.00 sec 29.8 MBytes 250 Mbits/sec 3810
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 311 MBytes 261 Mbits/sec 5.480 ms 36587/39719 (92%)
[ 5] Sent 39719 datagrams

Cable 3
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.01 sec 3.98 MBytes 33.2 Mbits/sec 510
[ 5] 1.01-2.02 sec 4.30 MBytes 35.7 Mbits/sec 550
[ 5] 2.02-3.02 sec 3.67 MBytes 30.6 Mbits/sec 470
[ 5] 3.02-4.01 sec 3.36 MBytes 28.4 Mbits/sec 430
[ 5] 4.01-5.01 sec 3.59 MBytes 30.4 Mbits/sec 460
[ 5] 5.01-6.02 sec 3.75 MBytes 30.9 Mbits/sec 480
[ 5] 6.02-7.01 sec 3.67 MBytes 31.2 Mbits/sec 470
[ 5] 7.01-8.00 sec 3.67 MBytes 31.0 Mbits/sec 470
[ 5] 8.00-9.02 sec 3.75 MBytes 30.9 Mbits/sec 480
[ 5] 9.02-10.02 sec 3.67 MBytes 30.8 Mbits/sec 470
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.02 sec 37.4 MBytes 31.3 Mbits/sec 1.831 ms 166/4790 (3.5%)
[ 5] Sent 4790 datagrams

Cable 4
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 25.4 MBytes 213 Mbits/sec 3250
[ 5] 1.00-2.00 sec 29.3 MBytes 245 Mbits/sec 3750
[ 5] 2.00-3.00 sec 29.4 MBytes 247 Mbits/sec 3760
[ 5] 3.00-4.00 sec 29.4 MBytes 246 Mbits/sec 3760
[ 5] 4.00-5.00 sec 29.3 MBytes 246 Mbits/sec 3750
[ 5] 5.00-6.00 sec 30.2 MBytes 254 Mbits/sec 3860
[ 5] 6.00-7.00 sec 29.1 MBytes 244 Mbits/sec 3720
[ 5] 7.00-8.00 sec 28.0 MBytes 235 Mbits/sec 3580
[ 5] 8.00-9.00 sec 29.2 MBytes 245 Mbits/sec 3740
[ 5] 9.00-10.00 sec 29.4 MBytes 247 Mbits/sec 3760
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 289 MBytes 242 Mbits/sec 3.387 ms 33874/36902 (92%)
[ 5] Sent 36902 datagrams
 
Can you share some information about the endpoints and network topology used to produce these test results? Before diving into what the results might mean, it'd help to know that your tests aren't being skewed by the hardware being used....
 
Sure - I'm no network expert by the way so I'll give you my plain english description :) I've basically got all the CAT6 cables around the house (including these 4) running to one location where I've got router, switch and other stuff. So at this end I used an old Sony Vaio laptop to plug the cable into the ethernet port and set as the iperf server. At the other end which is where the cables are running to various locations around my house, I connected the cable to a USB to ethernet adapter (because my 2nd newer laptop doesn't have an ethernet connection built in) and plugged that into the USB port. I then run the test.

Every time I tested a different location I obviously changed the cable plugged into the server end to match the location being tested.

Does that help?
 
  • Like
Reactions: djernie
alastairstevenson said:
These results are way, way below what should be achieved and I believe are most likely a reflection of the capabilities of the PCs as opposed to the cables.
Click to expand...
OK so given my objective is to validate that the cables are still good for power and data for the IP cams, is there another way I can test them?
 
A simple method is to check that the link speed auto detects at gigabit, then to run high traffic through it for a few minutes and check on the switch port counters that there are zero errors.
That does though generally need a managed switch to be able to see the counts, or a Linux device on one end.
 
alastairstevenson said:
A simple method is to check that the link speed auto detects at gigabit, then to run high traffic through it for a few minutes and check on the switch port counters that there are zero errors.
That does though generally need a managed switch to be able to see the counts, or a Linux device on one end.
Click to expand...
Hmm unfortunately I have neither a managed switch nor a linux machine.

Any other methods?
 
alastairstevenson said:
These results are way, way below what should be achieved and I believe are most likely a reflection of the capabilities of the PCs as opposed to the cables.
Click to expand...

Yup, this. :goodpost:

Here's a more typical result for a basic gigabit network:

------------------------------------------------------------ Client connecting to iperf, TCP port 5001 with pid 856 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.0.17.150 port 51002 connected with 10.0.17.52 port 5001 [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT [ 3] 0.00-10.00 sec 1.04 GBytes 895 Mbits/sec 1/0 0 322K/2117 us
 
freddyq said:
Hmm unfortunately I have neither a managed switch nor a linux machine.

Any other methods?
Click to expand...

Having access to a temporary linux machine could be as simple as booting a live image, but with USB adapters in the mix, and potentially the same hardware limitations etc. it's probably not a rabbit hole you need to go down.

The approach suggested by @alastairstevenson would have been my next go-to suggestion as well. I can't think of any other ways to test throughput with the hardware you have and without access to tools you're not likely to have either. Know anyone that might be willing to loan you hardware temporarily?

Were you planning on running the cameras standalone with SD cards for storing alerts or was there a plan for an NVR or something like Blue Iris?
 
  • Like
Reactions: alastairstevenson
DavidR1 said:
Having access to a temporary linux machine could be as simple as booting a live image, but with USB adapters in the mix, and potentially the same hardware limitations etc. it's probably not a rabbit hole you need to go down.

The approach suggested by @alastairstevenson would have been my next go-to suggestion as well. I can't think of any other ways to test throughput with the hardware you have and without access to tools you're not likely to have either. Know anyone that might be willing to loan you hardware temporarily?

Were you planning on running the cameras standalone with SD cards for storing alerts or was there a plan for an NVR or something like Blue Iris?
Click to expand...
I definitely intend to use an NVR or Blue Iris to store the footage.

I don't really think there is anyone I could get loan hardware from unfortunately but I'll look into it - so what I'm after is a managed switch?

What's the worst case scenario here? Would these results prevent me using them for the IP cams?
 
freddyq said:
I definitely intend to use an NVR or Blue Iris to store the footage.
Click to expand...

If you had a PC for Blue Iris, that would give you a valid endpoint to run iperf against, and you could even boot a live version of Linux on it if you wanted. That doesn't help you if you haven't already procured one however.

freddyq said:
I don't really think there is anyone I could get loan hardware from unfortunately but I'll look into it - so what I'm after is a managed switch?
Click to expand...

It was a long shot but I figured I'd ask. A managed switch would let you see errors on specific ports while trying to push a lot of traffic over those wires. You'd still need devices on either end of the connection capable of pushing that amount of traffic through the switch in the first place, or at least one such device if the switch itself can run a bandwidth testing tool.

Hardware like a borrowed Raspberry Pi 4, a modern laptop with built in Ethernet - basically anything that should more or less be capable of saturating a gigabit link would do the job as an endpoint. Heck even the built-in speed tests on some streaming devices could show if you really were getting sub-20Mbit speeds as shown in some of your results.

freddyq said:
What's the worst case scenario here? Would these results prevent me using them for the IP cams?
Click to expand...

Some of your results are particularly bad - but again, the test is suspect at best with the hardware you've used.

Honestly, if the cabling was installed professionally and tested at the time of installation, my guess is that your cabling is fine - assuming you don't have reasons to suspect otherwise beyond them being exposed to the elements (i.e., no one has physically damaged the cabling since it was installed like putting a staple through it somewhere or getting something caught in it and pulling, no known mice activity, etc.) If the cabling was the right kind, rated for exterior use, it should last outdoors for many years.

If the cabling did turn out to be a problem, would you scrap your camera plan entirely? If not, then there's really no harm in just trying it as is and dealing with any problems that do turn up.
 
  • Like
Reactions: djernie and alastairstevenson
freddyq said:
Hmm unfortunately I have neither a managed switch nor a linux machine.
Click to expand...
An NVR, IP camera, NAS, or even a router can provide some useful stats.
A NAS example. Overruns and dropped frames are not cable issues (congestion). Errors can be. A zero count is good. eth0 is the main interface.

Code: 
[~] # ifconfig
br0       Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:02 
          inet addr:192.168.1.202  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1181992898 errors:0 dropped:4631 overruns:0 frame:0
          TX packets:438030659 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2149033275847 (1.9 TiB)  TX bytes:41242924396 (38.4 GiB)

docker0   Link encap:Ethernet  HWaddr C6:74:9F:F8:19:3D 
          inet addr:10.0.5.1  Bcast:10.0.5.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:489481 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:58528572 (55.8 MiB)

eth0      Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:02 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1565784965 errors:0 dropped:204272 overruns:0 frame:0
          TX packets:444527486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2190922675835 (1.9 TiB)  TX bytes:41671710322 (38.8 GiB)
          Memory:fe300000-fe31ffff

eth1      Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:03 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe200000-fe21ffff

eth2      Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:04 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe400000-fe41ffff

eth3      Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:05 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe500000-fe51ffff

eth4      Link encap:Ethernet  HWaddr 24:5E:BE:0B:B4:06 
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:84 Base address:0xe000

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:327526108 errors:0 dropped:0 overruns:0 frame:0
          TX packets:327526108 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:158796367670 (147.8 GiB)  TX bytes:158796367670 (147.8 GiB)

lxcbr0    Link encap:Ethernet  HWaddr FE:84:78:E5:01:CF 
          inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:489482 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:58528556 (55.8 MiB)

[~] #
 
DavidR1 said:
If you had a PC for Blue Iris, that would give you a valid endpoint to run iperf against, and you could even boot a live version of Linux on it if you wanted. That doesn't help you if you haven't already procured one however.



It was a long shot but I figured I'd ask. A managed switch would let you see errors on specific ports while trying to push a lot of traffic over those wires. You'd still need devices on either end of the connection capable of pushing that amount of traffic through the switch in the first place, or at least one such device if the switch itself can run a bandwidth testing tool.

Hardware like a borrowed Raspberry Pi 4, a modern laptop with built in Ethernet - basically anything that should more or less be capable of saturating a gigabit link would do the job as an endpoint. Heck even the built-in speed tests on some streaming devices could show if you really were getting sub-20Mbit speeds as shown in some of your results.



Some of your results are particularly bad - but again, the test is suspect at best with the hardware you've used.

Honestly, if the cabling was installed professionally and tested at the time of installation, my guess is that your cabling is fine - assuming you don't have reasons to suspect otherwise beyond them being exposed to the elements (i.e., no one has physically damaged the cabling since it was installed like putting a staple through it somewhere or getting something caught in it and pulling, no known mice activity, etc.) If the cabling was the right kind, rated for exterior use, it should last outdoors for many years.

If the cabling did turn out to be a problem, would you scrap your camera plan entirely? If not, then there's really no harm in just trying it as is and dealing with any problems that do turn up.
Click to expand...
Yea you're right about the PC for Blue Iris although as you guessed, I haven't actually bought one yet. Thought I'd get the cameras setup first and working and then decide what I do about NVR or Blue Iris.

In terms of the cabling, I bought a reel of CAT6 cable at the time of the house renovations and asked the builder to run it from and to my desired points. I then crimped the RJ45 ends on myself some time later so I could just do basic checks but nothing like the iperf stuff. Have to say it didn't occur to me at the time that I should really have used cable rated for exterior use so it's just standard CAT6 cable. We have had some issues with mice in the past so annoyingly I can't rule out that they may have tampered with the cable somewhere between the end points but I doubt it.

The situation I have at the moment is that I'm about to have some extension work done so I thought if these CAT6 cables are OK I'll buy the IP cams and install them at the same time because the cables have all been run. If the cables aren't OK, I won't be able to re-run new cables as discreetly as the existing ones have been run so I would then just go for Nest Cams which just need power cables run to sockets which I can have done as part of the building work. That's why I was hoping to have a definitive answer on the status of the cables before ordering the cams..
 
Understood. I'd do this as a starting point (assuming you have a couple of known good patch cables): connect the Sony and your modern laptop directly to your switch and run some iperf tests to see what your best-case results turn out to be with short, machine-terminated cables. Make sure the USB->Ethernet adapter is plugged in to a USB3 port as USB2 will limit your maximum throughput well below gigabit speeds. Depending on those results, we can see if it's worth investing more time testing the cables you're concerned about with the hardware you have available.

As for the CAT6 not being outdoor rated, UV will eventually destroy the outer jacket but it's not uncommon for it to still last for many years - at least in my experience. You can sleeve exposed sections with conduit or even paint them to match the surface they're going to be attached to for some added protection.

Lastly, if you crimped the connections on the wires, and you consistently get poor results testing the same run, it's worth a few wasted connectors to try re-crimping the ends. If you do decide to go this route, replace one end at a time, re-test, and only do the other end if you still have issues.
 
  • Like
Reactions: alastairstevenson and SouthernYankee
DavidR1 said:
Understood. I'd do this as a starting point (assuming you have a couple of known good patch cables): connect the Sony and your modern laptop directly to your switch and run some iperf tests to see what your best-case results turn out to be with short, machine-terminated cables. Make sure the USB->Ethernet adapter is plugged in to a USB3 port as USB2 will limit your maximum throughput well below gigabit speeds. Depending on those results, we can see if it's worth investing more time testing the cables you're concerned about with the hardware you have available.

As for the CAT6 not being outdoor rated, UV will eventually destroy the outer jacket but it's not uncommon for it to still last for many years - at least in my experience. You can sleeve exposed sections with conduit or even paint them to match the surface they're going to be attached to for some added protection.

Lastly, if you crimped the connections on the wires, and you consistently get poor results testing the same run, it's worth a few wasted connectors to try re-crimping the ends. If you do decide to go this route, replace one end at a time, re-test, and only do the other end if you still have issues.
Click to expand...
This makes a lot of sense - I will definitely do that. I do have some known good patch cables so can do those best case tests at least. And no issues re-crimping either - I have plenty of kit and it'd be worth it if it works. I suppose I don't need to worry about cable 3 which only had 3.5% loss, or do I?

As for the CAT6, in two of the locations I was planning for it to go straight into the camera as it comes out of the wall so none of the cable would be exposed to UV. In the other location, I probably will need to run it along a short wall and there I would definitely put it inside some conduit.

Once I've done the tests with the known good patch cable I will post them on here...

Thanks a lot for the advice, really helpful.
 
DavidR1 said:
Understood. I'd do this as a starting point (assuming you have a couple of known good patch cables): connect the Sony and your modern laptop directly to your switch and run some iperf tests to see what your best-case results turn out to be with short, machine-terminated cables. Make sure the USB->Ethernet adapter is plugged in to a USB3 port as USB2 will limit your maximum throughput well below gigabit speeds. Depending on those results, we can see if it's worth investing more time testing the cables you're concerned about with the hardware you have available.

As for the CAT6 not being outdoor rated, UV will eventually destroy the outer jacket but it's not uncommon for it to still last for many years - at least in my experience. You can sleeve exposed sections with conduit or even paint them to match the surface they're going to be attached to for some added protection.

Lastly, if you crimped the connections on the wires, and you consistently get poor results testing the same run, it's worth a few wasted connectors to try re-crimping the ends. If you do decide to go this route, replace one end at a time, re-test, and only do the other end if you still have issues.
Click to expand...
OK @DavidR1 I've run some tests with machine-terminated CAT5e cables. As before I ran the iperf server on the older Sony laptop and the client on the newer Dell laptop using the USB to ethernet adapter. Both USB ports on my Dell are USB3. Here are the results of the UDP tests again set to use max bandwidth with the '-b 0' command:

[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 85.2 MBytes 714 Mbits/sec 10900
[ 5] 1.00-2.00 sec 86.2 MBytes 723 Mbits/sec 11030
[ 5] 2.00-3.00 sec 85.1 MBytes 713 Mbits/sec 10890
[ 5] 3.00-4.00 sec 85.9 MBytes 722 Mbits/sec 11000
[ 5] 4.00-5.00 sec 74.9 MBytes 628 Mbits/sec 9590
[ 5] 5.00-6.00 sec 67.9 MBytes 568 Mbits/sec 8690
[ 5] 6.00-7.00 sec 72.5 MBytes 610 Mbits/sec 9280
[ 5] 7.00-8.00 sec 82.6 MBytes 692 Mbits/sec 10570
[ 5] 8.00-9.00 sec 84.4 MBytes 708 Mbits/sec 10800
[ 5] 9.00-10.00 sec 84.8 MBytes 711 Mbits/sec 10860
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 809 MBytes 679 Mbits/sec 0.148 ms 13258/103610 (13%)
[ 5] Sent 103610 datagrams

I then swapped the client and server machines just for additional test results so now Dell running as server and Sony as client:

[ 5] local 192.168.0.8 port 53467 connected to 192.168.0.56 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 82.5 MBytes 692 Mbits/sec 10560
[ 5] 1.00-2.00 sec 89.9 MBytes 755 Mbits/sec 11510
[ 5] 2.00-3.00 sec 88.0 MBytes 738 Mbits/sec 11270
[ 5] 3.00-4.00 sec 88.3 MBytes 741 Mbits/sec 11300
[ 5] 4.00-5.00 sec 86.6 MBytes 727 Mbits/sec 11090
[ 5] 5.00-6.00 sec 85.3 MBytes 716 Mbits/sec 10920
[ 5] 6.00-7.00 sec 87.1 MBytes 730 Mbits/sec 11150
[ 5] 7.00-8.00 sec 87.3 MBytes 732 Mbits/sec 11170
[ 5] 8.00-9.00 sec 86.6 MBytes 726 Mbits/sec 11080
[ 5] 9.00-10.00 sec 84.4 MBytes 708 Mbits/sec 10800
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 866 MBytes 726 Mbits/sec 0.049 ms 3620/110843 (3.3%)
[ 5] Sent 110843 datagrams

Finally, I ran the tests again with the Sony set as the server, Dell as client but this time I swapped the machine-terminated cable connecting the Dell (client) to the switch with a CAT6 cable I have crimped myself (this cable is normally in use to connect my router to my switch). The cable connecting the Sony to the switch was still the machine-terminated one used in the other tests. Results:

[ 5] local 192.168.0.21 port 62366 connected to 192.168.0.36 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 41.9 MBytes 351 Mbits/sec 5360
[ 5] 1.00-2.00 sec 44.0 MBytes 369 Mbits/sec 5630
[ 5] 2.00-3.00 sec 45.2 MBytes 380 Mbits/sec 5790
[ 5] 3.00-4.00 sec 44.8 MBytes 376 Mbits/sec 5740
[ 5] 4.00-5.00 sec 45.1 MBytes 378 Mbits/sec 5770
[ 5] 5.00-6.00 sec 45.1 MBytes 378 Mbits/sec 5770
[ 5] 6.00-7.00 sec 45.2 MBytes 380 Mbits/sec 5790
[ 5] 7.00-8.00 sec 45.2 MBytes 379 Mbits/sec 5780
[ 5] 8.00-9.00 sec 45.5 MBytes 381 Mbits/sec 5820
[ 5] 9.00-10.00 sec 44.9 MBytes 377 Mbits/sec 5750
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 447 MBytes 375 Mbits/sec 1.497 ms 52254/57198 (91%)
[ 5] Sent 57198 datagrams

Keen to get your view but the results with the machine-terminated cable seem much more like the typical bandwidth results you posted. As soon as I used the CAT6 cable I crimped the bandwidth dropped and the lost datagrams increased massively. So I'm getting the feeling my crimping is to blame...:confused: I have results in all three scenarios for the TCP test and the UDP test set to 100m bandwidth limit so can post those if needed...
 
freddyq said:
a CAT6 cable I have crimped myself (this cable is normally in use to connect my router to my switch
Click to expand...
What length is that cable?
Quite a difference in the results.

With apologies for the dumb question - just trying to guess what might be the problem here -
You've confirmed that the wire colour sequence for your crimping is correct, and is T568B.
Can you confirm, maybe by comparison with the pre-made cable, that the wires are set in the correct direction? ie Pin 1 isn't actually Pin 8.
 
You must log in or register to reply here.
Top Bottom