Comment by gerdesj | Hacker News Reader

Comment by gerdesj | Hacker News Reader

OK so someone has noticed that you "only" need 15MBs-1 for a 4K stream. Jolly good.

Now let's address latency - that entire article only mentioned the word once and it looks like it was by accident.

Latency isn't cool but it is why your Teams/Zoom/whatevs call sounds a bit odd. You are probably used to the weird over-talking episodes you get when a sound stream goes somewhat async. You put up with it but you really should not, with modern gear and connectivity.

A decent quality sound stream consumes roughly 256KBs-1 (yes: 1/4 megabyte per second - not much) but if latency strays away from around 30ms, you'll notice it and when it becomes about a second it will really get on your nerves. To be honest, half a second is quite annoying.

I can easily measure path latency to a random external system with ping to get a base measurement for my internet connection and here it is about 10ms to Quad9. I am on wifi and my connection goes through two switches and a router and a DSL FTTC modem. That leaves at least 20ms (which is luxury) for processing.

There is no way that "15MBs-1" is more clear than "15MB/s", especially in an environment which lacks the ability to give text superscript styling.

Sorry mate, an old habit.

Perhaps we should insist on more from formatting from above. That's probably a post processing thing for ... gAI 8)

Old habit from where? Is this a personal preference or a lesser known convention?

Pretty common physics convention, uncommon when referring to data speeds but common for other things measured over time.

Someone said physics, it's also very common in engineering. But academically and professionally, I've only seen it with superscript.

Used that a bunch in physics class in school. Makes it much easier to calculate with units since you simply add up the exponents of the units instead of having to consider the notation around the units.

Doesn't work well in pure text mediums.

Even worse when it's actually 15Mb/s.

15 Mb·s⁻¹

Mb•Hz

Okay, this was way funnier than it has any right to be.

Мб and хз are both common acronyms in Russian, so this reads as “может быть, х** знает”, roughly: “maybe, f--- if I know”

Which could be written as 15Mbps with no doubt whatsoever.

A decent quality stream is not 256 kilobytes per second (1/4 megabyte), as you write. You probably meant 256kilobits, which is only 32 kilobytes. For speech that’s VERY high quality. Teams actually uses either G.722 or SILK codec, which is just 40kbit/s. That’s 5 kilobytes per second.

Tangentially related to the topic of the bandwidth efficiency of Teams: screen sharing in Teams has a very low framerate of about 3 to 4 fps. It is driving me insane, especially when the presenter starts relentlessly scrolling up and down and circling things with the mouse cursor.

I think Microsoft took bandwidth efficiency a bit too far here.

256kbps (yes I was pissed and miss-typed B for b and a few other transgressions) or whatever is sod all these days for throughput, as you well know, so worrying your codecs down to 40kbps means nothing if your jitter buffer is going mad!

Modern home/office internet connections are mostly optimised for throughput but rarely for latency - that's the province of HFT.

You see tales from the kiddies who fixate over "ping" times when trying to optimize their gaming experience. Well that's nice but when on earth do you shoot someone with ICMP?

I can remember calling relos in Australia in the 1970s/80s over old school satellite links from the UK or Germany and it nearly needed radio style conventions.

I've been doing VoIP for quite a while and it is so crap watching people put up with shit sound quality and latency on a Teams/Zoom/etc call as the "new" normal. I wheel out Wireshark and pretend to watch it and then fix up the wifi link or the routing (Teams outside VPN - split tunnelling) or whatever.

That's a 1/4 megabit per second. The codec should be around 32,00 bytes and thus 256,000 bits. The problem is the Internet is not multicast so if I'm on with 8 participants that's 8 * 32,000 bytes and our distributed clocks are nowhere near sample accurate.

If you really want to have some fun come out to the country side with me where 4G is the only option and 120ms is the best end to end latency you're going to get. Plus your geolocation puts you half the nation away from where you actually are which only expounds the problem.

On the other hand I now have an acquired expertise in making applications that are extremely tolerant of high latency environments.

The first time I learned about UDP multicasting, I thought it was incredible, wondering how many streams were out there that I could tap into, if only I knew the multicast group, and all with such little overhead! Then I tried to send some multicast packets to my friend's house. I kept increasing the hop limit, thinking I was surely sending my little UDP packet around the world at that point. It never made it. :(

