I am suffering from an issue where as a call increases in time I get more and more audible latency. on the server side I was told to run ss -4 -l -n | grep udp (which I think is the same as ss -4 -l -n -u?).
in there I see in the recvq on most connections is either 0 or 2304, sometimes briefly peaking above that before going back down to one of them or somewhere inbetween.
in an example call that was hours long and I had a ton of latency I had a recvq of 180,000...which I thought was impressive. the call itself was: nearly 7 seconds of round trip latency.
I'm not very good with this type of troubleshooting and am wandering around the internet reading about what these recv and send values mean.
is 2304 an important number? default queue size for my box? (deb 9 running freeswitch if it matters).
additionally, I was asked if the problem could be causes by our comcast circuit somehow misbehaving. instinctively I think no: if the recvq is bloated to hell it means the packets are making it there and just getting stuck waiting to be processed by the application listening on that port, right? or could the packets come into the queue in a way that would cause it to bloat (this is all udp traffic, rtp stream if it helps)?
further reading on how to troubleshoot latency issues would also be appreciated.
