杰哥的{教学,运维,编程,调板子}小笔记
替换自制服务器上的 48V 直流电源
背景
又到了新学期,计算机组成原理的实验又轰轰烈烈地开始了,但实验平台背后的 FPGA 集群,却出现了一台自制服务器不工作的问题,通过替换 48V 直流电源解决了。
自制服务器
说是服务器,但实际上,这个服务器是借用了机架式服务器的外壳,把里面改造成了一个 FPGA 集群。它通过一个电源把 220V 市电转成 48V 直流电源,然后给三个 10 口 PoE 交换机供电,然后每个 PoE 交换机再通过 PoE 给 8 个 FPGA 开发板供电。此外,再通过一个 48V 到 12V 的 DCDC 直流电源,给几个风扇供电。这样,一个自制服务器里,就可以承载 24 个 FPGA 开发板,再通过多个自制服务器组成 FPGA 集群。
交换机之间,采用菊花链的方式连接,最后连一根网线到机柜上的交换机。
问题定位
问题出在,其中一台自制服务器通电后没有反应。把自制服务器从机柜上拆下来,用万用表测试,最终的结论是:48V 电源坏了,输出的两个直流端子之间的电压为零,电源上的灯也没有亮。后续把电源拆出来看了看,没找到特别明显的出问题的部件。
修复
修复也很简单:找到了一个同型号的备用电源,一通拆卸,再按照原来的方式装回来就可以。由于这个 48V 电源的输出就是两个带有螺丝的端子,所以要把各路电源(三个交换机、一路 DCDC)的电源线的正和负分别压紧到对应的端子上,防止虚接发热。
source
替换自制服务器上的 48V 直流电源
背景
又到了新学期,计算机组成原理的实验又轰轰烈烈地开始了,但实验平台背后的 FPGA 集群,却出现了一台自制服务器不工作的问题,通过替换 48V 直流电源解决了。
自制服务器
说是服务器,但实际上,这个服务器是借用了机架式服务器的外壳,把里面改造成了一个 FPGA 集群。它通过一个电源把 220V 市电转成 48V 直流电源,然后给三个 10 口 PoE 交换机供电,然后每个 PoE 交换机再通过 PoE 给 8 个 FPGA 开发板供电。此外,再通过一个 48V 到 12V 的 DCDC 直流电源,给几个风扇供电。这样,一个自制服务器里,就可以承载 24 个 FPGA 开发板,再通过多个自制服务器组成 FPGA 集群。
交换机之间,采用菊花链的方式连接,最后连一根网线到机柜上的交换机。
问题定位
问题出在,其中一台自制服务器通电后没有反应。把自制服务器从机柜上拆下来,用万用表测试,最终的结论是:48V 电源坏了,输出的两个直流端子之间的电压为零,电源上的灯也没有亮。后续把电源拆出来看了看,没找到特别明显的出问题的部件。
修复
修复也很简单:找到了一个同型号的备用电源,一通拆卸,再按照原来的方式装回来就可以。由于这个 48V 电源的输出就是两个带有螺丝的端子,所以要把各路电源(三个交换机、一路 DCDC)的电源线的正和负分别压紧到对应的端子上,防止虚接发热。
source
Chips and Cheese
NVIDIA’s Olympus Core: Pushing Server Single Threaded Performance Boundaries
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
NVIDIA’s Olympus Core: Pushing Server Single Threaded Performance Boundaries
#ChipAndCheese
Telegraph | source
(author: Chester Lam)
Page table memory consumption
https://frn.sh/pagetables/
https://frn.sh/pagetables/
Optimizing GEMM on Apple's M5 from Scratch
https://lenguyen.vercel.app/note/metal-gemm-1
https://lenguyen.vercel.app/note/metal-gemm-1
杰哥的{教学,运维,编程,调板子}小笔记
把博客生成器从 Mkdocs 迁移到 Zensical
距离上一次 从 Mkdocs 迁移到 Zensical 已经过去了三年,这次 Zensical 终于是补齐了原来 Mkdocs 用到的大部分插件,所以就当小白鼠,把博客从 Mkdocs + Mkdocs-Material 迁移到了 Zensical。
这次迁移的背景,就是 Mkdocs-Material 团队对 Mkdocs 后续的更新计划不满,自己独立出来,RIIR 了一个尽量兼容 Mkdocs 生态的 Zensical。当然这个兼容不是 100% 的,所以我也在逐渐地做一些替换,从 ctf-writeups 开始,到 cpu,再到博客主站,未来等 i18n 插件到位了,再迁移 kb 等等。其实用起来也没啥区别,连配置文件都不用改,然后就是构建速度确实快了很多,之前 mkdocs build 一次要好几十秒,zensical 明显更快。插件方面,我也自己移植了一个 zensical-wavedrom-plugin用来渲染 wavedrom 波形图。
回顾历史,本博客已经做了好几次迁移:
● 2019 年,从 Jekyll 到 Hugo
● 2023 年,从 Hugo 到 Mkdocs
● 现在 2026 年,从 Mkdocs 到 Zensical
迁移的基本动力,要么是原来的生成器太慢了,要么就是有一些硬伤。不知道几年后,会不会再迁移到新的技术栈呢。
source
把博客生成器从 Mkdocs 迁移到 Zensical
距离上一次 从 Mkdocs 迁移到 Zensical 已经过去了三年,这次 Zensical 终于是补齐了原来 Mkdocs 用到的大部分插件,所以就当小白鼠,把博客从 Mkdocs + Mkdocs-Material 迁移到了 Zensical。
这次迁移的背景,就是 Mkdocs-Material 团队对 Mkdocs 后续的更新计划不满,自己独立出来,RIIR 了一个尽量兼容 Mkdocs 生态的 Zensical。当然这个兼容不是 100% 的,所以我也在逐渐地做一些替换,从 ctf-writeups 开始,到 cpu,再到博客主站,未来等 i18n 插件到位了,再迁移 kb 等等。其实用起来也没啥区别,连配置文件都不用改,然后就是构建速度确实快了很多,之前 mkdocs build 一次要好几十秒,zensical 明显更快。插件方面,我也自己移植了一个 zensical-wavedrom-plugin用来渲染 wavedrom 波形图。
回顾历史,本博客已经做了好几次迁移:
● 2019 年,从 Jekyll 到 Hugo
● 2023 年,从 Hugo 到 Mkdocs
● 现在 2026 年,从 Mkdocs 到 Zensical
迁移的基本动力,要么是原来的生成器太慢了,要么就是有一些硬伤。不知道几年后,会不会再迁移到新的技术栈呢。
source