V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  kennylam777  ›  全部回复第 33 页 / 共 47 页
回复总数  929
1 ... 29  30  31  32  33  34  35  36  37  38 ... 47  
2018-04-27 06:02:49 +08:00
回复了 lloovve 创建的主题 Linux 来说说你们在生产环境开启 BBR
生產環境開 +1

因為伺服器是向全世界的用戶服務的, 不單面對國內, 跨洲 Internet 在高 latency 下的提升效果明顯, 速度是重要的。而且沒影響內網(一直有監測 latency 及 throughput)。對於不用面向客戶端的運維人員, 開 BBR 也是要額外工作吧, 反正自己用不著。

說內網開會浪費資源的, 純粹是對 BBR 不了解, 它畢竟是進入了 Linux kernel 的 Fair Congestion control, 不是像 KCP 一類的的進取兼不公平的搶佔。

而且最後一哩和國內骨幹網的質量完全不是可以比較的, 單是在商廈一類 WiFi 干擾嚴重的場境下, packet loss 情況影響更大, 這時 BBR 才會見到有效。我個人很喜歡用有線網絡, 但也很清楚一般用戶是以 WiFi 為主的。


@Love4Taylor 不影響的, NAT 的動作只是修一下 packet 的 address field, 不管 Congestion control
2018-04-26 14:52:00 +08:00
回复了 leopard080264 创建的主题 宽带症候群 中国电信开通香港交换中心 hkix 线路
@237176253 3ms 那種港深專線, 不用佔用 Internet 容量的, 放心吧......世界加錢可及
2018-04-25 22:12:00 +08:00
回复了 aocif23 创建的主题 问与答 ffmpeg 切割视频不准确,被-1s
FFMpeg 對 seeking 準確度的解說

https://trac.ffmpeg.org/wiki/Seeking
As of FFmpeg 2.1, when transcoding with ffmpeg (i.e. not just stream copying), -ss is now also "frame-accurate" even when used as an input option. Previous behavior (seeking only to the nearest preceding keyframe, even if not precisely accurate) can be restored with the -noaccurate_seek option.

要精確的話必需要重編碼沒錯, 但切片的動作可以分成這樣

第一輪先切成 raw video+raw audio 減少損耗, 精準 seeking 的話(-ss 放-i 前)就不會卡
然後第二輪用 concat 重編

我用 ffmpeg 來生成分段預覽, 因為不要求 frame-accurate, 就用 fast seeking(-ss 放-i 後)先以(T+K)切一段出來, T 是𢬒定時間, K 是 keyframe 時間, 第一輪先快速切片, 在第二輪壓制前把每個分片開始的 K 長度剪走, 這就能解決卡頓問題
2018-04-25 22:01:00 +08:00
回复了 XinLake 创建的主题 Android Android 4K 硬件解码 CPU 占用,专业的 APP 不耗电
LibVLC 也是用的 Android MediaCodec API, 說白了就只是個 wrapper 還要經 JNI 繞路到 MediaCodec, 而且不知道跟 CV 有甚麼關係, 就 framebuffer 可以接上而已。

這種接 open source libraries 的技能是有用沒錯, 但....你這種 demo 令我想起一個來見工的, 滿手好看的 demo, 但 OpenCV 就只是抄 demo 畫了一些標點出來, 問到該算法的特點也不上來, 卻說成自己發現似的。
2018-04-25 20:25:57 +08:00
回复了 leopard080264 创建的主题 宽带症候群 中国电信开通香港交换中心 hkix 线路
@wangxiyi077 你的解讀是正確的, 不說 DWDM 是因為整段光纜中的分配情況不好說, 反正出口頻寬是按端口計算的

