1 |
*> **http://blog.edseek.com/~jasonb/articles/traffic_shaping/scenarios.html |
2 |
|
3 |
> At the time of writing, the link appears to be down but you should able |
4 |
to access it via Google's cache.* |
5 |
|
6 |
|
7 |
The site is also available here... |
8 |
|
9 |
http://web.archive.org/web/20100727135916/http://blog.edseek.com/~jasonb/articles/traffic_shaping/scenarios.html |
10 |
|
11 |
|
12 |
|
13 |
|
14 |
On Mon, Jan 16, 2012 at 1:10 PM, Kerin Millar <kerframil@×××××.com> wrote: |
15 |
|
16 |
> On 01/07/2011 01:58, Pandu Poluan wrote: |
17 |
> |
18 |
>> Another factor that made me re-think my setup is the 'strange' |
19 |
>> characteristics of traffic between my office and our |
20 |
>> brand-spankin'-new subsidiary office 14 floors below us: SSH is very |
21 |
>> nice, but any big file transfers (sftp, http, ftp, cifs,*anything* |
22 |
>> biggish) will run well only for the first 10 seconds or so, before |
23 |
>> slowing to a crawl (and even managed to make WinSCP complaining of 'no |
24 |
>> response for 15 seconds'). But the ping's have no dropped packets at |
25 |
>> all. |
26 |
>> |
27 |
> |
28 |
> With respect to this particular syndrome, I have found the approach |
29 |
> described here to be extraordinarily effective:- |
30 |
> |
31 |
> http://blog.edseek.com/~**jasonb/articles/traffic_**shaping/scenarios.html<http://blog.edseek.com/%7Ejasonb/articles/traffic_shaping/scenarios.html> |
32 |
> |
33 |
> At the time of writing, the link appears to be down but you should able to |
34 |
> access it via Google's cache. |
35 |
> |
36 |
> Also, check out the tosfix() function in FireHOL, which demonstrates the |
37 |
> above implementation (and happens to be the best iptables wrapper, imho). |
38 |
> There's an ebuild in portage but I would advise that you supplement it by |
39 |
> grabbing the latest instance of the "firehol.sh" script from upstream CVS. |
40 |
> |
41 |
> Cheers, |
42 |
> |
43 |
> --Kerin |
44 |
> |
45 |
> |
46 |
> |