I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit. Presumably if they aren't working too well one will see errors and retries at the hardware level - is there a tool for monitoring this?
Mostly these cables have just one switch between the ends but there are a couple where there may be two switches involved.
On 4 December 2011 11:55, Chris Green cl@isbd.net wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit.
You could perhaps run iperf with each cable in turn between 2 machines and no switches, and compare any performance differences?
I have no idea what proper quality control tests cable manufacturers do.
Regards, Srdjan
On Sun, Dec 04, 2011 at 12:13:02PM +0000, Srdjan Todorovic wrote:
On 4 December 2011 11:55, Chris Green cl@isbd.net wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit.
You could perhaps run iperf with each cable in turn between 2 machines and no switches, and compare any performance differences?
I have no idea what proper quality control tests cable manufacturers do.
I'm not so worried about the basic quality of the cable but it has been roughly handled in places and the connections may not be perfect.
Does the switch offer you a counter of bad ethernet frames?
You can get the info for the PC end from ethtool: mephi@mephi-server:~$ sudo ethtool -S eth0 NIC statistics: tx_packets: 0 rx_packets: 0 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 0 broadcast: 0 multicast: 0 tx_aborted: 0 tx_underrun: 0
specifically you're looking for rx_errors, the other end (the switch) will need to report on it's rx_errors
If your switch can't do that you can always connect two PCs back to back with the cable.
To test, you'll need to spam a whole load of data over the cable using something like iPerf and then check those counters. BTW, There's no way (that I know of) to reset those counters (on linux, a lot of switches can) except by restarting the PC.
Regards,
Matt
-----Original Message----- From: main-bounces@lists.alug.org.uk [mailto:main-bounces@lists.alug.org.uk] On Behalf Of Chris Green Sent: 04 December 2011 12:48 To: main@lists.alug.org.uk Subject: Re: [ALUG] How to test if a cat5 (or cat6) is working as well as it should?
On Sun, Dec 04, 2011 at 12:13:02PM +0000, Srdjan Todorovic wrote:
On 4 December 2011 11:55, Chris Green cl@isbd.net wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit.
You could perhaps run iperf with each cable in turn between 2 machines and no switches, and compare any performance differences?
I have no idea what proper quality control tests cable manufacturers do.
I'm not so worried about the basic quality of the cable but it has been roughly handled in places and the connections may not be perfect.
-- Chris Green
_______________________________________________ main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
On Sun, Dec 04, 2011 at 01:01:07PM -0000, Matthew Green wrote:
Does the switch offer you a counter of bad ethernet frames?
You can get the info for the PC end from ethtool: mephi@mephi-server:~$ sudo ethtool -S eth0 NIC statistics: tx_packets: 0 rx_packets: 0 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 0 broadcast: 0 multicast: 0 tx_aborted: 0 tx_underrun: 0
specifically you're looking for rx_errors, the other end (the switch) will need to report on it's rx_errors
If your switch can't do that you can always connect two PCs back to back with the cable.
To test, you'll need to spam a whole load of data over the cable using something like iPerf and then check those counters. BTW, There's no way (that I know of) to reset those counters (on linux, a lot of switches can) except by restarting the PC.
Thanks, that sounds like the sort of thing I'm after. Presumably as long as I see no tx_errors:, rx_errors: or rx_missed: then there's nothing seriously broken anywhere.
The cable I'm most interested in from this point of view is one that run's to the backup system in the garage so I can look at the statistics over a few days of backups to see if there's anything wrong. Both my desktop system and the garage backup system are alway on so the counters won't get cleared.
The cable I'm most interested in from this point of view is one that run's to the backup system in the garage so I can look at the statistics over a few days of backups to see if there's anything wrong.
Couldn't you just calculate the md5 checksums and compare? The odd missed packet here and there isn't usually a big deal in the bigger picture, right? TCP recovers from packet loss so it's a bit of a non-issue as long as the data is getting from A to B.
-Simon
On Sun, Dec 04, 2011 at 10:05:06PM +0000, Simon Elliott wrote:
The cable I'm most interested in from this point of view is one that run's to the backup system in the garage so I can look at the statistics over a few days of backups to see if there's anything wrong.
Couldn't you just calculate the md5 checksums and compare? The odd missed packet here and there isn't usually a big deal in the bigger picture, right? TCP recovers from packet loss so it's a bit of a non-issue as long as the data is getting from A to B.
I really just want to know if it is actually running at (or close to) Gigabit speed. OK, in reality it's limited by the speed of the backup system but I'd rather not have anything else slowing things down.
On 5 December 2011 11:23, Chris Green cl@isbd.net wrote:
I really just want to know if it is actually running at (or close to) Gigabit speed. OK, in reality it's limited by the speed of the backup system but I'd rather not have anything else slowing things down.
Then user iperf. It will easily max out your links (even if you have to run multiple instances) as you may hit disk I/O limits long before the link capacity is full, when copying files.
On Mon, 5 Dec 2011 11:23:08 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Dec 04, 2011 at 10:05:06PM +0000, Simon Elliott wrote:
The cable I'm most interested in from this point of view is one that run's to the backup system in the garage so I can look at the statistics over a few days of backups to see if there's anything wrong.
Couldn't you just calculate the md5 checksums and compare? The odd missed packet here and there isn't usually a big deal in the bigger picture, right? TCP recovers from packet loss so it's a bit of a non-issue as long as the data is getting from A to B.
I really just want to know if it is actually running at (or close to) Gigabit speed. OK, in reality it's limited by the speed of the backup system but I'd rather not have anything else slowing things down.
Care to tell us what you eventually did and what you found?
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On Tue, Dec 06, 2011 at 06:39:40PM +0000, mick wrote:
On Mon, 5 Dec 2011 11:23:08 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Dec 04, 2011 at 10:05:06PM +0000, Simon Elliott wrote:
The cable I'm most interested in from this point of view is one that run's to the backup system in the garage so I can look at the statistics over a few days of backups to see if there's anything wrong.
Couldn't you just calculate the md5 checksums and compare? The odd missed packet here and there isn't usually a big deal in the bigger picture, right? TCP recovers from packet loss so it's a bit of a non-issue as long as the data is getting from A to B.
I really just want to know if it is actually running at (or close to) Gigabit speed. OK, in reality it's limited by the speed of the backup system but I'd rather not have anything else slowing things down.
Care to tell us what you eventually did and what you found?
Well, not a lot so far! :-)
The most useful tool so far seems to be ethtool which can report any ethernet errors, it's not reporting any at the moment:-
NIC statistics: tx_packets: 65837 rx_packets: 72128 tx_errors: 0 rx_errors: 0 rx_missed: 0 align_errors: 0 tx_single_collisions: 0 tx_multi_collisions: 0 unicast: 68200 broadcast: 3928 multicast: 0 tx_aborted: 0 tx_underrun: 0
I need to run it from both ends still.
On Sun, 4 Dec 2011 11:55:14 +0000 Chris Green cl@isbd.net allegedly wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit. Presumably if they aren't working too well one will see errors and retries at the hardware level - is there a tool for monitoring this?
A Time Domain Reflectometer (TDR) is usually used to identify faults, breaks, poor terminations, degradation in connections etc. Used to be used a lot on old co-ax ethernet cable testing.
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On Sun, Dec 04, 2011 at 12:34:57PM +0000, mick wrote:
On Sun, 4 Dec 2011 11:55:14 +0000 Chris Green cl@isbd.net allegedly wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit. Presumably if they aren't working too well one will see errors and retries at the hardware level - is there a tool for monitoring this?
A Time Domain Reflectometer (TDR) is usually used to identify faults, breaks, poor terminations, degradation in connections etc. Used to be used a lot on old co-ax ethernet cable testing.
Sounds a bit excessive! :-)
I was hoping/wondering if there were any software diagnostic tools for digging around in the ethernet interface hardware and seeing if anything was amiss.
On 04 Dec 11:55, Chris Green wrote:
I have a number of quite long (i.e. 30 metres or more) cat5e cables strung about the place and would like to test how 'clean' they are.
It's easy enough to test their basic integrity (i.e. if all 8 wires are correctly connected) and I have done that. However I'd like to see if they are actually good enough to provide maximum performance when running gigabit. Presumably if they aren't working too well one will see errors and retries at the hardware level - is there a tool for monitoring this?
Mostly these cables have just one switch between the ends but there are a couple where there may be two switches involved.
Create a 100M file on the system that you're testing the connection with using something like: dd if=/dev/urandom of=1Gfileorubbish bs=$((1024*1024)) count=100
We use urandom, because random will take a LOOONG time waiting for the required entropy for that operation...
Now, on that machine do something like: cat 1Gfileorubbish | nc -l serverip 10234
Then on the other machine: time nc serverip 10234 > /dev/null
Use the realtime and calculate your byterate as such...
e.g. over localhost I did...
$ cat 100Mfileocrap | nc -l localhost 10234
and in another terminal:
$ time nc localhost 10234 > /dev/null
real 0m2.275s user 0m0.036s sys 0m0.376s
$
So that took 2.275 seconds to transfer 100M of data, so (ignoring TCP overheads, etc):
; (100/2.25)*8 ~355.55555555555555555556
Which is 355Mb/s give or take.
I'm thinking I'm probably at that point actually stuck on disk IO, as that's approximately 44MB/s.
Anyways - you're most likely to get hit by disk io rather than network... 1Gb/s is ~ 125MB/s then take in to account TCP overhead and you're probably around 100MB/s... which is probably getting close to the limits of disks (unless you've got really good disks and there's no seeking and everything is being read in sequence, in which case, you're doing better than anyone else I know in the world.
If you're after anything more extensive than that, you're looking at paying Good Money for a top end cable tester of doom.
-
Brett Parker -
Chris Green -
James Bensley -
Matthew Green -
mick -
Simon Elliott -
Srdjan Todorovic