信道 是我國 《计算机信息网络国际联网出入口信道管理办法》的用詞, 但我的說法應該是改成「端口」比較好
2018-04-25 09:05:06 +08:00
回复了 zhangyuting 创建的主题 宽带症候群 家里房间较多,如何很好的实现全家 wifi 无缝覆盖
Ubnt Inwall 系列 +1
正在用, 三個 GbE 口超級好用, 還有 PoE In/Out 可以廷接到下一個 AP, 裝修時可以少煩心 switch 放哪裡
規劃也容易, 直接讓師傳用多裝一組電線的工法就可以做到多點 AP 用網線相連
2018-04-25 08:43:12 +08:00
回复了 leopard080264 创建的主题 宽带症候群 中国电信开通香港交换中心 hkix 线路
@237176253 才不會炸掉, 那點流量......

就當有一天 163 ChinaNet 突然改死性在 HKIX 弄 Public peering 好了。

總出口只有 3.6Tbps 的電信還不會 100%配到香港去, 看 CN2 才 10G, 更不能賺錢的 ChinaNet 能分到多少? 用最新的工藝開通 100Gx2 的信道也才 200Gbps 流量, 對於流量峰值已經超過 1Tbps 的 HKIX 還不算很嚴重。一次過接入 400Gx2 的話才要擔心, 不是交換中心跟不上, 而是亞洲區內接到 HKIX 的 ISP 線路容量不足。

然後更大的問題是: 對接香港的廣州國際局, 分配給電信的「安全裝置」容量追不上......
2018-04-24 05:32:30 +08:00
回复了 EIlenZe 创建的主题 日本 去日本旅行,怎么解决网的问题呢。
Japan Welcome SIM + 1, 最老實的因為是 NTT Docomo 自營, 價錢也不算貴, 而且免設定

很多所謂 NTT Docomo 網絡的 SIM 卡要加 APN(PAP 帶 username/password)的那種就不能用了, 只是買了很少出口頻寬 MVNO, 垃圾。

反而租用 U-roaming (Softbank 網絡)的 WiFi 還行, 今年去了日本兩次, 因為滑雪場算是遍遠地區, 住宿的 WiFi 都不太好, 兩個人幾台機要靠 4G WiFi, 兩次也用了接近 10GB 還沒遇到限速, MVNO SIM 卡的話早就限成 512kbps 或以下。

我們用 Japan Welcome SIM 方便分開行動時的聯絡, 一起時就共用 4G WiFi。
我是把家裡的 Subnets(LAN + VPN)都遠離 192.168.0.0/192.168.1.1, 考慮到經常用 VPN 連回去, 而外面很多一般路由器預設分配 192.168.0.0/24 及 192.168.1.0/24 為主, 避開了就好

已經有 3 點 LAN 之間的 site-to-site 互連, 還有 virtualization 的分隔, 但還是用不完 192.168.0.0/16
@imrei 我搞了電信+移動, 最後在 pfSense 的 firewall 順序是這樣

AS9808 -> 移動
AS9394-> 移動
chnroutes -> 電信
剩下的 -> VPN
@Danswerme 問題反一下, 把中國的路由表收集起來就可以了

https://github.com/fivesheep/chnroutes

chnroutes 的路由表, 用 iproute2 (ip route add) batch mode, 在一般的 LEDE 上五秒內完成。

還是嫌多就用 bestrouteb
https://github.com/ashi009/bestroutetb
一樓答案 +1

而且 WiFi 的情況比家寬好, 不會長期佔用 IP
2018-04-16 18:34:33 +08:00
回复了 whereabouts 创建的主题 宽带症候群 推荐个低价位爱折腾的机顶盒设备/方案?
我用 Intel n3150 (x86)的 NUC,裝 LibreELEC 的 Kodi, 再配個 Docker plugin, 進 linux shell 甚麼 Linux 的東西都能跑起來, 但價錢沒這麼便宜, 好處是 LibreELEC 很穩定, x86 build 長期有支持, 不像機頂盒般有各色小問題而要自己找方法解決。

上面說的都是 AMLogic S912 方案, 好像有 LibreELEC 的 rom 可以安裝, 但要配 docker 的話不知道有否這麼簡單了
2018-04-15 20:57:34 +08:00
回复了 yexm0 创建的主题 宽带症候群 恭喜中国电信加入 HKIX 大家庭
@hlz0812 HKIX 是要交錢沒錯,但價錢一定比 Private peering/Transit 的低
價錢表是公開的: http://www.hkix.net/hkix/Charge/ChargeTable.htm
比任何一間 ISP 都要便宜吧?

