From the data provided by Tom, Dick and my own logging, the point in the network where routes converge en route to the forum server, is at the IP 69.139.168.142 which is a Comcast router located in Pennsylvania in the vicinity of Lancaster.
I log the network activity hourly on the hour. When the response is good the RRT (round trip time - pc-server-pc) is 130 milliseconds. this will vary from user to user, for Tom in Massachusetts 55ms, Dick in Texas 80 ms. When the response is slow the RRT time will increase. If at a point on the network there is severe congestion then the pathping utility will terminate prematurely, as happened to Dick.
The final output from pathping is obtained by sending packets specifically to the individual nodes progressively along the route - so you may find the time at say node 12 is smaller than node 10. In Dick's second trace the utility timed out attempting to send and receive packets from node 25 (IP 96.110.32.132). This is a Comcast route in Georgia and because it is also a node on Tom's route I infer this may be a significant hub in the Comcast network. The timeout may have occurred due to congestion at any point on the network to node 25, but it was most likely due to congestion on the line between nodes 24 and 25 or the router at 25 being overloaded.
In post #76 Jerry indicated that he was suffering problems 20:20 GMT. I have a log of pathping that finished at 20:10 ...
As can be seen the RRT has increased from 130ms to 181ms and the trace is showing lost packets in the critical part of the network which from the evidence we have, is common to all users trying to access the server from off-site locations. The information shown for node 17 records an RTT of 182ms then 4/100 = 4% which indicates that 4% of the data packets sent directly to this node were lost. The value "0/100 = 0%" shows that no packets that passed through the hop were discarded. The line below indicates that on the path to the next hop (IP address: mb.nawcc.org), 6% of the data packets were discarded. Of the packets sent to the server (node 18) 10% were lost - 100 packets were set and only 90 arrived and were acknowledged, hence 10 had to be resent - this results in an 11% increase in network traffic to serve any request to the server. The data for nodes 13,15, and 16 show that these routers discarded 2%, 3% and 1%, respectively of the packets that should have been forwarded to the following notes in the network
We are looking into this. Unfortunately, there is not a simple, obvious answer.
Dave I continue to be mystified why this is so difficult to analyse.
How do the staff working at headquarters access the forums? I assume their interaction can be across the LAN (the in-house network) and they do not have to use the Comcast network? If so, have they been explicitly asked to use the forum during the periods when remote response is degraded and report their experience?
and in reference to pathping ...
Someone in headquarters should use it - this will check that they are not being directed out to the Comcast network and back in again. I have known it happen!
The results from these observations and monitoring would be so helpful. If there is no degradation of service when the external network is excluded from the path, this will provide the data necessary to dispel the view that it is the server and the in-house network that are the problem. It will not of course rule out the on-site hardware that links to the Comcast network.
John
