d59053301e
This knob controls whether Linux throws away its congestion window (cwnd) after a connection has been idle for at least one retransmission timeout (RTO). With a value of 0, Linux keeps the cwnd it had before the idle period and can send that amount immediately when the application resumes writing (still bounded by the receiver's advertised window and by pacing). With slow start after idle enabled (the default), Linux allows only about 10 MSS (~14 KiB) in the first burst after idle. Even when a connection stays open to web clients, a short idle forces multiple round trips to ramp back up. On Wi-Fi, local connections often have very low RTTs, which drives the RTO down. Between page navigations the connection is considered idle by Linux. If the next request happens during a transient latency spike on the Wi-Fi link, the sender starts with a tiny cwnd and must grow it over many RTTs, so the spike causes outsized and visible loading delays. For devices behind typical Internet uplinks, the higher RTT makes the initial ramp-up feel even slower until the window regains size. However, here the connection does take longer to drop to idle, for Linux standards. So the connection is less likely to be considered idle between navigations. This change does not affect flows with very small receive windows (e.g. many microcontrollers), which are limited by the peer's advertised window rather than the sender's cwnd. Example RTOs on low jitter, low loss connections: Defaults: TCP_RTO_MIN = 200 ms TCP_RTO_MAX = 120 s low-jitter path so rttvar_us = 200 ms HZ = 1000 or 250 or 100 (depending on the kernel settings) *31 ms average RTT* - SRTT ≈ 31 ms; RTTVAR ≈ 200 ms → Sum = 231 ms - 'usecs_to_jiffies(231000)' = 231 jiffies (HZ 1000) -> RTO ≈ 231 ms - If 'HZ = 250' (4 ms tick), ceil(231/4)=58 jiffies -> 232 ms RTO - If 'HZ = 100' (10 ms tick), ceil(231/10)=23 jiffies -> 240 ms RTO *178 ms average RTT* - HZ=1000 (1 ms tick): 378 ms RTO - HZ=250 (4 ms tick): ceil(378/4)=95 -> 380 ms RTO - HZ=100 (10 ms tick): ceil(378/10)=38 -> 380 ms RTO *292 ms average RTT* - HZ=1000 (1 ms tick): 492 ms RTO - HZ=250 (4 ms tick): ceil(492/4)=123 -> 492 ms RTO - HZ=100 (10 ms tick): ceil(492/10)=50 -> 500 ms RTO Any loss or jitter will increase those RTO values.
Home Assistant Operating System
Home Assistant Operating System (formerly HassOS) is a Linux based operating system optimized to host Home Assistant and its Add-ons.
Home Assistant Operating System uses Docker as its container engine. By default it deploys the Home Assistant Supervisor as a container. Home Assistant Supervisor in turn uses the Docker container engine to control Home Assistant Core and Add-Ons in separate containers. Home Assistant Operating System is not based on a regular Linux distribution like Ubuntu. It is built using Buildroot and it is optimized to run Home Assistant. It targets single board compute (SBC) devices like the Raspberry Pi or ODROID but also supports x86-64 systems with UEFI.
Features
- Lightweight and memory-efficient
- Minimized I/O
- Over The Air (OTA) updates
- Offline updates
- Modular using Docker container engine
Supported hardware
- Nabu Casa
- Raspberry Pi
- Hardkernel ODROID
- Asus Tinker Board
- Generic x86-64 (e.g. Intel NUC)
- Virtual appliances
See the full list and specific models here
Getting Started
If you just want to use Home Assistant the official getting started guide and installation instructions take you through how to download Home Assistant Operating System and get it running on your machine.
If you're interested in finding out more about Home Assistant Operating System and how it works read on...
Development
If you don't have experience with embedded systems, Buildroot or the build process for Linux distributions it is recommended to read up on these topics first (e.g. Bootlin has excellent resources).
The Home Assistant Operating System documentation can be found on the Home Assistant Developer Docs website.
Components
- Bootloader:
- Operating System:
- Buildroot LTS Linux
- File Systems:
- Container Platform:
- Docker Engine for running Home Assistant components in containers
- Updates:
- RAUC for Over The Air (OTA) and USB updates
- Security:
- AppArmor Linux kernel security module
Development builds
The Development build GitHub Action Workflow is a manually triggered workflow which creates Home Assistant OS development builds. The development builds are available at https://os-artifacts.home-assistant.io/index.html.