| 1 |
Am Wed, 21 Sep 2016 22:06:37 +0200 |
| 2 |
schrieb Kai Krakow <hurikhan77@×××××.com>: |
| 3 |
|
| 4 |
> Am Wed, 21 Sep 2016 12:37:51 -0700 |
| 5 |
> schrieb Grant <emailgrant@×××××.com>: |
| 6 |
> |
| 7 |
> > [...] |
| 8 |
> > [...] |
| 9 |
> [...] |
| 10 |
> > > |
| 11 |
> > > You may want to set the default congestion control to fq-codel |
| 12 |
> > > (it's in the kernel) if you're using DSL links. This may help your |
| 13 |
> > > problem a little bit. It is most effective if you deploy traffic |
| 14 |
> > > shaping at the same time. There was once something like |
| 15 |
> > > wondershaper. Trick is to get the TCP queuing back inside your |
| 16 |
> > > router (that is where you deployed pppoe) as otherwise packets |
| 17 |
> > > will queue up in the modem (dsl modems use huge queues by |
| 18 |
> > > default). This works by lowering the uplink bandwith to 80-90% of |
| 19 |
> > > measured maximum upload (the excess bandwidth is for short bursts |
| 20 |
> > > of traffic). Traffic shaping now re-orders the packets. It should |
| 21 |
> > > send ACK and small packets first. This should solve your queuing |
| 22 |
> > > problem. |
| 23 |
> > |
| 24 |
> > |
| 25 |
> > We're talking about optimizing the DSL connection at my office but |
| 26 |
> > the server is located in a data center. I can't imagine optimizing |
| 27 |
> > that office DSL connection is the way to solve this even though the |
| 28 |
> > http response slowdowns do correlate to office hours. As a note, |
| 29 |
> > the slowdowns are recorded by my third-party monitoring service. |
| 30 |
> |
| 31 |
> Ah I didn't correctly get this... So as the problem correlates with |
| 32 |
> office hours the first step of solving your traffic flow problems |
| 33 |
> (timeouts, drops etc) should be sufficient to further work on problems |
| 34 |
> of the other side. |
| 35 |
|
| 36 |
I'd probably try iperf at this stage to test if this problem occurs |
| 37 |
with application stacks only or also occurs using only raw tcp streams. |
| 38 |
Try upload, download, and bidirectional. Do your tests again after |
| 39 |
modifying some parameters, maybe access the http server in parallel, |
| 40 |
test at different times of day (off-hours and office hours). See if you |
| 41 |
can isolate it around specific settings or tasks. |
| 42 |
|
| 43 |
-- |
| 44 |
Regards, |
| 45 |
Kai |
| 46 |
|
| 47 |
Replies to list-only preferred. |
Archives