DSM-G600, DNS-3xx and NSA-220 Hack Forum

I can't shed any light on the original issue, but I would like to mention one thing about ping and it's usage.

Ping should really be used only to test for connectivity - trying to use it to check for latency, lag, etc., can give very misleading results.

A couple of examples - if you ping a Cisco device, the first ping request will almost always be dropped, this is caused by the software that responds to the request having to start, the remaining requests will not time out - this does not mean there is a problem with the device, or the network, it's just a peculiarity of how Cisco devices work - I start with this example for a reason that I will now explain - Cisco, obviously, does not place a high priority on the device being ready to respond to a ping request, the priority is given to the device's normal functions - switching, routing, etc.

Next example - I'm sitting at my desk, with four command windows open on a Windows XP desktop, and I'm continuously pinging four devices on my network - two network switches, a router and a Windows server.  The router consistently reports <1mS response times, the server also reports <1mS response times with an occasional spike to 15 mS, and the switches report response times of 1mS occasionally jumping to 2mS, 8mS, 15mS - with no apparent correlation between the spikes on any one device.

Given the fact that the ping request has to travel through one switch to get to the router and through both switches to get to the server - it should be impossible for the router and/or the server to be able to respond faster than the switch linking them - but this is not an anomaly, this is repeatable - you can do your own tests if your network hardware is manageable.  What I believe causes this discrepancy is the different devices dealing with their different process in the order of priority they were programmed to - routers route, switches switch, and when they have a few processor cycles to spare they will respond to a ping request - it certainly doesn't take a full millisecond for the request to transit the 20 odd feet of CAT5e cable between the desktop and the first switch, the remainder of the equipment is no more than 2~3 feet (cable-wise) beyond the first switch, and perhaps 10 feet for the server - with the exception of the desktop, we're talking patch cords.

I'm not saying completely ignore the ping response times, just don't put too much emphasis on them - if you know what to expect, they can be very good sources of information.  When my internet connection seems slow, I do a traceroute (which uses ping) to a common internet site (such as Yahoo) and look at the times - when I see the second & third hops in the 2 second region, I know that's one of my kids maxing out the DSL circuit, if the second & third hop are low and the fourth & fifth high, that's caused by congestion at the ISP, if the first half dozen are low and the remainder up over 600 mS that's a failed submarine fibre and we're on a redundant satellite feed.

1mS occasionally spiking to 15mS - as you say - is nothing to worry about and I don't think your problem is one of network connectivity

Don't use wireless .a or .g for streaming. use wired ethernet or .n

oxygen wrote:

Don't use wireless .a or .g for streaming. use wired ethernet or .n

Personally I have not been impressed with the performance of the current crop of "draft-n" product - it does deliver better performance than g and greater range than a, but nowhere near the promise of 300 mbps - in fact I have been hard pressed to achieve a consistent 40 mbps connection - I'm talking about actual throughput here, not the reported connection speed.  By comparison - g will deliver 20 mbps.

If you're looking for reliable consistent connectivity - ethernet is the only way to achieve it.