It seems reasonable that jitter will be a big factor in the performance of CAT5e/6 runs used for HDMI baluns. I ran two high quality unshielded CAT5e cables and two high quality shielded (but ungrounded by me) CAT6 cables.
They cross over multiple power lines and unfortunately run parallel to power lines for about 11 foot of the ~ 30 foot run.
On the server:
<pre>iperf -s -w 128k -u</pre>
This means start iperf server with a 128KB buffer in UDP mode. UDP best reflects the nature of traffic of HDMI over ethernet.
On the client:
<pre>iperf -c serverip -u -b 1000m -w 128k -t 120</pre>
This means start the client and connect to serverip, use UDP and send traffic at gigabit speeds for 120 seconds. I needed to run the test for at least 120 seconds to get consistent jitter results.
First I tested with a 3 foot CAT5e cable connected directly to the switch, this represents ‘ideal’ performance. The same short cable was connected to the ends of the long CAT5e and CAT6 runs.
[ ID], Interval, Transfer, Bandwidth, Jitter, Lost/Total Datagrams
IDEAL, 0.0-120.0 sec, 9.65 GBytes, 691 Mbits/sec, 0.013 ms, 47713/7095556 (0.67%)
STP-CAT6, 0.0-120.0 sec, 9.62 GBytes, 689 Mbits/sec, 0.015 ms, 26399/7052134 (0.37%)
CAT5e, 0.0-120.0 sec, 9.57 GBytes, 685 Mbits/sec, 0.180 ms, 108956/7100704 (1.5%)
So there we have it. From a simple bandwidth perspective the long CAT5e run offers basically the same performance as the STP-CAT6 run, however when it comes to jitter, the CAT6 cable is marginally worse than the ideal case, while the CAT5e run is an order of magnitude worse.
Very interesting! In the end I’m sure it’s the shielding rather than the CAT6 rating that makes the STP-CAT6 superior.