Home » Posts tagged "time" (Page 2)

TP-Link 的 NTP 流量

在「TP-Link repeater firmware squanders 715 MB/month」這邊看到 TP-Link 因為 NTP 的關係而狂吃流量的情況:(這邊是用逗點表示小數點,所以是 715.4 MB/month)

You should probably avoid TP-Link products if you’re on a tight bandwidth budget. By design, TP-Link firmware sends six DNS requests and one NTP query every 5 seconds, for a total of 715,4 MB per month.

如果拿 24 小時都開機的 Windows 相比的話,會發現這數字天差地別:

To put this number in context: an always-on Windows device will use around 1,6 KB per month on NTP.

作者抓出韌體上面的設定,發現裡面寫死了不少伺服器... 那個 aunz 的選擇讓人頗好奇,另外直接把幾個大學的 NTP server 放進去不知道是什麼樣的想法:

TP-Link has hardcoded the following non-configurable NTP servers and server pools in their firmware:

  • time.nist.gov, time-a.nist.gov, time-b.nist.gov, time-nw.nist.gov
  • au.pool.ntp.org, nz.pool.ntp.org
  • 133.100.9.2, 128.138.140.44, 192.36.144.22

The first sets of servers are operated by the US National Institute of Standards and Technology (NIST). The second is the Australian and New Zealand public NTP project time server pools. The IP addresses are owned by universities in Japan, Colorado; US, and Sweden respectively.

而從行為可以看到沒有遵守這些 NTP service 的規範:

The NTP Pool project asks device manufacturers and vendors to register (and optionally sponsor) their own pools through the service (e.g. tplink.pool.ntp.org), and emphasize that they “must absolutely not use the default pool.ntp.org zone names”. They also request that vendors don’t check more often than every 5 minutes at the most.

而且因為沒有地方可以修改這些設定,唯一的解法是不要買 TP-Link 的產品:

You can avoid buying TP-Link products to avoid this problem.

You can’t turn this behavior off in TP-Link’s web administration interface nor in their management app for mobile. You can’t change the NTP server addresses it targets either.

Amazon CloudWatch 支援縮放與拖拉調整時間區間

Amazon CloudWatch 的操作上支援 Zoom 與 Pan 了:「Amazon CloudWatch now supports two new chart visualization options in metrics and dashboards」。

Zoom 是改變時間的粒度:

You can use the CloudWatch console to graph metric data generated by AWS services and your applications. Now, you can zoom into a shorter time period such as one minute or five minutes while viewing the metric graph at a longer interval.

Pan 則是維持一樣的粒度,但改變開始與結束的時間:

Once zoomed, you can also pan the metric graph across your selected interval, but at a zoomed detail level.

變得更容易操作,而不用滑鼠移過去修改...

英文母語的人學習外語所需的時間

這個報導蠻有趣的:「A Map Showing How Much Time It Takes to Learn Foreign Languages: From Easiest to Hardest」。

文章裡分成這幾種:(扣除已經是母語的英語,Category 0)

  • Category I: 23-24 weeks (575-600 hours) Languages closely related to English
  • Category II: 30 weeks (750 hours) Languages similar to English
  • Category III: 36 weeks (900 hours) Languages with linguistic and/or cultural differences from English
  • Category IV: 44 weeks (1100 hours) Languages with significant linguistic and/or cultural differences from English
  • Category V: 88 weeks (2200 hours) Languages which are exceptionally difficult for native English speakers

其中時間最長的這部份引用一下:

Arabic
Cantonese (Chinese)
Mandarin (Chinese)
*Japanese
Korean
* Usually more difficult than other languages in the same category.

AWS 環境裡面提供 NTP Service 了 (Amazon Time Sync Service)

以前在 AWS 環境裡都要自己架設兩台可以連外的 NTP server,然後將內部機器指到這兩台上,現在可以用現成的了:「Keeping Time With Amazon Time Sync Service」。

服務放在 169.254.169.123

You can access the service via the link local 169.254.169.123 IP address. This means you don’t need to configure external internet access and the service can be securely accessed from within your private subnets.

然後也有提到 leap second 的解法,用的解法是 leap smearing:

Leap seconds are known to cause application errors and this can be a concern for many savvy developers and systems administrators. The 169.254.169.123 clock smooths out leap seconds some period of time (commonly called leap smearing) which makes it easy for your applications to deal with leap seconds.

先前 AWS 也有 leap time,但不包括 Amazon EC2 這些系統 (EC2 裡的時間是獨立的),不過還是可以看一下 AWS 處理 leap time 的方式,因為這次 NTP Service 就會拿去用了。

最近一次 leap time 是 2016 年底的「Look Before You Leap – December 31, 2016 Leap Second on AWS」,處理的方式跟 2015 年時的方法還是一樣:「Look Before You Leap – The Coming Leap Second and AWS (Updated)」。

類似於下圖左上角這張的變化:

然後全區開放,都可以用了:

This service is provided at no additional charge and is immediately available in all public AWS regions to all instances running in a VPC.

Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗):

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明,其他頁面都還是跑 React,只有 Landing Page 被改寫,看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI,所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的):因為之前 React 的專利問題,變成之後 Facebook 如果真的出手提出告訴,會以惡意侵權來告 (因為鬧這麼大以後,沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗),後續再換內頁...

