There is a remote site that earlier connected to a central site through a 128 Kbps leased line connection. The ping response times to the central site was constantly between 22 - 24 ms. Due to congestion on the WAN link, the remote site upgraded its bandwidth to 256K. However, the ping response is still 22-24 ms and there is no reduction in latency. The router has been configured for 256K and the NOC also has confirmed that the line rate has been configured to 256K.
My first question is that does bandwidth upgradation lead to better ping response times? And the next and last question is that how does one verify if they are receiving 256 K of bandwidth?
Not usually. You may have doubled your clock speed (or, more likely, gotten four shares of a T1 instead of two shares), but your ping times are dominated by the distance rather than by the speed you are transmitting the bits.
There are cases where upgrading would result in better ping times -- e.g., if the speed of the carrier wave through the medium is noticably faster for a far enough distance, or if intermediate equipment with a high latency got replaced, or if you manage to get a noticably shorter route. But distance is distance, and if you figure out the actual time spent sending bits for the two ping cases, you will find it to be trivial compared to the ping times you are seeing.
As Walter said in a previous post .. "your ping times are dominated by the distance". Data transmission occurs at the speed of light ... a constant. The general rule of thumb is to allow 10 micro seconds per mile. Propagation delay, processing delay and serialisation delay are all incurred along the way. As pings are typically small packets any benefits the bandwidth increase has given can be hard to spot.
You can do a 'show controllers ' to see what the actual clock rate is.
I could not point out anything from the clock speed but I have given below the output of show controllers command. Please help me to find out the bandwidth received:
QUICC Serial unit 0 idb at 0x252FF20, driver data structure at 0x2531784 SCC Registers: General [GSMR]=0x2:0x00000030, Protocol-specific [PSMR]=0x0 Events [SCCE]=0x0000, Mask [SCCM]=0x001F, Status [SCCS]=0x0006 Transmit on Demand [TODR]=0x0, Data Sync [DSR]=0x7E7E Interrupt Registers: Config [CICR]=0x00368461, Pending [CIPR]=0x0000C202 Mask [CIMR]=0x50000850, In-srv [CISR]=0x00000000 Command register [CR]=0x680 Port A [PADIR]=0x00C4, [PAPAR]=0x3DF3 [PAODR]=0x0040, [PADAT]=0xC1FA Port B [PBDIR]=0x00F13F, [PBPAR]=0x0010CE [PBODR]=0x000000, [PBDAT]=0x024ADC Port C [PCDIR]=0x0084, [PCPAR]=0x0800 [PCSO]=0x0230, [PCDAT]=0x040B, [PCINT]=0x0000 DTE V.35 serial cable attached.
SCC GENERAL PARAMETER RAM (at 0xFF00E00) Rx BD Base [RBASE]=0x500, Fn Code [RFCR]=0x18 Tx BD Base [TBASE]=0x540, Fn Code [TFCR]=0x18 Max Rx Buff Len [MRBLR]=1528 Rx State [RSTATE]=0x18C48240, BD Ptr [RBPTR]=0x510
Tx State [TSTATE]=0x18000348, BD Ptr [TBPTR]=0x548
Ping response is the sum of four independent delays:
1 - Propagation delay (speed of light and switching/routing inside the cloud) assume a minimum of 6ms/1000km (10msec/1000 miles).
2 - Processing delay (how long from the time a request is received until the response is ready to be sent).
3 - Serialization delay (how long it takes to send the bits in the frame at the data rate of the link).
4 - Queueing delay (how long a packet must wait in line for packets in front of it in the buffers).
Generally speaking, #1 and #2 are independent of packet size and link speed, and #4 only makes a difference when there is significant load. So changing the link speed will only change delay #3 in the absence of competing traffic. So to determine your link speed using ping, do a bunch of pings with short packets and with long packets (as long as they are short enough not to be fragmented). If all the short packets have about the same response time and all the long packets have about the same (albeit longer than for the short packets) response time, then you don't have significant queueing times, and the data rate of the link is simply twice the difference in packet length (in bits) divided by the difference in response time (in seconds).
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.