Yep, with TCP, you'll be fine as any lost packets are retransmitted, but with UDP, anything lost is lost forever. Great for surfing, but I wouldn't want to play a game across it. DNS is usually setup for UDP as well, so you could see some delays from packets getting dropped from DNS quires.
If you can trace the wire from end to end, I would just go along it and see if it gets close to anything electrical. Put tinfoil around that area for a foot or two and move on. The randomness makes perfect sense for RF noise. If it was a bad connector or a wire that was stretched/borken, then it would be consistent. ---- Julian On Tue, Aug 2, 2011 at 9:17 AM, Anthony Q. Martin <[email protected]>wrote: > Thanks for some feedback, Julian. I'm going to be testing with various > fixes to suppress the radiated RF coupling (including tin foil over the > connectors and shield cabling inside). It will be fun to see what actually > works, but I kinda wish I had bought the STP in the first place. The thing > is, since apparently packets are checked, I can still get decent enough > performance a lot of the time, but not 100% of the time. And the randomness > is irritating. > > > On 8/2/2011 8:40 AM, Julian Zottl wrote: > >> Tinfoil works well :) If not that, some conduit will do too. If it's >> running on the outside of your house, I would put it in conduit anyway. >> ---- >> Julian >> >> >> On Tue, Aug 2, 2011 at 8:03 AM, Anthony Q. Martin<[email protected]>** >> wrote: >> >> Oops....did it over with the bandwidth value set higher (50m). Got this: >>> >>> [3] Server Report: >>> [ 3] 0.0-10.0 sec 53.1 MBytes 44.6 Mbits/sec 0.522 ms 3813/ >>> 41719 >>> (9.1%)<======= >>> >>> did it again with the same 50m but this time using a different PC on my >>> network. Got this: >>> >>> [3] Server Report: >>> [ 3] 0.0-10.0 sec 58.7 MBytes 49.2 Mbits/sec 0.694 ms 25/41892 >>> (0.06%) >>> >>> As can be seen, the second one is way under 1% (see below) while the >>> first >>> is way over 1%. I'm losing lots of packets probably due to lack of >>> shielding. Crap! >>> >>> The cabling under the house is probably too close to something that is >>> spewing RF. I wonder if I can make some shielding to improve this? >>> >>> >>> On 8/1/2011 12:59 PM, Thane Sherrington wrote: >>> >>> At 01:53 PM 01/08/2011, Anthony Q. Martin wrote: >>>> >>>> What do you mean? they are the points where inference gets in? >>>>> >>>>> That's where I run into connection issues. Other than the occasional >>>> problem where I go in to a spot where some idiot ran the cable and >>>> either >>>> ran it alongside power cables stretched it, most of the connection >>>> failures >>>> are at the ends. I think you can use iPerf to test data loss on >>>> Ethernet. >>>> Or get one of those high end cable testers from Fluke. >>>> >>>> >>>> Following this site: >>> >>> http://openmaniak.com/iperf.****php <http://openmaniak.com/iperf.**php>< >>> http://openmaniak.com/**iperf.php <http://openmaniak.com/iperf.php>> >>> >>> >>> They say this: >>> >>> "The UDP tests with the -u argument will give invaluable information >>> about >>> the jitter and the packet loss. If you don't specify the -u argument, >>> Iperf >>> uses TCP. To keep a good link quality, the packet loss should not go >>> over 1 >>> %. A high packet loss rate will generate a lot of TCP segment >>> retransmissions which will affect the bandwidth." >>> >>> In their example, they get this: >>> >>> ------------------------------****----------------------------**-- >>> Client connecting to 10.1.1.1, UDP port 5001 >>> Sending 1470 byte datagrams >>> UDP buffer size: 108 KByte (default) >>> ------------------------------****----------------------------**-- >>> [ 3] local 10.6.2.5 port 32781 connected with 10.1.1.1 port 5001 >>> [ 3] 0.0-10.0 sec 11.8 MBytes 9.89 Mbits/sec >>> [ 3] Sent 8409 datagrams >>> [ 3] Server Report: >>> [ 3] 0.0-10.0 sec 11.8 MBytes 9.86 Mbits/sec 2.617 ms 9/ 8409 >>> (0.11%) >>> >>> That last part is the # of packets that were lost and had to be re-sent. >>> They got 0.11% and 1% is the upper limit on a quality link. When I run >>> this test I get this: >>> >>> 3] Server Report: >>> [ 3] 0.0-10.0 sec 11.9 MBytes 10.0 Mbits/sec 1.711 ms 2/ 8505 >>> (0.024%) >>> >>> So, perhaps this is time dependent and/or condition dependent...or I'm >>> just >>> barking up entirely the wrong tree. >>> >>> >>>
