Thanks for all your comments and efforts ! I do hope we are talking about the same thingies in here. Those who say they got it working (Volker, Primo�) don't mention the effects, unfortunately. Volker included a sequence of pfctl -vvsq proving the usage of both queues. *This* is what I experience myself with the config given earlier.! - When I download, I get about 310 kb/s - yes, with the ACKs showing nicely in q_pri, while q_def remains about 0. When I upload, I'm getting the expected 100kb/s in q_def and the ACKs nicely in q_pri. Why whine ? Upload and download at the same time, however, does not improve at all: upload remains unchanged about 100kb/s, download is about 26kb/s; about 1/10 of the rate without download. *This* is what should improve, but is uneffected by the queues, even though the ACKs are (seem) prioritized. Primo� seems to experience something similar to what I observe here: "If I set the bandwidth to the _downlink_ speed and not to the _uplink_." This is precisely what I noticed (see above): The uplink rate is controlled by the queue and shows as traffic; while the download rate doesn't show at all (q_def remains about 0). When I change the bandwidth to 80kb/s, pfctl -vvsq follows suite (for upload): q_def is very close to 79.9 kb/s. To the cold eye this looks like download never shows up in the queues, upload works as expected, ACKs are transmitted with priority. Download, our aim, remains the problem. There seems to be no 'space' for the data, except - as Primo� wrote - by setting the bandwidth higher. Could you try if this *really* increases the download speed to about the advertised one ?
Uwe __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
