Network latency

Hi Guys,

I got a small challenge. A customer has 2 Network management nodes, which approximately 300 miles apart. Node A is a master node with DB and Node B is remote client.

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...

Any sensible advice???? So far I have refused as I don't belive this is just a latency issue...

Bandwidth isn't really an issue as this system works fine elsewhere with 2 routers and a 512K link...

Am i right to assume this is possibly a combination of Hardware, Windows 2K server (sorry!), and Network manager software?

Thanks

R

I think that in order to crack this, you may need to capture the transmitted packets using Ethereal or something similar during the update. Unless of course the updates just happen to concide with particularly bad periods of network congestion. I would however lean towards your hunch, and in that case a packet capture session should shed some more light on the situation.

I would however lean towards your hunch, and in that case a packet capture session should shed some more light on the situation.

Would you care to explain what type/kind of data a packet capture would provide to reduce the updates from 17?

I think what Dalight is getting at is that a packet capture trace of the transfer in progress would reveal if you were getting retransmissions, dropped packets, packets that one side of the connection didn't bother to respond to because it ewas overloaded etc. You can also see how the window sizes are holding up and assess how efficiently TCP is handling the connection. You might need to repeat the exercise sampling at several points within the path however to finally track down the device/system that is the cause of the problems

I think what Dalight is getting at is that a packet capture trace of the transfer in progress would reveal if you were getting retransmissions, dropped packets, packets that one side of the connection didn't bother to respond to because it ewas overloaded etc. You can also see how the window sizes are holding up and assess how efficiently TCP is handling the connection. You might need to repeat the exercise sampling at several points within the path however to finally track down the device/system that is the cause of the problems

In addition, I would suggest looking to your hardware. Are there software version differences, do you have port speed settings on auto-negotiate, tied down or mixed etc. Just a thought!

I think what Dalight is getting at is that a packet capture trace of the transfer in progress would reveal if you were getting retransmissions, dropped packets, packets that one side of the connection didn't bother to respond to because it ewas overloaded etc.

If the above statment is True, and dropped packets and re-transmissions are happening on a consistent basis, how would capturing either TCP Segments and IP Packets would help the OP reduce the updates time from 17?

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?