| 1 |
Hi, |
| 2 |
|
| 3 |
On Mon, 16 Apr 2007 09:00:04 -0700 |
| 4 |
Grant <emailgrant@×××××.com> wrote: |
| 5 |
|
| 6 |
> > > After a lot of testing, these numbers seem to give me the best |
| 7 |
> > > performance as far as bittorrent download speed. |
| 8 |
> > > How can that be? Is DOWNLINK my upload and UPLINK my download? |
| 9 |
> > |
| 10 |
> > Hm, usually not. Are you by chance shaping the internal (i.e. LAN) |
| 11 |
> > interface on a router? Then, of course, it would make sense (except |
| 12 |
> > from the fact that shaping your actual bottle neck, i.e. Internet |
| 13 |
> > connection, would make more sense). |
| 14 |
> |
| 15 |
> Thanks a lot for that. I switched the interface to eth0 and reversed |
| 16 |
> the DOWNLINK and UPLINK values. |
| 17 |
|
| 18 |
:-) |
| 19 |
|
| 20 |
> I switched to wshaper from wshaper.htb and now ssh and browsing seem a |
| 21 |
> lot more responsive. Could that be because I'm missing something in |
| 22 |
> my kernel that I need for htb? I don't get any errors when restarting |
| 23 |
> the firewall. |
| 24 |
|
| 25 |
I'm not sure about that. I did only try wshaper.htb and didn't manage |
| 26 |
to fit it to my needs completely either (see below). The kernel |
| 27 |
configuration help tells a good bunch of info, IIRC. |
| 28 |
|
| 29 |
> One other thing is if I don't limit the upload rate within my |
| 30 |
> bittorrent client, it really goes nuts and everything else suffers. I |
| 31 |
> don't see how that's possible with UPLINK and the bittorrent source |
| 32 |
> and destination ports defined. |
| 33 |
|
| 34 |
Well, the problem is that limiting inbound traffic is absolutely |
| 35 |
unreliable. From the numbers given, I guess you're on DSL, right? (Just |
| 36 |
like me, BTW.) If you were on cable, well, there's not a lot you can do |
| 37 |
since the media is unreliable w/ regard to your share of it. But I |
| 38 |
think you're talking about stable bandwith. If you're not lucky, all |
| 39 |
those peers out there flood your inbound traffic line. You can't shape |
| 40 |
this on your side, it's absolutely an issue to be resolved on the DSLAM |
| 41 |
your DSL modem connects to. OTOH, those routers usually don't do very |
| 42 |
sophisticated packet inspection... So it's all about cutting expensive |
| 43 |
connections down very early. This is the even more true for |
| 44 |
applications that are somewhat hasty in changing their requested and |
| 45 |
incoming traffic. So first try cutting down the maximum even more. Take |
| 46 |
a few measures and see what is actually saturated: upstream or |
| 47 |
downstream. If it's in fact neither, it's a configuration issue. |
| 48 |
|
| 49 |
> What I'd really like to do is limit the bittorrent upload rate so |
| 50 |
> Verizon doesn't throttle my connection. Can I do that with The Wonder |
| 51 |
> Shaper without limiting the total upload rate? I don't trust the |
| 52 |
> bittorrent clients I use to limit it. |
| 53 |
|
| 54 |
Did you consider trickle? It's lightweight and easy and works on |
| 55 |
application layer (i.e. usermode) by overloading glibc functions... If |
| 56 |
you're not trying to manage a whole set of clients behind a router, |
| 57 |
that would be an option. |
| 58 |
|
| 59 |
And to be honest: I've dumped QoS on my linux-based router. I've never |
| 60 |
managed to fully saturize my link the way I wanted it using it. I'm not |
| 61 |
completely sure if I should blame it on the 125MHz the poor CPU's |
| 62 |
running at (it's a WiFi AP, the Linksys WAP54g) or the 8MB of RAM... |
| 63 |
|
| 64 |
-hwh |
| 65 |
-- |
| 66 |
gentoo-user@g.o mailing list |
Archives