Marco Gaiarin wrote:
My new setup are in test by some hours; really i've not tested ad all,
but users does not complain. ;)
I think i've found the first trouble: long download stalls.
If i start a long download (eg, a debian iso), and then i start some
intensive and more priorized traffic (eg, a ssh transfer inside an
openvpn tunnel), all works well, eg i can see the iso download go full
speed, then if i start ssh transfer go down and then stabilize at
predefined rate.
But after some time the download stalls.
I feel that htb on ifb correctly drop packets (http is on class 30):
<snip can't see anything wrong, but may have missed something>
but this probably ''confuse'' the real interface, and connection stalls.
It shouldn't confuse anything, dropping tcp is OK as long as it's to
indicate congestion and the buffer is sized OK.
Of course if possible you only want to drop bulk packets from the actual
connection that is using the bandwidth.
I've noted this yesterday, trying to upgrade a windows box that, with
windows update, need a 130MB of nvidia driver, and stalls.
I've tried with iso images now.
Someone have some hints?
Not sure really - need more info on the rest of the setup like what
qdiscs/queue lengths (if any) you set on the leafs. The nature and speed
of the wan.
I assume this is shaping incoming from ISP - which is not the same as
shaping outgoing traffic. If you line is 3mbit then for ingress you have
to set a rate lower than that or you won't shape anything at all and
choosing how much bandwidth you need to sacrifice to shape is tricky.
The harder you hit the line the more you'll need to back off.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
