A problem that started a few weeks ago returned again last night for myself and several other virginmedia users within the group I was playing with.
All night between 19:00 and 23:00 BST we were unable to stay connected to a mumble server for more than 5 minutes.
Connecting, moving channel, in fact anything to do with the channel controls within mumble were severely lagged and 95% of the time resulted in us being disconnected from the voice server.
During the few minutes we were connected the actual transmitting and receiving of voice data was absolutely fine.
Whilst I appreciate you may want me to run all kinds of local connection and client checks I should point out that there were 3 VM users in total within a group of 12, all 3 of us had the problem all evening across the 2 different mumble servers we tried, the other 9 people had no problems all night on the same server(s).
This problem first started sometime last month, continued for a week (during peak times) and then disappeared until yesterday evening.
If you're going to inspect my data, please give it the priority it needs.
Welcome to the forum, sorry you are suffering problems to mumble, we will take a look.
I appreciate your post suggests a common issue but thought I would check your connection to be sure all is well. You will be pleased to hear I can see no problems. The traffic in your area does build up a bit in the evening but not too bad so there may have been something else going on.
If it occurs again please try a wired connection to this site if you are not using that already that is, Perhaps some traceroutes or pathpings may reveal something?
Yeah I'm not a huge tech guy so i don't really know the implications of it this is just what multiplay told me to do. All I know is the only way to make dota more frustrating is to constantly lose voice comms, well that and try to call virgins tech support and explain this issue.
Those WinMTR stats seems to be the same as me with the 3rd and 4th jumps being no response and the 5th and 6th jumps being at 50-100% loss, All being Virgin nodes.
WinMTR uses ICMP packets. Those nodes are told to ignore them (no response) or return on low priority or discard when busy ("packet loss")
Hopefully that explains your comment here and
I've read a few times in this post that someone is trying to blame it on LINX but why does the problem in everyones tracers/Monitors show the problems starting before it gets anywhere near LINX.
For me the 3rd and 4th jump in the trace show as no response from host (don't know if this is normal) but the 5th and 6th jumps (brhm-bb-1c-ae0-0.network.virginmedia.net & tcl5-ic-2-ae0-0.network.virginmedia.net respectively) is where the problem clearly starts.
Some of the issue is the hump at Linx for sure. UDP transmission as highlighted above may well be part of the issue?