Mbone.

> If you really want to have some fun come out to the country side with me where 4G is the only option and 120ms is the best end to end latency you're going to get.

That's basically me. 80ms on LTE or 25ms on Starlink.

Used to be 1200-1500ms on BGAN, 160ms on 3G.

Oh you'd love Project Genesis.

It has all the latency associated with cell networks combined with all the latency of routing all traffic through AWS.

As an added bonus, about 10% of sites block you outright because they assume a request coming from an AWS origin IP is a bot.

Latency is an issue but it's not the biggest one. Most real-time protocols can adjust for latency (often using some sort of OOB performance measurement port/protocol.) The issue is jitter. When your latency varies a lot, it's hard for an algorithm to compensate.

You can't fix problems caused by network latency by adjustments in real time apps like video/audio calls or gaming.

Maybe you are thinking of working around bufferbloat?

I agree for video + audio calls, but I’m not sure for gaming.

Usually multiplayer games have some correction and if you have really stable latency it can work pretty well (of course never as well as 0 latency). But usually, the jitter is the killer because it makes actions delayed AND unpredictable.

And then comes all the latency _jitter_ inherent in a shared resource like 5G, and on top of that shenanigans like (transparently) MITM-ing TCP streams on a base station by base station base.

5G is (at least on paper) _very_ low latency; couple of ms.

It is until you congest it. Then, like all other network technologies, performance collapses. You can still force traffic through with EDC, buffering, and re-tries, but at massive cost to overall network performance.

Cellular technologies can be configured to degrade differently to WiFi. The device gets fewer assigned slices, so the bandwidth reduces, but latency should remain static.

How does voice call quality degrade? Does it switch to a tinny bit rate?

On 4G or 5G, if voice quality is degrading it's either being switched to a lower quality codec, or it's an upstream issue.

It is not on paper. Couple of ms ( 4ms ) is real, except it is not normal 5G but specific superset / version of 5G.

Your network needs to be End to End running on 5G-A ( 3GPP Rel 18 ) with full SA ( Stand Alone ) using NR ( New Radio ) only. Right now AFAIK only Mobile networks in China has managed to run that. ( Along with turning on VoNR ) Most other network are still behind in deployment and switching.

Although the deployments are very limited, wouldn't the 5G mmWave coverage, in NFL stadiums for example, need to have both New Radio (NR) and Stand Alone (SA)? Or is there some bodge for down-rating your mmWave experience to a non-Stand Alone network? I understand you won't get SA end-to-end calling an endpoint on an LTE network, but, with 5G FWA also needing SA to achieve full performance, SA should be pretty widespread in the US, or is it?

US Stadium mmW deployments and showcases at marquee sporting events happened well before SA was ever out of the labs.

On that note, the BBC deployed a temporary 5G SA non-public-network to broadcast King Charles' Coronation, giving over 1Gbps uplink over 1km of the procession route. More details are in the award-winning white paper linked from this[0] blog post.

[0]: https://www.bbc.co.uk/rd/blog/2023-05-5g-non-public-network-...

I could not imagine any private news-gathering organization to set up a temporary cell network for coverage.

Eh, I wouldn't be that surprised if it happens from time to time for big events. You'd be talking the very big sophisticated ones, but it is possible to get temporary licenses, and the equipment isn't _catastrophically_ expensive, particularly if you're just renting it.

This: https://en.wikipedia.org/wiki/Chaos_Communication_Congress usually has a temporary cell network (I think up to LTE last year) set up for the duration of the event, on a temporary license. And that's basically just done for fun.

I know a few companies that have managed to get the license to do it.

F1 TV also gets radio spectrum which they use for something like 4G for their wireless cameras.

Barring some revolutionary new material where we can get EM waves to travel orders of magnitude faster through it over current stuff, I don't think we're ever getting around the latency problem.

It's usually not a speed of light problem. It's a problem of everyone optimizing for bandwidth, not latency, because that is the number that products are advertised with. Speed of light is 200'000-300'000 km/s in the media used, that should not be very noticeable when talking to someone in the same country.

See my comments about L4S.

Well, fucking finally! But it seems like it's going to take a few more years until L4S is deployed everywhere.

Secret is to try off alg.

Reply on news.ycombinator.com