Facebook 在 MySQL 裡存時間的型態

MySQL at Facebook這邊說明提到了,Facebook 內部是使用 INT UNSIGNED 儲存時間:

Which gets us to the point that it is no different than storing INT (hello 2038?) or UNSIGNED INT (a bit later) or BIGINT (till the end of time) and possibly passing binary values in efficient protocols eventually.

If you got that far of this post, your likes in Facebook graph are stored with 'INT UNSIGNED' time field.

順道一提,INT 是 2038 年問題,INT UNSIGNED 是 2106 年問題。

而 Facebook 在 MySQL 上會選擇不使用 DATETIMETIMESTAMP 的原因其實跟技術搭不上太多關係,主因是因為 MySQL 根本沒打算修 XDDD

It is my favorite MySQL bug, simply because it forces any reasonable mind not to use TIMESTAMP, and MySQL is never going to fix it (nor will ever understand time). I lost my temper a bit on that bug: https://bugs.mysql.com/bug.php?id=38455

我的猜測是已經爛成一團了,而且大家都有 workaround (呃,其實就是 Facebook 推薦用 INT UNSIGNED 的方法),再考慮到有一票現有程式,在上面狂用 side effect 讓執行結果正確,不如就不要修這種吃力不討好的東西了 XDDD

另外一方面 timezone 資訊其實常常變化,常常需要更新 MySQL 的 timezone database (而這對於維運來說不是什麼開心的事情):

There're few ways around that. One of them is side-load and maintain timezone data inside MySQL itself - it has support for internal timezone database and tracks obscure time shifts like ones for "Pacific War Time" and "Pacific Peace Time". That is operationally feasible (you have to remind yourself to update the database whenever time rules change, and they do change a lot, if you consider every timezone in the world), but has limited value.

這就是為什麼大家遇到 MySQL 時都會推薦用 INT UNSIGNED 了...

另外可以參考三年前的文章「MySQL 裡儲存時間的方式...」,裡面引用了 Baron Schwartz 的說明:

All date and time columns shall be INT UNSIGNED NOT NULL, and shall store a Unix timestamp in UTC.

其實這已經是個 best practice 了...

除了 DNS 的 TTL 外,還有瀏覽器本身的 cache time...

在看「Reviewing Fastly’s New Approach To Load Balancing In The Cloud」這篇的時候被提醒:

However, most browsers have implemented their own caching layer that can override the TTL specified by the server. In fact, some browsers cache for 5-10 minutes, which is an eternity when a region or data center fails and you need to route end users to a different location.

我印象中沒那麼長,但也記不起來多長,所以查了一下...

結果 IE 在「How Internet Explorer uses the cache for DNS host entries」直接說三十分鐘 XDDD 這篇文章是 2011 年更新的,所以至少到 IE9 都是對的?

Internet Explorer 4.x and later versions modify how DNS host entries are cached by decreasing the default time-out value to 30 minutes.

Firefox 的值可以從 Mozilla networking preferences 這邊對 network.dnsCacheExpiration 的說明看到是 60 秒。

Google Chrome 沒找到官方的說明...

不過這可以知道當你要換 IP address 時,如果可以讓新舊 IP 都提供服務的話,至少規劃半個小時會比較保險。如果有其他理由而沒辦法同時提供服務的話,至少公告步驟裡要有「重開瀏覽器」這塊。

而作業系統自己的 cache 又是另外要計算進去的事了...

Amazon ECS 可以跑 cron job 了...

Amazon ECS 上面固定時間跑某些東西,以前得自己用 AWS Lambda 帶 (或是自己架,不過這樣就要自己考慮 High Availability 架構了),現在則是直接支援:「Amazon ECS Now Supports Time and Event-Based Task Scheduling」。

Previously, you could start and stop Amazon ECS tasks manually, but running tasks on a schedule required writing and integrating an external scheduler with the Amazon ECS API.

Now you can schedule tasks through the Amazon ECS console on fixed time intervals (e.g.: number of minutes, hours, or days). Additionally, you can now set Amazon ECS as a CloudWatch Events target, allowing you to launch tasks by using CloudWatch Events.

微軟的 Time Service 回應錯誤的時間...

看起來會有不少災情 (像是 SQL Server 遇到使用 server side 的時間的 SQL query):「Windows Time Service is sending out wrong times and that’s a big problem」,報導裡引用了 Reddit 上「PSA: time.windows.com NTP server seems to be sending out wrong time」這邊的討論串。

為了避免這種情況,不同單位會用不同方法解決。像是財力充足的 Google 就自己搞了原子鐘,然後還放 Google Public NTP 出來給大家用。可以不倚靠外部裝置確保自家時間的正確性。

另外是有人用 Raspberry Pi 收 GPS 訊號轉成 NTP service (像是「The Raspberry Pi as a Stratum-1 NTP Server」這邊介紹的方式),不過之前有發生過 GPS 送出來的時間差了 13ms 的事情,也不是完全可靠 (不過相較起來應該還是可以接受):「GPS error caused '12 hours of problems' for companies」。另外可能的方案有 GLONASS (俄羅斯的系統)。

也許之後有機會會需要自己架...

Archives