來看 Intel + Varnish 的單機 500Gbps 的 PR 新聞稿

在「Varnish Software Achieves 500Gbps Throughput Per Server for UHD Video Content」這邊看到 PR 稿,由 IntelVarnish 合作,宣稱達到單機 500Gbps 的 throughput 了:

According to Varnish Software, the following were the outcomes of the test:

  • 509.7 Gbps live-linear throughput, using a dual-processor configuration
  • 487.2 Gbps video-on-demand throughput, using a dual-processor configuration

白皮書在「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」這頁可以用個資交換下載,不過用搜尋引擎找一下可以發現 Intel 那邊有放出 PDF (但不確定兩邊給的是不是同一份):「Delivering up to 500 Gbps Throughput for Next-Gen CDNs」。

單 CPU 的伺服器是四個 100Gbps 界面接出來,雙 CPU 的伺服器是八個 (這邊 SUT 是 system under test 的縮寫):

These client systems were connected to the CDN servers using 100 GbE links through a switch; 4x100 GbE connections for the single-processor SUT, and 8x100 GbE for the dualprocessor SUT. Testing was done using Wrk, a widely recognized open-source HTTP(S) benchmarking tool.

不過如果實際看圖會發現伺服器是兩個 100Gbps (單 CPU) 與四個 100Gbps (雙 CPU),然後 wrk 也吃了兩個或是四個 100Gbps:

在白皮書最後面也有提到測試的配置,都是在 Ubuntu 20.04 上面跑,單 CPU 用的是兩張 Intel 的 100Gbps 網卡,雙 CPU 的用的是四張 Mellanox 的 100Gbps 網卡:

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Single processor SUT configuration was based on the Supermicro SMC 110P-WTR-TNR single socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by two 100 GbE Intel® Ethernet Network Adapters E810. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 8 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80 generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnishplus-6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

3rd generation Intel Xeon Scalable testing done by Intel in September 2021. Dual processor SUT configuration was based on the Supermicro SMC 22OU-TNR dual socket server based on Intel® Xeon® Platinum 8380 processor (microcode: 0xd000280) with 40 cores operating at 2.3 GHz. The server featured 256 GB of RAM. Intel® Hyper-Threading Technology was enabled, as was Intel® Turbo Boost Technology 2.0. Platform controller hub was the Intel C620. NUMA balancing was enabled. BIOS version was 1.1. Network connectivity was provided by four 100 GbE Mellanox MCX516A-CDAT adapters. 1.2 TB of boot storage was available via an Intel SSD. Application storage totaled 3.84TB per drive and was provided by 12 Intel P5510 SSDs. The operating system was Ubuntu Linux release 20.04 LTS with kernel 5.4.0-80- generic. Compiler GCC was version 9.3.0. The workload was wrk/master (April 17, 2019), and the version of Varnish was varnish-plus6.0.8r3. Openssl v1.1.1h was also used. All traffic from clients to SUT was encrypted via TLS.

不過馬上就會滿頭問號,四張 100Gbps 是怎麼跑到 500Gbps 的頻寬...

這份 PR 馬上就讓人想到 Netflix 先前放出來的投影片 (先前有在「Netflix 在單機服務 400Gbps 的影音流量」這篇提到),在 Netflix 的投影片裡面有提到他們在 Intel 平台上面受限於記憶體的頻寬,整台機器只能跑到 230Gbps。

另外一種猜測是,如果 Intel 與 Varnish 宣稱的 500Gbps 是算 switch 上的總流量 (有這樣算的嗎,你是 Juniper 嗎...),那這邊的 500Gbps 換算回去差不多就是減半 (還很客氣的沒把 cache 沒中需要去 origin server 拉資料的流量扣掉),跟 Netflix 在 FreeBSD 上跑出來的結果差不多啊...

坐等反駁 XDDD

Amazon EC2 推出 VT1 Instance

看到 Amazon EC2 推出新機種 vt1,專門為影片壓縮而推出的 family type:「New – Amazon EC2 VT1 Instances for Live Multi-stream Video Transcoding」。

主要是透過 Alveo U30 Data Center Accelerator Card 這張卡加速,號稱比 GPU 機器還要省 30% 的費用 (CPU 的話可以到 60%):

These VT1 instances feature Xilinx® Alveo™ U30 media accelerator transcoding cards with accelerated H.264/AVC and H.265/HEVC codecs and provide up to 30% better price per stream compared to the latest GPU-based EC2 instances and up to 60% better price per stream compared to the latest CPU-based EC2 instances.

看規格支援 H.264H.265,不過看起來沒支援 royalty-free 的 VP9AV1...

另外這跟 AWS Elemental MediaConvert 以及 AWS Elemental Live 好像稍微有點打對台?另外專利的費用不知道怎麼算...

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息,Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份,這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因,是因為 DebConf20 需要一個非封閉式平台的直播架構,而 PeerTube 看起來很適合這個情境:

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題,這個算是其中的一個方向,試著在解決平台壟斷的問題...

AWS 推出直播服務 Amazon Interactive Video Service (Twitch-as-a-Service)

把直播系統包在一起的服務 Amazon Interactive Video Service:「Amazon Interactive Video Service – Add Live Video to Your Apps and Websites」。

這邊先抱怨一下,這個服務的網址是 https://aws.amazon.com/ivs/,但 Elastic Load Balancer (ELB) 卻是 https://aws.amazon.com/elasticloadbalancing/,這是差別待遇啊...

回到原來的主題,這個服務做了幾件事情。收到 RTMPS stream 後,他會轉成許多格式:

