Server sizing¶
The figures in this section are guidelines for planning, not measurements on your hardware. Consumption depends on the protocols, settings and sources, so allow headroom and check the load on site: the web interface shows the node’s CPU, memory and network interface load, and alerts report thresholds being exceeded (Alerts (alerter)).
CPU and memory¶
The general rule (System requirements): 1 core at 2.4 GHz and 1 GB of memory for every 200 Mbit/s of traffic. Count input and output together: the node parses and checks every packet on the input and sends it separately on each output.
Example: 40 HD channels at 8 Mbit/s, each sent once to multicast. Input is 320 Mbit/s, output is 320 Mbit/s, 640 Mbit/s in total: by the rule that is 3–4 cores.
Memory grows with the number of streams rather than with traffic. For plain UDP distribution the “1 GB per 200 Mbit/s” rule is generous, but do not plan for less than 2 GB for the system and the service.
A stream with OTT delivery keeps a window of segments in memory — about 40–80 seconds of the channel.
Transcoding is not covered by the rule. The transcoder needs its own resources — CPU cores or a GPU (Transcoders). If the channels are passed through as they are, no transcoder is needed.
DVB adapters¶
Each adapter reads the whole transponder — usually 40–80 Mbit/s — and extracts the required programmes from it. For planning, allow up to one core per adapter: this is an upper bound, and actual consumption is usually much lower. If a core is nevertheless fully busy, the node raises alert code 40 (dvb-thread-cpu, List of alerts).
Software BISS descrambling of several programmes of a transponder takes a small fraction of a core.
A CAM module descrambles by itself and puts almost no load on the node. The limit here is the module itself: how many programmes it can descramble at once is stated in its specifications.
Delivery to guests (OTT)¶
Size guests’ phones and tablets by the outgoing bandwidth: number of simultaneous viewers × channel bitrate. 200 viewers at 3 Mbit/s come to about 600 Mbit/s from the node. With that many viewers, the network interface and the link to the guest network hit their limit before the CPU does: all viewers of a channel read the same segments from memory, and there is no separate copy per viewer.
Network interfaces¶
Put multicast for the TVs and the internet and OTT side on different interfaces, or at least on different VLANs. The node sends multicast from the interface set on the output and serves OTT from the address of its HTTP server, so this separation comes about by itself.
0.5–1 Gbit/s of multicast fills a 1 Gbit/s port completely. If multicast can reach 1 Gbit/s, use 10 Gbit/s on this side or a bond of two 1 Gbit/s ports.
The node has no limit of its own on the multicast send rate: the limits are set by the network card, the switch and the IGMP configuration (Multicast network in a hotel).
Disk¶
Without DVR, the node needs space only for settings, logs and small databases (statistics, the log, EPG): about 10 GB of free space under /var/log/pss and the settings directory, with headroom. The main.log log is rotated daily, and old files are deleted after a month (Service log). The DVR archive is sized separately, by the depth and bitrate of the channels (OTT and DVR).
Examples¶
Small hotel |
Large hotel |
|
|---|---|---|
Channels |
30: 10 SD at 3 Mbit/s and 20 HD at 8 Mbit/s |
80: 20 SD at 3 Mbit/s and 60 HD at 8 Mbit/s |
Multicast traffic |
190 Mbit/s |
540 Mbit/s |
Sources |
2 DVB adapters, channels from the internet |
4 DVB adapters, channels from the internet |
Guests over OTT |
up to 30 viewers at 3 Mbit/s — 90 Mbit/s |
up to 200 viewers at 3 Mbit/s — 600 Mbit/s |
CPU by the rule |
input and output 470 Mbit/s — 3 cores, plus up to 2 cores for the adapters: 4–6 cores |
input and output 1.7 Gbit/s — 9 cores, plus up to 4 cores for the adapters: 10–14 cores |
Memory |
4 GB |
8–16 GB |
Network |
1 Gbit/s for multicast, 1 Gbit/s for the internet and OTT |
10 Gbit/s or 2 × 1 Gbit/s for multicast, 1 Gbit/s for the internet and OTT |
Disk without DVR |
10 GB for logs and settings |
10 GB for logs and settings |
If protection against a server failure is needed, the second node is sized the same way (Redundancy).
