One overview of network performance stats for all participants / whole session

[OpenDictator]

This is my first posting in this project. I'm really enjoying what this software and its community is enabling.

I've joined the jamsessions at Worldjam.vip and noticed that when a group is formed and a server is picked, we spend quite a bit of time to check on everybody's ping and latency stats. Given the volatility in network traffic, I've also experienced the need for these checks with the same group on the same server, but at different dates.

I don't know if the clients already share their network stats with the server, but I imagine they do in order to make the audio stream synchronisation work.

I imagine having a session 'network check' function with an overview of all players' network stats can be very helpful to get started more quickly. By seeing each others stats, players can coach each other to optimize settings etc.

[dcorson-ticino-com]

Hi Open,
Glad you are enjoying using Jamulus.

FYI: Jamulus is written lean and mean to squeeze every drop of network capability in the service of good connections.
Note that the parameter most causing problems for us is the jitter, non-regularity in the network packet delivery, and not the network speed. Unfortunately we are about the only group of users with this requirement profile and the networks are not optimized for low jitter, but for high speed.
Anyway, being lean and mean Jamulus does no stat collection and only the client knows its own state, the server doesn't know nor does it need to know.
There have been requests for stat collection in the past, but it would need protocol changes and cause additional network usage.
The possibilities of a client to react to network changes are very limited anyhow.

In my experience, in any case, when a group gets together, there is some optimising the first couple of sessions, but after that everyone knows what to do and it is simply connect and jam.

[hoffie]

I don't know if the clients already share their network stats with the server

I don't think things like latency or buffer fill status is transmitted.

However, I second this request. There have multiple other requests and ideas around this topic in the past. I'm planning to publish a proposal for adding such (optional) instrumentation/monitoring to Jamulus. I don't quite get around to doing it though, but it's on my list. :)

[gilgongo]

These "telemetry" discussions seem to divide into two types: ones that are aimed at "deep dive" analysis that would perhaps give insights into protocol or other issues (so, logs essentially), and ones that specify something in the UI of Jamulus itself. These latter discussions tend to include statements (as here) such as if such stats were known, "players can coach each other to optimize settings etc."

I'm curious as to what that would mean in practice though. So if you saw somebody had a 100ms ping, what would you say to them beyond the established "best practice" checks we give on the website?

[OpenDictator]

Thanks for asking for clarification @gilgongo Gilgono. My experience is that for a newly formed group, or a group on a 'new' server, time is spent asking about each others network stats.

'Coaching' in this case refers to have someone check their network buffers, check if they have wired internet, etc. Newbee stuff perhaps, but it can be helpful if advanced users can quickly spot situations like this. Especially in larger groups.

There is also an aspect of 'negotiating' when players from different countries are picking a server out of a list of options. Even when a group has settled on a particular server, the performance is not always as expected.

Hope this helps.

[gene96817]

I am not sure which of the two types of telemetry interest covers my use case. I am seeing some data paths (between user and server) that have highly variable ping times. Variable could mean day-to-day, or different times of day, or during a session. Most people focus on (TCP) speedtest as an indicator of service quality. I need to surface the UDP transit variability. You could consider this part of bufferbloat. Here in my area, it appears to be a symptom of underprovisioned networks. I am working on a project to expose the underprovisioning (as the reason for poor service quality).

This problem affects some of my chorus members. No amount of better client adjustments can fix the problem.

[gilgongo]

@OpenDictator So an indication that the client connected had a high ping time or a high delay time would mean that you could prioritise talking them through the "standard stuff" (are they using a short buffer, on wi-fi, watching Netflix etc.)? I ask because (although I'm not an engineer) I think getting that data may be quite hard if not actually impossible with the current Jamulus architecture. So it would require a lot of work to implement. But if such work doesn't really offer a clear benefit, it's hard to justify. As people have said before about this: your ears are the first and last judge of whether any issues are present. To what extend do they need confirmation of this, given that there are so few things you can actually do to make the sound better?