Network latency

Hi,

Firstly thanks to all of your comments regarding this. You have pretty much confirmed mu suspicions...and given great advice as to how to resolve.

However most of your suggestions will not be practical because my customer will only allow me access to the nodes we supplied. I have to offer the rest as advice to their network 'gurus' who will either implement or ignore as they see best.

So this is the approach I have taken so far.

1) Removed all 3rd party software to leave windows on both nodes and perform large file transfers between the 2 stations.

Result: Acceptable performance.

2) Installed my companies software and repeated file transfers.

Result: as 1)

3) Install 3rd party network management suite on both nodes. and tried to perform updates...

Result: 17 minute delay in update completing.

So it appears the 3rd party stuff has a problem with the network (Application latency???)

So now I am working with 3rdparty & customer to resolve.

shame customer won't let me loose on their network

Dear undead - neuron's , and i will keep on calling you that, as you have proved that yours are not dead at all!!!
as for the your post, i would not have reacted to something like "I'm sure your little *Mind* can NOT process it", as this is not a site to vent out our personal issues (i don't think we even have any!). But since you have taken pains to pick out my post and those particular lines and directed them towards yourself, which no one else seems to have noticed at all, i guess i really do deserve an apology, as they were not directed to you. i don't know how you give your apology but i'll give you a hint, i love chocolate
jokes apart, i hope your visits to this wonderful site would be fruitful, as both parties would gain from it, you and us.
looking forward to your posts on various issues.
take care

Glad to see you've highlighted the possible cause using the good old principles of analysis and synthesis, Ranger24.

Point taken Dead-Neur0ns. I've been in and out of the forums recently due to pressure of work and haven't been following this thread as closely as perhaps I should. However I'll try to provide a little more depth around my answers

can you tell me what Field to look for and even if one finds out what the Field are, what/how would one do to reduce the updates from 17?

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

When using a packet sniffer to diagnose throughput issues it is seldom a matter of running your finger down the trace, pulling out a single packet and saying "Aha!". Often I wish it was.
What you end up doing is following the flow of the TCP exchange from packet to packet from the initial handshake and on through the trace and seeing as you go along how the various elements of the protocol are responding. For example, keeping track of the sequence numbers will show whether you have retransmissions and/or packets that never arrived at the destination. They will also reveal instances where packets turn up out of numerical order, perhaps due to changes in topology between the endpoints or multiple routes. Another indicator to watch is the TCP window size being advertised by each end of the link; sometimes you can see the available window size dropping as the machine feels the pain for whatever reason and doesn't have the resources to service the network properly. You can also look at the way the payload is being carried byt he packet stream. You'd expect to see a fair few packets with a full-sized data segment and some smaller packets here and there for acknowledgments and control. If all your packets are suspiciously small however there might be a misconfiguration in one of the protocol stacks at either end or maybe even a router in the path with a smaller MTU size causing fragmentation.
As Chris rightly said, there are a number of simpler diagnostic tests you can do before you get to this level, the intention being to isolate the problem to a particular device in the chain. In my experience nine out of ten throughput problems can be solved in this way. But there's always that tenth one where you draw a blank and have to figure it out from the traces.
Hope that helps, and if anyone else has more to add or points they wish to correct me on, please feel free.

I'm still no CCNA yet but I've been around a bit and reading through this thread, it seems to be geting way more complex a fix than it surely ought to be. Here's my 2p. If i'm way off base just tell me to shush and I will go whimper off into the book section for a while

Node B periodically should recieve network updates from Node A (Node states, link states, management states etc). However the update takes 17 minutes to complete via the following network:

Node A --[FastEthernet]--router --[8mb/s Link]-- router --[fastethernet]--switch--[fast ethernet]--switch---[10mb/s]--router --[10mb/s]--Node B

A ping test provides a RTT of 22 Ms.

The customer has asked for a suggestion as to the latency requirements for this 17minute download to be reduced...

Thats quite a lot of info considering he/she obviously can't go into details. With a link of this size I would say the best bet first would be to see whats happening either side of the link just to narrow down your search area. 300 miles is a lot when testing points on the network (though very good for the mileage claim I suspect).

After 15 years in IT support, man and boy, I've learnt that walking to a keyboard and typing ping/tracert is one of the biggest red herring generators going when it comes to any fault analysis. Typically resulting in "Well it looks fine to me!".

Although you gave a 22 ms trip, what's actually happening when the data is being sent in each section of that long journey. Have you tried a "right send it now" on the phone while your ready to monitor at each side of that link. That will narrow down your search a lot.

If its leaving Node A's router ok then see whats happening across those switches on the B side. Also, what's going on on Node B when that lot arrives. Is it ready to handle it or is it busy with whatever the rest of Node B is upto normally. What time of day is this all hapening at. Have these in house 'gurus' set it to go off at lunch time when Node A/B staff are busy downloadin .. erm.. <cough> studying the finer intracasies of their internet browser for later official use.

Also, have you calculated how long theoreticaly the size of the transmit over a 22 ms link should take in minutes if it were travelling at 22ms? Could it be a great link but with waaay to much data being sent?

Just some ideas on narrowing down your search area... Tell me to shush if i'm statin the bleedin obvious

Star.

Point taken Dead-Neur0ns. I've been in and out of the forums recently due to pressure of work and haven't been following this thread as closely as perhaps I should. However I'll try to provide a little more depth around my answers

For example, keeping track of the sequence numbers will show whether you have retransmissions and/or packets that never arrived at the destination.

Explain how keeping track of the Sequence Numbers will help reduce the issue at hand?

They will also reveal instances where packets turn up out of numerical order, perhaps due to changes in topology between the endpoints or multiple routes.

Explain how if the packets are out of numerical order will help the issue at hand?

Another indicator to watch is the TCP window size being advertised by each end of the link; sometimes you can see the available window size dropping as the machine feels the pain for whatever reason and doesn't have the resources to service the network properly.

How can one control to have a consistent Window Size? Explain what you meant by *the machine feels the pain*?

If all your packets are suspiciously small however there might be a misconfiguration in one of the protocol stacks at either end or maybe even a router in the path with a smaller MTU size causing fragmentation.

.

If all the packets are small as you have mentioned, how would one determine what Protocol have been misconfigured?