Hacker News Reader

Comment by yakubin | Hacker News Reader

I work from home and regularly need to download large files from work servers. Several months ago I noticed that my internal network was 100Mb/s, which was dreadful. Downloads of 500MiB files would take tens of minutes, because Tomcat would drop connections on such a slow download. And even without dropped connections it generally took a long time to download anything, and Zoom call quality was regularly degraded (I sometimes heard my colleagues as androids and vice versa). I fixed the issue and now I get the full 700M/s that my ISP offers (and 1G/s internally over a Netgear switch for NFS transfers). I could get a 1G/s, but it would cost me more and 700M/s is fine for the most time. But sometimes to get a shorter feedback loop on what I'm doing I could imagine getting a 5G/s. I think it would be optimal. But 10G is clearly overkill.

View on HN

"Zoom call quality was regularly degraded"

It sounds like something else was dodgy on your previous network, surely Zoom cannot use up 100mb/s connection

When one side sends data at 1Gb/s and the other receives at 100Mb/s, it's worse than if the first side sent data at 100Mb/s. Here's a description from Julia Evans: <https://jvns.ca/blog/2018/07/12/netdev-day-2--moving-away-fr...>

Basically my ISP router would receive data at full speed, while internally I would have a lot of dropped packets.

Additionally, I usually use the web browser to view Jira or copy files over NFS during calls, and I'm sure there are some background apps contributing to the traffic as well.

The one thing that fixed all my problems was reconfiguring the network driver to set 1G bandwidth on my NIC instead of the 100M that it set automatically. Yeah, Linux Desktop problems...

> Basically my ISP router would receive data at full speed, while internally I would have a lot of dropped packets.

This is not how this works. The other end of your zoom call doesn't go "hey the person I'm talking to is on a 700mbits line, so that's how much data I'll send." By that logic you could extend this to the network of your isp, which is probably 10 or 100gbits, so you should have a lot of packet loss where the transition from 10gbits to 700mbits happens. And it's not even clear how the other peer could even know how fast your internet connection is, or the internal network of your ISP. That is what congestion control is for. Your peer can't know your modem's connection speed nor your LAN's speed. Software will simply observe how fast it can send data before packet loss starts to happen. This obviously requires that the there is some sort of feedback by the peer you're talking to. If you're using TCP, the OS will do that for you for free. With UDP, you have to implement that logic yourself in your application. And that's why it doesn't matter where the bottleneck is, it could very well be somewhere "in the middle" between two ISPs.

> I noticed that my internal network was 100Mb/s, which was dreadful. Downloads of 500MiB files would take tens of minutes, because Tomcat would drop connections on such a slow download. And even without dropped connections it generally took a long time to download anything, and Zoom call quality was regularly degraded.

Was you network setup broken? Did your firewall block ICMP? Ancient servers like tomcat and apache should handle slow networks in stride, even with modern updates - and 500MB at 100mbps is 40 seconds?

Now I can't imagine running 100mbps today for a home network... So upgrading makes sense. But your problems doesn't sound like they were caused by your lan speed.

In my case it was either 1G or 10G (no in-between), price difference between 1 and 10 wasn't huge, most of the cost was installing the actual fibre optics in the house.

Reply on news.ycombinator.com