Ping response times - same after upgrade of bandwidth

Hi friends,

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?

Thanks a lot Gautam

Reply to
gautamzone
Loading thread data ...

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.

Reply to
Walter Roberson

Hi Walter,

Thanks a lot for the information given and it really helped.

Reply to
gautamzone

Hi Walter,

Thanks a lot for the information given and it really helped.

Reply to
gautamzone

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.

BernieM

Reply to
BernieM

Thanks a lot for the info Bernie.

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

SCC HDLC PARAMETER RAM (at 0xFF00E38) CRC Preset [C_PRES]=0xFFFF, Mask [C_MASK]=0xF0B8 Errors: CRC [CRCEC]=13, Aborts [ABTSC]=5, Discards [DISFC]=0 Nonmatch Addr Cntr [NMARC]=0 Retry Count [RETRC]=0 Max Frame Length [MFLR]=1526 Rx Int Threshold [RFTHR]=0, Frame Cnt [RFCNT]=62772 User-defined Address 0000/0000/0000/0000 User-defined Address Mask 0x0000

buffer size 1524 BRGC1=101B0, BRGC2=0, BRGC3=0, BRGC4=0 modem_signal_addr FF01566 MASK: DSR=40, DTR=80,RTS=4.CTS=100,DCD=200 txbrgc=FF015F8, rxbrgc=FF015F8 BRG [DTE]: rx_sicr_clk=5, tx_sicr_clk=4 BRG [DCE]: rx_sicr_clk=5, tx_sicr_clk=2 CLK SRC: sync=4000, async=4000 RX ring with 8 entries at 0xFF00500, Buffer size 1524 Rxhead = 0xFF00518 (3), Rxp = 0x25317AC (3)

00 pak=0x2536EFC buf=0x27A4620 status=9000 pak_size=0 01 pak=0x25362E4 buf=0x27A1DB8 status=9000 pak_size=0 02 pak=0x2537910 buf=0x27A67CC status=9000 pak_size=0 03 pak=0x2537304 buf=0x27A5398 status=9000 pak_size=0 04 pak=0x2535CD8 buf=0x27A0984 status=9000 pak_size=0 05 pak=0x2536CF8 buf=0x27A3F64 status=9000 pak_size=0 06 pak=0x2535AD4 buf=0x27A02C8 status=9000 pak_size=0 07 pak=0x2535EDC buf=0x27A1040 status=B000 pak_size=0 TX ring with 2 entries at 0xFF00540, tx_count = 0 tx_head = 0xFF00540 (0), head_txp = 0x25317FC (0) tx_tail = 0xFF00540 (0), tail_txp = 0x25317FC (0) 00 pak=0x0000000 buf=0x0000000 status=0000 pak_size=0 01 pak=0x0000000 buf=0x0000000 status=2000 pak_size=0 QUICC SCC specific errors: 187799 input aborts on receiving flag sequence 1 throttles, 1 enables 45 overruns 880 transmitter underruns 0 transmitter CTS losts

Thanks a lot Gautam

BernieM wrote:

Reply to
gautamzone

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

Good luck and have fun!

Reply to
Vincent C Jones

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.