On 09/02/2013 03:07:17 PM, Sebastian Kemper wrote: > I want video streams (http streams, e.g. newscasts and trailers) to > load > quickly and play smoothly, even when there's loads of bulk traffic, > e.g. > multiple ftp transfers. >
> Let's say I have multiple ftp downloads ongoing at full speed and > then > I want > to watch an HD trailer. I would expect that the ftp traffic ends up > in > the > "bulk" bucket. http gets put into the "default" bucket, which has a > higher > priority. Then the queuing discipline starts dropping ftp packets and > the ftp > server slows down. The http stream gets the attention I want it to > get. > > Unfortunately I doesn't yet work like that. The initial buffering of > the http > stream takes ages. And once it starts up it's prone to pause again > and > buffer > some more. Currently the only way for me to enjoy a stream is to dial > down the > bulk transfers manually. > > Has anybody an idea what's wrong? Queing input traffic is hard, since it's already got to you through the bottleneck of your Internet link. TCP has to "ramp up", starting slow and getting faster as more acks show successful receipt. If your link to the net is clogged http packets will rarely get through which slows up the "slow start" tcp model. The solution is to throttle your bandwidth _below_ that of your actual bandwidth. This allows "extra" "default" packets down the pipe to be accepted while "bulk" packets are dropped, making the bulk streams slow down and allow room in the pipe for "default" packets. At least 2 things complicate this. You're working in MSS packet size units, so depending on the speed of your link there's definite "steps" in just how much reserve bandwidth you want to leave in your pipe to the net. Worse, network equipment has big buffers. This is bad because it introduces extra latency into the process that slows down the "bulk" tcp connections. (You can probably find a good series of blog posts about this via the wikipedia article on bufferbloat.) You're probably seeing pauses after startup because your endpoint is buffering the video stream. The buffer fills, there's no more acks, the remote end slows down, but then the buffer empties and needs refilling and your pipe to the net is once again clogged with "bulk" traffic. You might be able to help this by shrinking the video buffer at your end. Meanwhile, you may have an asymmetric connection to the net. With weeny outbound bandwidth a single "full" IP packet (or series of same) can hold up "empty" outbound ACK packets -- ACK packets that signal successful reception of inbound "default" data. Thus, limited outbound bandwidth throttles inbound bandwidth and interferes with fast tcp ramp-up. The solution here is to give empty ack packets highest priority (which won't interrupt a MSS sized outbound packet that's in-transit over your outbound link, but at least reduces ack latency). The good news is you don't really need low-latency, as you might if you were doing voip or something like that. So bufferbloat is going to be less of an issue than it could be. Regards, Karl <[email protected]> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein _______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
