loss – Gea-Suan Lin's BLOG

Python 裡使用超過 Double Precision 的運算

Hacker News 上爬到的，是一篇 2019 的文章：「When Double Precision Is Not Enough (adambaskerville.github.io)」，原文在「T>T: When Double Precision is Not Enough」。

作者是拿矩陣 (matrix) 的運算當例子，遇到了 double precision 造成的計算誤差問題：

There is no error with the program; this discrepancy is caused by a loss of numerical accuracy in the eigenvalue calculation due to the limitation of hardware double precision (16-digit).

解法是用 mpmath 增加精度，算是一種暴力解，到要注意計算會慢很多：

Note that this library is incredibly slow for large matrices, so is best avoided for most applications.

另外在 Hacker News 的討論串裡面看到個有趣的東西：「Herbie: Automatically Improving Floating Point Accuracy」這個專案，你把公式丟進去，Herbie 會試著提供等價公式來維持精度，像是 $\sqrt{x+1} - \sqrt{x} = 1 / ( \sqrt{x+1} + \sqrt{x} )$ 這種東西。

半自動化幫你改善...

看起來這個月 HiNet 連外大概會不怎麼順...

在 Twitter 上看到這則障礙資料：

因 APG 海纜障礙影響 HiNet 客戶連線美國、中國及香港部份網站之連線品質
🕓 2021-10-30~2021-11-30, 2021-10-30 10:00AM

2021 年 10 月 30 日發生 APG 海纜障礙，客戶連線美國、中國及香港部份網站可能造成部分連線有少許延遲現象。https://t.co/bBapFA47He

— HiNet 網站公告 (@HiNetNotify) October 30, 2021

APG (Asia Pacific Gateway) 在 2016 年啟用，還算是新的海纜，看起來會有不少頻寬受到影響... 這點在 HiNet 上用 SmokePing 監控對 dynamodb.ap-southeast-1.amazonaws.com 的 packet loss 就很明顯的可以看出來了：

連過去封包掉的亂七八糟的，然後公司做東南亞生意，操作起來苦哈哈... 不過其他 ISP 看起來還行，應該有機會先繞過去。

台灣看 Lbry/Odysee 的速度變快一些

Twitter 上看到 jkgtw 提到 Lbry/Odysee 的速度快很多：

最近 lbry / odysee 在台灣看的速度突然變超快！雖然還不像 Youtube 那樣一點就看，但是也相差不遠了，真讚～ 👍 https://t.co/W5qGZsJsck

— Stephen  (@jkgtw) March 12, 2021

看了一下資料，HiNet 到 cdn.lbryplayer.xyz 的 latency 增加了，但是 packet loss 改善了不少，看起來是把本來導去新加坡的流量改導去美國：

另外走 APOL 的 cable 這邊也有類似的情況，可以看出導去美國了：

測了一下影片觀看速度，1.5x 可以看，2x 還是放不太動，的確是比以前好不少。

Dropbox 測試 BBRv2 的結果

BBRv1 有不少問題，在 BBRv2 有一些改善 (目前還在測試階段，在「TCP BBR v2 Alpha/Preview Release」這邊可以看到一些說明)，而 Dropbox 則是跳下去測試，並且公佈結果：「Evaluating BBRv2 on the Dropbox Edge Network」。

Spoiler alert: BBRv2 is slower than BBRv1 but that’s a good thing.

在文章開頭的這張圖就說明了 BBRv2 的速度比較慢，但是說明這是朝好的方向改善。

BBRv1 的問題其實我自己都有遇到：我自己的 Ubuntu 桌機跑 BBRv1，在我上傳大量資料的時候 (只開一條連線)，會導致 PPPoE 的 health check 失敗，於是就斷線了，另外 VM 裡面的 Windows 7 因為也是 bridge mode 跑 PPPoE，也可以看到斷線嘗試重連的訊息，於是只好改掉...

上面提到的問題就是 BBRv1 造成 packet loss 過高，除了我遇到的問題外，這對於其他 loss-based 的 TCP congestion algorithm 來說會有很大的傷害 (i.e. 不公平)：

Other tradeoffs were quite conceptual: BBRv1’s unfairness towards loss-based congestion controls (e.g. CUBIC, Compound), RTT-unfairness between BBRv1 flows, and (almost) total disregard for the packet loss:

另外一個改善是 BBRv2 加入了 ECN 機制，可以更清楚知道塞住的情況。

整體上來說應該會好不少，不知道之後正式釋出後會不會直接換掉 Linux Kernel 裡的 BBRv1，或是不換，讓 BBRv1 與 BBRv2 共存？

DNSFilter 使用 InfluxDB 與 TimescaleDB 的過程

DNSFilter 這篇講 InfluxDB 與 TimescaleDB 的文章頗有趣的：「Towards 3B time-series data points per day: Why DNSFilter replaced InfluxDB with TimescaleDB」。

在沒有實際用過之前，其實都只能算是一方之詞... 另外這種轉換其實也跟每個公司內的組織組成有關，像是熟悉 PostgreSQL 的單位就比較有機會用 TimescaleDB 解決 time series data 的問題。

