dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
73
Cloneman
join:2002-08-29
Montreal

1 edit

Cloneman

Member

Re: Tomato QoS major bug (all versions, incl toastman, shibby)

What you're describing seems to correlate with the results I'm seeing, but I don't see how QoS can be effective when operating in this manner.

At least in my testing, I recall that even if you give a class High Priority, it won't have good enough jitter/ping for VoIP unless there is a chunk of bandwidth left over, unassigned to anything within the global maximum you've set.

not
@comcast.net

not

Anon

No, limiting jitter on a call is about not having dropped packets. Remember that VoIP has bad quality because packets don't/cannot retransmit. That's when you get jitter and bad call quality. So, in order to keep that from happening, you build up QoS so that everything is prioritized properly. I think you're finally getting it, but treat QoS no different than the subway system. It's not about increasing the amount of trains you have or speeding them up. It's about fitting the most people in the cabins in the most efficient way. If you have a ton of "fat" people, (i.e. VoIP), you fit them in first and then fill in the small empty areas with the other smaller packets which have retransmit capabilities... either they fit or they don't and if they don't, they get in the next car or the next train via a retransmit which own't affect that traffic in a negative manner aside from speed impairment... something that doesn't affect it as badly as VoIP quality drop does.