Sorry, I didn't mean to be antagonistic, but I guess my general advice was too vague. Let me provide a clear description of the science behind why SQM/fq_codel works so well.
But first, it would really help me if you (or the OP) reported the results from www.dslreports.com/speedtest You can see a typical result at:
http://www.dslreports.com/speedtest/1156999 (my 7mbps down/768kbps up DSL link).
1) Maybe I'm wrong, and the high ping times are not caused by bufferbloat. If your router is not bloated, then none of the information below will help you.
2) You can solve bufferbloat in your network, but it requires a router from a vendor/developer who understands the problem. To date, the Bufferbloat team has not found any of the big commercial vendors whose firmware does this. (Both Ubiquiti and ipfire.org may have a handle on it. You can check with them.) I use a TP-Link Archer C7 v2 flashed with the OpenWrt Barrier Breaker firmware. See
http://wiki.openwrt.org/toh/tp-link/tl-wdr7500 for instructions.
3) After installing OpenWrt and getting it configured, you need to setup SQM/QoS. Read the HOWTO
http://wiki.openwrt.org/doc/howto/sqm or watch the video at
https://www.youtube.com/watch?v=FvYhifdQ92Q
4) I wrote a non-technical description of bufferbloat - "Bufferbloat and the Ski Shop" Bufferbloat http://richb-hanover.com/bufferbloat-and-the-ski-shop/
5) There is a very good description of the algorithm in the IETF Draft Internet Standard, at:
https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-01#page-4
6) And finally, here is an explicit description of how fq_codel can control bufferbloat for traffic from your ISP to your home router. First, I'll describe the way fq_codel algorithm controls sending data the other way: toward the ISP.
a) Bufferbloat arises when packets get queued at the bottleneck link (most frequently, between your home router and your ISP).
b) fq_codel works by separating different flows/connections into separate queues, and measuring the *time* packets live in each of the queues. It sets a time stamp when each packet is queued, and when a packet comes out of the queue to be transmitted, it computes the time it has been in the queue (the "sojourn time").
c) The insight to the fq_codel algorithm is that, when packets have been queued for "too long" (the sojourn time is longer than the "target" - 5 msec, or the time to send one max segment size of data), it drops a fraction of those packets (or uses the more gentle ECN marking). This informs the sender whose data is backing up in the queue that it should slow down, while preserving the timely delivery of the low-traffic flows so they stay snappy.
How does this work with data sent *toward* the home from the ISP? You're right, normally, the data received from the ISP never builds up a queue. But... your example is very close to the mark.
fq_codel installs an artificial bottleneck into the download stream, typically one or two percent slower than the actual link. Because that artificial bottleneck is a bit slower than the ISP's link, a queue can build up, and fq_codel can then do the same packet sojourn time measurements. It'll drop or mark (with ECN) packets from big senders who are using more than their share of the link and latency remains low.