On Sat, 18 Jun 2016 11:29:50 +0000 (UTC) Bohdan Tashchuk <btashc...@yahoo.com> wrote:
> On Fri, 6/17/16, Marko Cupać <marko.cu...@mimar.rs> wrote: > > > Perhaps it would be useful to add that 'set prio' does nothing > > unless "hardware is slower at transmitting packets than the > > thing that generates these packets to send", as stated here: > > > > [http://marc.info/?l=openbsd-misc&m=145257356119612&w=2] > > > > ... thus making it inappropriate for solution of OP's problem. > > Hi, > > I'm the OP. I agree that a single VoIP session doesn't need > 'set prio' in normal circumstances. > > The reason I want to implement it in my home network is > because, occasionally, one of the kids will upload > something big, e.g. a few hundred megabytes of pictures, > to some social network. > > When that happens, my Internet "goes to shit" for the > duration. The upload attempts to push 100 Mbit/sec > or more to my firewall. Which then tries to push > to the Internet over the 5 Mbit/sec uplink speed of my > cable modem. Which immediately saturates. Which results > in the usual problems, such as 2000 msec or longer ping > times. Etc. Of course, TCP eventually backs off, but things > remain quite unpleasant for the duration of the upload. > > I don't want VoIP to suffer under those circumstances. So > if I can work around this with 'set prio' (and not need to > get queues involved), then it's certainly worth trying to do it. > > I will, of course, do some tcpdump monitoring in the near > future, and report back to the list as to how successful I > was in solving my problem by simply using 'set prio'. I was trying to achieve the same goal the same way as you, as it came to me as a common sense that packets with higher prio would be processed first. However, I found out this is not how things work. Prio does not respect bandwidth set on queue. It starts to discard packets with lower prio value when interface's physical bandwidth is saturated, which - in your and my case - means never. Maybe you will have better luck with queues. Make sure you set max bandwidth on parent queue. I prefer to set also min: # QUEUES queue ul on $if_ext bandwidth 800K min 800K max 800K queue hi parent ul bandwidth 100K queue std parent ul bandwidth 600K default queue low parent ul bandwidth 100K This work on traffic leaving external interface - traffic in low queue will get 800K, but once traffic in std queue kicks in, low will get throttled to 100K. I haven't managed to make it work as expected for traffic leaving internal interface (eg. replies from the Internet to requests from local network). Regards, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
