Exactly my thoughts on how to proceed. Just got back from under the
house...I did reposition the cabling to that it runs perpendicular to
the other cables, as it look as if there is a big one running to the
furnace under the crawl space.
I assume TCP is used for the home network, right? I'm not really into
gaming and certainly won't do any on this HTPC..that will be done
upstairs, exclusively.
I have noticed in other situations that my computing room is really
noisy...I'm going to all shielded cabling to/from the router...then I'm
going to wrap the keystone wall mounts that I've used...and then if none
of that works, I'm going to wrap the cable under the house in foil tape.
A little bit at a time, though. If need be, I'll wrap it all, piece by
piece til I get it right.
On 8/2/2011 9:55 AM, Julian Zottl wrote:
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.
