Skip to main content

acshame

  1. OpenAI 终于出了个详细的说明,
    关于何时使用哪个模型↓

    1. GPT-4o -用于日常工作流程中的实时、多模态推理的比较全面的模型。

    2. GPT-4.5——更广泛的知识和更好的语气控制——非常适合写作、编码和快速解决问题。

    3. o4-mini -快速、经济高效的代码、数学和视觉任务推理。

    4. o4-mini-high - 比 ​​​https://mapp.api.weibo.cn/fx/5438ce3955e394ff8553e0312c5a7afc.html
  2. 前天和超级大鹅 @SUPER_GOOSE0 (who 写过一篇极好的 mtu 文章 https://www.kawabangga.com/posts/4983) 又一次讨论 mtu,我这两天也间歇性做了一些学习

    1. 现代 Linux 早就把 MSS 和 GSO 绑定了。不知道大家纸面上学习 mss 的时候是怎么想的,我的古早理解是 tcp socket 发出的 skb 总是小于等于 mss,这在 2.4 的时候确实如此实现,但是在 2.6 引入 GSO 之后 mss 分片被极大推迟,就算 mss 是 1400,一个 skb 依然可以把 4k 的 payload 塞入非线性区 (struct skb_shared_info*)(skb->head+skb->end),然后在“最终时刻”再分。

    2. “最终时刻”往往比大家想象中的还要晚。考虑云原神环境里的 pod to pod via vxlan tunnel,设置 pod mtu 需要减去隧道包头已是常识,那么 MSS 分段和 IP 分包会发生在什么时候呢?在我本地 ubuntu 2404 默认情况下,最终时刻发生在在 vxlan 隧道封包之后,处理完 nf POSTROUTING 之后,eth0 dev_xmit 之前,先做 MSS 分段,如果分段成后长度 > eth0 mtu,再做 IP 分包。

    3. 因此用 ping -s 1500 / ping -M do -s 1500 做 mtu 连通性测试的意义不明,MSS 分段和 ICMP 分包实现如此不同,ping 的连通性和分包状态无法推断出 tcp 发同样大小 payload 的连通性和分包状态。

    这些破细节不能指望任何人通过看书学会,就连那本经典的《TCP/IP详解》也远落后于时代,成书于 1994,十年后的 GSO 才成为 MSS 底层逻辑。“我们需要一本现代的、符合时代精神的《TCP/IP详解》”,我看着超级大鹅的眼睛说。