Sat, 18 Jun 2016 11:29:50 +0000 (UTC) Bohdan Tashchuk <btashc...@yahoo.com> > 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.
Actually, it's not exactly this what causes, but this is exactly what happens as you describe it. It is very disappointing to have to deal with this while trying to get work done. Please see Daniel Hartmeier has a page with details what you can actually do to sort it out. It is frustrating that the CPE (cable, aDSL and various other typically asymmetric broadband Client Premises Equipment) don't try an inch to help you out with their default configurations. Pretty useless, huh? Prioritizing empty TCP ACKs with pf and ALTQ [http://www.benzedrine.ch/ackpri.html] I can't tell if this still applies and if the configuration snippets will be exactly as is, the page is dated and pf got several reworks. But you'll get the idea pretty well, and understand how to solve it. I can attest this worked for me several times in the past very fine. > 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'.