當然沒免費的划算,但問題是有免費的嗎? HKIX 只收取基本的設備維持費用,開始的時候更是免費的,任何人接進去只要負責專線及路由設備的費用,到現在改成了自負盈虧也只按收費表計價。接入方法可以是跟 FTSN 租光訊道,也可以租 Layer 2 通道接進去。

其實 CN2 這麼久才直連 HKIX,要不是需求不大,就是以前成本沒在管都依賴 Peering 穿到 HKIX 去。
樓主都調好了優先序, 路由表就不用 delete route 再 add default route 了, 直接把公司內網的 IP 段指到 LAN gateway 去, 路由表的規則是小 subnet 比大 subnet 甚至 default route 都要優先
2018-04-09 15:54:50 +08:00
回复了 yexm0 创建的主题 宽带症候群 恭喜中国电信加入 HKIX 大家庭
@akw2312 我以為你在罵 ChinaNet 及 169....CMCC 在 HKIX 的 route 挺多的吧,但絕大部分是自己 AS 的,transit 的沒研究
2018-04-09 10:52:35 +08:00
回复了 yexm0 创建的主题 宽带症候群 恭喜中国电信加入 HKIX 大家庭
先觀看吧, participant list 上還沒有 AS4809, 也沒有公告說 AS4809 接到 HKIX, 應該沒準備好
http://www.hkix.net/hkix/participant.htm

現時 AS4809 (CN2) 接入 HKIX 還是主要經過 AS9304(HGC)/AS4637(Telstra Global)來 transit
https://www.hkix.net/hkix/hkixlg.htm


不過, 123.255.91.150 的 rDNS 是 chinatelecomglobal1-10g.hkix.net , 這顯示了應該會用 CTG 的名義接 HKIX 吧, 但 rDNS 沒有 lacp, 也沒有 chinatelecomglobal2-10g.hkix.net , 看來就只有 10G 的容量, 應該不會像 AS58453(CMI 移動國際) 般有 100G 容量+發佈幾乎完整的 BGP table 了
2018-04-06 17:31:47 +08:00
回复了 liuxin5959 创建的主题 程序员 常年写 JS,怎样适应 Java ?
@v2dead 如果是外部不確定的來源, 做一個非完整的 sturct 就好, 只為需要的(needed)及已知的(known)的地方寫 fields, 像 jackson 般就是可以把沒定義的 fields 全放在 map 之中, 兩者兼顧到

如果整天接到的 json 都是亂來的, 也就認了
2018-04-06 17:11:03 +08:00
回复了 liuxin5959 创建的主题 程序员 常年写 JS,怎样适应 Java ?
@orangeade
對我來說, 只要有封裝的都是可行的設計方法, 我還有用 Golang 呢, 近來在練 Kotlin
2018-04-06 16:41:52 +08:00
回复了 liuxin5959 创建的主题 程序员 常年写 JS,怎样适应 Java ?
拿 23 樓那種超長的例子來說, 如果只是有一天 web-app.servlet.servlet-name 改成了 web-app.servlet.servlet-id

如果有結構封裝, 要改代碼的話, 就把封裝 json 結構的 class 找出來改掉
class servlet{
String servlet-name;
}

直接用 IDE 的 refactor 改成新的 field 名字, 這樣引到用這 field 的地方都會自動改掉, 引用 1 次還是 100 次都沒差
class servlet{
String servlet-id;
}

沒有封裝的話, 如果用 Json["web-app"]["servlet"]["servlet-name"] 的, 嗯, 你們就慢慢手動的 search,再看看是否相關, 然後才 replace......這種 code 你自己用得開心就好, 不要留下來了
1 ... 29  30  31  32  33  34  35  36  37  38 ... 47  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   973 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 22:26 · PVG 06:26 · LAX 15:26 · JFK 18:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.