PRIQ 1 user and have drops?
-
Hi.
I have setup TC PRIQ, I have 1 users downloading 1 files, just 1 user and I have drop, how can this be possible?
Thanks.
-
I'm wondering if the drops being reported are accurate. I've read in another thread that may not be the case.
https://forum.netgate.com/topic/83141/traffic-shaper-queue-length-and-dropped-packets/22I recently setup a very basic PRIQ setup with VOIP as the highest priority. I can see VOIP traffic going into the correct que as expected. When I checked the drops today it's very high but I'm skeptical of that number. I have had zero complaints of users on the phones having issues and we have more than enough bandwidth to handle anything the users are doing on the network. I'm ignoring that for now until I have any actual issues.
-
Drops are normal. If the user tries to transmit at a rate above what the interface (or their queue) is configured to allow, drops keep them under the set limits.
There may only be one user but they are still constrained by the limits of the shaper configuration.
-
@jimp Thanks. That makes sense. I'm sure I'm not understanding the way PRIQ or traffic shaping in general works, but in our specific use case our network bandwidth far exceeds our needs in both downstream and up (250Mbps/50Mbps). Traffic shaping probably wasn't necessary, but the reason I setup PRIQ using the wizard in the first place was to ensure that VOIP traffic would not be limited by something like an FTP upload that would otherwise try to use all the bandwidth. Wouldn't the highest priority que generally have the least amount of drops? In my case, the highest priority que (VOIP) is the one consistently with the highest amount of drops. According to ntopng our average throughput (mostly emails and web browsing) is in the range of ~ 1 Mbit/s. Checking different time frames were in the same ballpark (1 day, 1 week, 1 month, etc). So it's safe to say we are well under utilizing our bandwidth. I even watched a 4K movie to test how much it goes up by and it only went as high as ~ 15 Mbps downstream. If i read the docs correctly, you don't want drops happening with UDP (VOIP) since there is no retransmission. Yet the users are not complaining about call quality. That's what leads me to think there is something odd about the drop numbers reported in my particular case.
Thanks,
Raffi -
Drops don't really mean anything about priority until there is contention for bandwidth. If traffic in the VoIP queue tries to exceed the configured interface speed (even very briefly) it will have drops that keep it in line. In that case you'd see more drops on whatever queue had the most traffic if it's trying to go "too fast" and not about which queue has preference.
It could also be that the queue length needs to be increased due to the amount of traffic and potentially high bandwidth in the queue. You could tinker with that value (which is at 50 now in your screenshot), increasing it quite a bit higher.
-
@jimp ooooh ok. That explains it.
Thanks for the tip. I will try to adjust the queue length if I do run into trouble with phone calls.
Raffi -
A 5Mb/s video stream from youtube can burst upwards of 10Gb/s for a few milliseconds. The average over one second is only 5Mb/s, but for a brief moment, it's 10Gb/s.
Packets don't come in a smooth flow, they're bursty. Unless you're talking about a single stream of paced UDP. Your buffer needs to be large enough for your typical burst. You don't want the buffer too large because that can lead to buffer bloat. But you also don't want it so small that packets are unnecessarily getting dropped. VoIP is generally resilient to some drops, but may not like jitter.
Your buffer of 50 packets, assuming 1540 bytes of data, would represent about 12ms at 50Mb/s. That is your maximum buffer bloat. A little google and I see a typical VoIP packet is about 500 bytes or less, so really your buffer bloat would be only about 4ms. You could double the buffer to 100 and your maximum bloat, assuming proper VoIP traffic, would only be about 8ms at max. The reason you care about buffer bloat is that is what determines your maximum jitter. Even 8ms of jitter is pretty low.
-
@Harvy66 Thanks for the education and info, I really appreciate it. I will keep this in mind and refer back to this thread if I do have any issues. So far I haven't had any complaints from VOIP users.