We help IT Professionals succeed at work.

Why is it when doing a speed test (or when everyone total maxes the upload of a connection), my ping response shoots through the roof?

This may be a very easy question to explain or answer but why is it when my internet connection cable or dsl is being taxed on the upload, which is easily noticeable during a speed test, the ping response sky rockets and everyone on the network suffers while trying to surf the web?
Comment
Watch Question

Top Expert 2012

Commented:
You're using up all the bandwidth and the response time is slow.

Picture it like a running tap.  If the water is running out of the tap with nothing in the way it goes fast and the stream is very thick.  If you divert this water into different cups then the remaining water stream isn't as fast and the stream is smaller (less available to use).

Hope that makes sense.
i like the analogy to running a tap.  i like the car trip analogy better:

think of this.  you have to go to the grocery store and back.  now, this is a 24-hours store to you can go whenever.

you could go at 1am - this way there is no traffic.  you get there and back super quick because no one is on the roads - all the lights are green.

or you could go at 5pm - rush hour!  everyone is on the road, you have to wait at stop lights!  round trip time is much higher.

same thing is happening with your ping response time.  too many cars on the road!  things are getting backed up at routers (traffic lights)

Commented:
if you feel the need, you can solve this with using a good traffic shaper / QoS in your routing device, e.g. any m0n0wall device.

Author

Commented:
I'm using PFSense. Can someone give me a bit of a spoon fed help on this? I'm also using dual WAN at one of the locations I'm using PFSense. DSL and Cable.

Commented:
What happens is there is more data attempting to be transferred than the link can carry.

When a network connection is congested, some packets can be sent at any particular moment, and some packets cannot.

What happens is one of two things:

(1)  Packets that cannot be sent yet are "buffered" or  wait for their turn to be sent out the congested link;   the bigger  the buffer space configured for the links,  the greater the "queue depth"  (number of packets waiting in line)  is allowed to be,  BUT the longer the wait time.

If the wait time is long enough, the sender will not receive an acknowledgement, and may attempt to re-send the packet that is actually just waiting in line,  because they will believe the packet got lost/discarded.

The wait time increase due to buffering increases the latency and reduces the response/performance for every packet that has to wait;  normally there is no 'preference' there, so all packets with similar size have a similar chance of being impacted, and all network activities  are effected by congestion.


(2) Packets that cannot be sent yet are dropped, if they cannot be buffered; beyond a few milliseconds, this is the preferred response.... e.g. too many packets waiting in line, exceeds the buffer space  --  if using TCP, the sender will detect the problem and send/re-send new packets.


It is possible to manage congestion by ensuring that end-to-end the buffers are appropriately small,  and  that you implement prioritization of highly latency-sensitive
traffic using  traffic classification and QoS priority queuing.

However, this only  really works if the traffic you need to prioritize, comfortably
fits within the available link capacity, with sufficient extra headroom for TCP.
I found an article on traffic shaping for your device.  You want to limit the amount of bandwidth any one connection can use.  In Cisco firewall speak you create a policy to limit available bandwidth.

http://doc.pfsense.org/index.php/Traffic_Shaping_Guide

Explore More ContentExplore courses, solutions, and other research materials related to this topic.