不過有個地方倒是讓我想記錄起來：

Comparing TimescaleDB to InfluxDB at the same time — we realized we were losing data. InfluxDB relied on precisely timed execution of rollup commands to process the last X minutes of data into rollups. Combined with our series of rollups, we realized that some slow queries were causing us to lose data. The TimescaleDB data had 1–5% more entries! Also we no longer had to deal with cardinality issues, and could show our customers every last DNS request, even at a monthly rollup.

會掉資料等於是跟 InfluxDB 的使用者發出警訊，要大家確認自己手上的資料是否正確... 這對於正確性要求 100% 的應用就不是開玩笑了 @_@

Google Cloud Platform 的 DLP API

在「New ways to manage sensitive data with the Data Loss Prevention API」這邊提到三月的時候就推出了 DLP API (在「Discover and redact sensitive data with the Data Loss Prevention API」這邊提到的)，不過沒什麼印象：

The Data Loss Prevention (DLP) API, which went beta in March, can help you quickly find and protect over 50 types of sensitive data such as credit card numbers, names and national ID numbers.

這次看了一下範例，可以直接對圖片上面分析：

先記起來，看起來之後應該有機會用到？(像是分析使用者上傳的圖片)

Amazon S3 推出加速功能

Amazon S3 推出了新的加速功能，並且向更多地區提供 AWS Import/Export Snowball 服務：「AWS Storage Update – Amazon S3 Transfer Acceleration + Larger Snowballs in More Regions」。

其中的 Amazon S3 Transfer Acceleration 只要把本來的 BUCKET_NAME.s3.amazonaws.com 或是帶有地區的 BUCKET_NAME.s3-region.amazonaws.com 變成 BUCKET_NAME.s3-accelerate.amazonaws.com 就可以了，他會透過 CloudFront 的節點做 proxy，並且透過 AWS 內部最佳化過的網路傳輸。

由於這是定位為 Amazon S3 的服務，而實際測試後也確認不會有 cache：他的目的在於降低 latency 而加速，而不是 cache 加速，所以大量 GET 相同內容的部份應該還是用 CloudFront 會比較好。

再來是費用的部份增加相當多，第一筆要收的是 CloudFront 的費用，再來才是計算 Transfer Acceleration 的費用：

Transfer Acceleration pricing is in addition to Data Transfer pricing.

從 Internet 進 CloudFront 再進 Amazon S3 的要收 USD$0.04/GB (透過在美國、歐洲或是日本的 CloudFront 節點) 或 USD$0.08/GB (透過其他 CloudFront 節點)。

另外要收的是從 Amazon S3 一路傳到 Internet 的部份，USD$0.04/GB。如果是傳到其他 AWS region 的話，也是 USD$0.04/GB。

不過他有效能保證條款 (雖然掌控全不在自己)，AWS 會持續監控有沒有比較快，如果沒有的話系統會 bypass 回原來的 Amazon S3：

Each time you use Transfer Acceleration to upload an object, we will check whether Transfer Acceleration is likely to be faster than a regular Amazon S3 transfer. If we determine that Transfer Acceleration is not likely to be faster than a regular Amazon S3 transfer of the same object to the same destination AWS region, we will not charge for that use of Transfer Acceleration for that transfer, and may bypass the Transfer Acceleration system for that upload.

我本來以為會是在 DNS 層 bypass 回本來的 region，結果發現是 307 redirect 重導回 Amazon S3 上，效能上應該還是會差一些...

可以看出這個架構的特性主要還是用在上傳的部份，而且用在網路不穩定的環境下很重要 (像是電信網路上的行動裝置)，因為 latency 的減少會對於 packet loss 造成的 retry 有很大的幫助。

下載的部份應該會比本來 Amazon S3 快 (因為 Amazon 本身會加速)，但由於沒有 cache，除非有特殊需求，不然建議不要這樣規劃。

另外一個是 AWS Import/Export Snowball 推出的新硬體，以及新區域。

新硬體是 80TB 的版本，本來只有 50TB 的版本：

The original Snowball appliances had a capacity of 50 terabytes. Today we are launching a newer appliance with 80 terabytes of capacity.

而新區域包括了 AWS GovCloud (US)、US West (Northern California)、Europe (Ireland) 以及 Asia Pacific (Sydney) 這三區：

Today we are making Snowball available in four new Regions: AWS GovCloud (US), US West (Northern California), Europe (Ireland), and Asia Pacific (Sydney). We expect to make Snowball available in the remaining AWS Regions in the coming year.

其中 80TB 版本只在這三區生效，其他區可以選擇 50TB 或是 80TB 版本：

If you are transferring data in or out of the US East (Northern Virginia), US West (Oregon), US West (Northern California), or AWS GovCloud (US) Regions using Snowball you can choose the desired capacity. If you are transferring data in or out of the Europe (Ireland) or Asia Pacific (Sydney) Regions, you will use the 80 terabyte appliance.

日本還是沒進場...