If you can guarantee that the ship can be routinely filled to capacity, it's almost always economical to build the biggest ship you can. These things are often built to the maximum size that will fit into the canal that they transit.
I thought I remember reading that this ship was designed to meet the Suez canal specs.
Appreciate the write up with specific examples. I haven’t been discriminated against at work (that I’m aware of) and try very, very hard to avoid it (though I’m sure I have failed unknowingly). This helps remind me of how it can happen whether intentional or not.
> Rewriting it in C++ to magically solve problems. Good job, engineer.
Well it's a lot easier to make an app perform well in C++ than electron.
They should at least have for the VS Code team to help. That's one of the best performing Electron apps, it's strange MS never adopted those practices company wide.
Hmm when I compare the two in terms of CPU / Memory usage and speed, Teams is one of the worst performing electron apps on my system, and VS Code one of the best. I don't think this is just network related (and I have a 600/600 connection anyway).
Either way, even if this was the reason it would prove that Electron is not a good fit for an app like this.
The issue with teams is performance. Teams is a relatively simple application. C++ is extremely common and well known, would have been a better tool for the job. That’s called engineering when you actually care about the quality of the product.
If you’re willing to read documentation, OpenBSD is best-in-class for a secure, stable home router. The interfaces (configuration, CLI) are extremely simple and the man pages top notch.
I switched to OpenBSD on my desktop and remote server after many years of Linux use. It's now my goto OS for network connected stuff.
One caveat: A power cut during the relinking process that occurs during and after boot can wreck the filesystem. A UPS is advisable. Once the relinking finishes the filesystem is quite robust.
TCP does have retransmission, but it was designed for networks with very low packet loss and where most packet loss is due to congestion, so it does not react quickly to packet loss and when multiple packets are lost it slows down dramatically. TCP typically uses an exponential backoff in re-transmission times to avoid exacerbating congestion.
When dealing directly with UDP, one can implement different application-level logic for dealing with packet loss: "NAK" packets, different backoff strategies, and even forward error correction.
Yes, I had the same confusion. There seems to be a standard for TCP over UDP [1]. But in general, I would assume that it does not help at all WRT any of the packet loss/latency problems posed by satellite links.
TCP is designed for encapsulation in IP, this is why it is called TCP/IP. And UDP is very similar to IP, only difference is that UDP gives you source and destination port numbers and a payload checksum, where IP only gives you a protocol numbers and non-checksummed data. None of these "features" is going to have any effect on how TCP is delivered.
So the only effect that use of TCP over UDP would have here is:
- increase the overhead used for headers, thereby decreasing the MSS (segment size)
- "cloak" the TCP traffic as UDP and thereby prevent any routers and/or middleboxes [2] from applying special treatment to TCP (i.e. traffic shaping, buffering etc.)
Maybe the latter effect is what made a difference for the link in question.
He probably saw benefits from using UDP because he's no longer limited by TCP's congestion control and can flood the pipe with duplicates of his packets.
> He probably saw benefits from using UDP because he's no longer limited by TCP's congestion control and can flood the pipe with duplicates of his packets.
But he wrote that he'd used "TCP over UDP". The first lines of the TCP over UDP spec already state
"It provides exactly the same congestion control, flow control, reliability, and extension mechanisms as offered by TCP." [1]
