| 1 |
Am Wed, 21 Sep 2016 12:53:17 -0700 |
| 2 |
schrieb Grant <emailgrant@×××××.com>: |
| 3 |
|
| 4 |
> [...] |
| 5 |
> [...] |
| 6 |
> >> |
| 7 |
> >> You may want to set the default congestion control to fq-codel |
| 8 |
> >> (it's in the kernel) if you're using DSL links. This may help your |
| 9 |
> >> problem a little bit. It is most effective if you deploy traffic |
| 10 |
> >> shaping at the same time. There was once something like |
| 11 |
> >> wondershaper. Trick is to get the TCP queuing back inside your |
| 12 |
> >> router (that is where you deployed pppoe) as otherwise packets |
| 13 |
> >> will queue up in the modem (dsl modems use huge queues by |
| 14 |
> >> default). This works by lowering the uplink bandwith to 80-90% of |
| 15 |
> >> measured maximum upload (the excess bandwidth is for short bursts |
| 16 |
> >> of traffic). Traffic shaping now re-orders the packets. It should |
| 17 |
> >> send ACK and small packets first. This should solve your queuing |
| 18 |
> >> problem. |
| 19 |
> >> |
| 20 |
> >> Between each step check dslreports.com for bufferbloat. I'm |
| 21 |
> >> guessing it is currently way above 1000 ms while it should stay |
| 22 |
> >> below 20-50 ms for dsl. |
| 23 |
> >> |
| 24 |
> >> The fq-codel congestion control fights against buffer bloat. But it |
| 25 |
> >> can only effectively work if you're doing traffic shaping at least |
| 26 |
> >> on your uplink (downlink may or may not be worth the effort |
| 27 |
> >> depending on your use-case). |
| 28 |
> >> |
| 29 |
> >> Additionally, you can lower the priority of icmp-echo-reply this |
| 30 |
> >> way so during icmp flooding your uplink will still work. |
| 31 |
> >> |
| 32 |
> >> This link may help you: |
| 33 |
> >> https://www.bufferbloat.net/projects/codel/wiki/Cake/ |
| 34 |
> > |
| 35 |
> > And this: |
| 36 |
> > https://github.com/tohojo/sqm-scripts |
| 37 |
> |
| 38 |
> |
| 39 |
> I haven't mentioned it yet, but several times I've seen the website |
| 40 |
> perform fine all day until I browse to it myself and then all of a |
| 41 |
> sudden it's super slow for me and my third-party monitor. WTF??? |
| 42 |
|
| 43 |
I had a similar problems once when routing through a IPsec VPN tunnnel. |
| 44 |
I needed to reduce MTU in front of the tunnel to make it work |
| 45 |
correctly. But I think your problem is different. |
| 46 |
|
| 47 |
Does the http server backlog on the other side? Do you have performance |
| 48 |
graphs for other parts of the system to see them in relation? Maybe |
| 49 |
some router on the path doesn't work as expected. |
| 50 |
|
| 51 |
-- |
| 52 |
Regards, |
| 53 |
Kai |
| 54 |
|
| 55 |
Replies to list-only preferred. |
Archives