If you send the maximum 8.5Mbps, 1080p60 stream, Amazon IVS will create 8.5Mbps 1080p60, 3Mbps 720p60, 2Mbps 720p30, 1.2Mbps 480p30, 800Kbps 360p30, and 400Kbps 160p30 renditions in an ABR stream.

從這份列表可以看出他目前最高只支援 1080p60,而 1440p (2K) 或是 2160p (4K) 看起來都還不支援。

另外因為是包裝 AWS Elemental Media Services,所以有蠻多東西都一起可以拿進來用,像是廣告機制與 DRM,然後看起來可以選擇 CDN:

With AWS Elemental Media Services, you have a high level of control over all workflow components: transcoding and packaging configurations; levels of resilience; personalized ad insertion; and features like content protection for digital rights management (DRM). You also get to choose which video players and CDNs are used.

區域上只開了三區 (us-east-1us-west-2eu-west-1),但我在看 AWS 上的標價時整個搞混:

一開始看的時候在找單位但發現沒標,後來研究了一下看起來應該是 per hour?這樣標看起來很像是前面一萬個小時只要 USD$0.32 啊?

另外一個比較有趣的事情是,看起來不像是用 CloudFront 做,因為收費區域的區分跟 CloudFront 不太一樣,實際開下去後發現似乎是用 Twitch 的架構?

我試著開了一個,給了 a9a09e285166.us-east-1.playback.live-video.net 這樣的 endpoint,實際測試發現的確是某種 CDN,指到台灣的機房:

;; ANSWER SECTION:
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 23.160.0.254
a9a09e285166.us-east-1.playback.live-video.net. 56 IN A 192.108.239.254

實際 traceroute 後發現不是 CloudFront,但反解後發現 dig 拋出了 Justin.tv 的資訊:

;; AUTHORITY SECTION:
0.160.23.in-addr.arpa.  300     IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 44 10800 3600 604800 300

;; AUTHORITY SECTION:
239.108.192.in-addr.arpa. 300   IN      SOA     ib-ens.sjc02.justin.tv. admin.justin.tv. 49 10800 3600 604800 300

然後 traceroute 可以發現跟 video-edge-6ab612.tpe03.abs.hls.ttvnw.net (在 Twitch 上隨便找個實況抓的 hostname) 進到同一個機房 (在 router 還沒有擋下來的範圍),看起來就是拿 Twitch 的頻寬做事 XDDD

Twitch-as-a-service XDDD

這包會不會是 Twitch 掛 AWS 牌推出的服務啊 XDDD

AWS Elemental Link:直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link,可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上:「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎,大約 524 立方公分):

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI,規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限),然後設備除了透過一般電力供電以外,也可以用 PoE 供電,可以少接一條電源線:

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995,但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品,好像沒看到類似可以直接送到網路服務的產品...

擋 Live 與 Podcast 內廣告的工具

看到「An adblocker for live radio streams and podcasts. Machine learning meets Shazam.」這個專案,這個把 machine learning 用到「正途」上了啊...

不過畢竟是比較複雜的演算法,會吃不少 CPU 資源:

On a regular laptop CPU and with the Python time-frequency analyser, computations run at 5-10X for files and at 10-20% usage for live stream.

不過看用法還是偏向 library 性質,如果要大力推廣可能還是需要有其他人包個更好的界面...

Cloudflare 改善了同時下載同一個檔案的效率...

在「Live video just got more live: Introducing Concurrent Streaming Acceleration」這邊 Cloudflare 說明他們改善了同時下載同一個 cache-miss 檔案時的效率。

本來的架構在 cache-miss 時,CDN 這端會先取得 exclusive lock,然後到 origin server 抓檔案。如果這時候有其他人也要抓同一個檔案,就會先卡住,避免同時間對 origin server 產生大量連線:

這個架構在一般的情況下其實還 ok,就算是 Windows Update 這種等級的量,畢竟就是一次性的情況而已。但對於現代愈來愈普及的 HTTP(S) streaming 技術來說,因為檔案一直產生,這就會是常常遇到的問題了。

由於 lock 機制增加了不少延遲,所以在使用者端就需要多抓一些緩衝時間才能確保品質,這增加了直播的互動延遲,所以 Cloudflare 改善了這個部分,讓所有人都可以同時下載,而非等到發起的使用者下載完才能下載:

沒有太多意外的,從 Cloudflare 內部數字可以看出來這讓 lock 時間大幅下降,對於使用者來說也大幅降低了 TTFB (time to first byte):

不確定其他家的情況...

AWS 推出了 Live 時全自動上字幕的功能

AWS 推出了在直播時就自動上字幕的功能:「Introducing Live Streaming with Automated Multi-Language Subtitling」,其實就是把現有的服務兜出來:「Live Streaming with Automated Multi-Language Subtitling」。

The solution deploys Live Streaming on AWS which includes AWS Elemental MediaLive, MediaPackage, Amazon CloudFront. The solution also deploys AWS Lambda, Amazon Simple Storage Service, Amazon Transcribe, and Amazon Translate.

對於比較沒那麼要求翻譯品質的情況也許可以玩看看...?

Sandvine 對全球網路流量的分析,那兩個是怎麼上榜的...

看到「Netflix Dominates Internet Traffic Worldwide, BitTorrent Ranks Fifth」這篇報導了 Sandvine 對全球網路流量的分析,主要是這張:

大多數的應用都不算意外 (只是差在各地區的使用習慣),但 AMERICAS 的第十名 (XBOX LIVE UPDATE) 跟 EMEA 的第七名 (PLAYSTATION DOWNLOAD) 是怎麼一回事 XDDD