Network latency

i think dalight is suggesting, and as the bishop also pointed out, that packet captures be done in order to troubleshoot where and when a congestion within the network structure occurs. in this case if packets are captured during the updating and transferring process, it would show how these packets are handled while the updating/transferring process is taking place. wherin the capture would indicate behaviour by each device as the packets travel through them, in which case it would provide a better overview of how these packets react to each individual devices within the infrastructure that might show the culprit to the latency problem.

try thinking it like a water pipe with sections leading to a faucet. say you open a faucet and suddenly water flows slowly out. if you had an x-ray machine that could scan all the sections of the pipe leading to the faucet you might see a clog in one of the pipe sections, thus replacing that clogged pipe would make water flow continuously with great enhancement in speed rate.

i think dalight is suggesting, and as the bishop also pointed out, that packet captures be done in order to troubleshoot where and when a congestion within the network structure occurs. in this case if packets are captured during the updating and transferring process, it would show how these packets are handled while the updating/transferring process is taking place. wherin the capture would indicate behaviour by each device as the packets travel through them, in which case it would provide a better overview of how these packets react to each individual devices within the infrastructure that might show the culprit to the latency problem.

a]. What fields in a TCP Segment and IP Packet would tell you
where/when network congestion is occuring?

b]. What fields in a TCP Segment and IP Packet would describe the behavior of these devices?

I wasn't actually approaching the problem from a network congestion angle due to the fairly generous bandwidth provision in place. My reason for the packet capture suggestion was to see if any application level inefficiencies could be highlighted possibly due to incompatibilities between the different technologies in the transmission path.

interesting posts happening here, as one segment is trying to arrive at a solution, and others are trying only to find faults with it, but not really coming up with alternatives......*yawn*
anyway, back to the main issue. the brief network design presented here, shows routers and that too three of them. the schematic diagram given does not show how many other links or nodes these routers serve respectively. neither do we get to know the actual load borne by these routers, and how much priority data travelling between Node A and Node B are getting. same lack of info is for the switches as well. if you can provide the actual picture of the network, then a simulation can be done on it to try and find out which link or device is creating any bottlenecks.
awaiting your response

I must admit this is a very interesting thread and its certainly got my attention!

The suggestions made by our members are, in my opinion, correct and will help identify possible cause of this delay. To get to the point, here is a list of actions I'd take to help identify the problem:

1) Enhanced Ping by solarwinds (you can download the individual application here: www.firewall.cx/download-s01-mnt.php Let it run for around an hour's time during high traffic periods to see if you've got any major latency issues or packet loss.

2) Grab the event viewer log on both machines and analyse them for possible errors which may 'give-in' the problem.

3) Check each equipment that's in the packets path, including switches and the ports to which the nodes connect to. For the switches, check the interfaces to see the duplex, speed and errors they might have. For the routers, ensure you pay attention to the interfaces reliability, input/output errors and TX/RX loads during high-peak hours.

4) Introduce a neat packet sniffer on node A or B (whichever is close to you) and monitor the traffic between the two nodes. Ideally you would want to capture the traffic during an update to see what's going on. If there's a high volume of traffic, you can also use IRIS which has a great tool to view the bandwidth consumption in real-time generated graphs.

If the traffic is very low during the updates, the problem could point toward the configuration of the nodes, where updates are slowly sent to ensure network congestion is avoided; This depends on the applications and their settings - check it out.

Using the above information you should be able to see some type of pattern that would tell you where to look next. If you like, you can share this information with us and we'll do the best to assist you in resolving this problem.

As a last note, I used the above method 2 days ago at one of my customers who was experiencing network drop-outs on their WAN network links, cutting 3 remote offices every now and then. The problem was identified and I'm actually typing up the report as I 'speak'

Good luck!

interesting posts happening here, as one segment is trying to arrive at a solution, and others are trying only to find faults with it, but not really coming up with alternatives......*yawn*

If this comment is directed towards me, you are dead wrong my friend. If someone comes up with a solution, and is not clear how the solution would help solve the issue, any person with a common sense would question the solution so that everyone could learn from it.

My intentions are to challenge the responses and NOT the People and see if the people that came up with solutions could expand it a little further. I'm sure your little *Mind* can NOT process it.

And if the above comment is NOT directed at me, I sincerely apologize.

Remember always ask *Why?*.