V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  cs8425  ›  全部回复第 4 页 / 共 7 页
回复总数  131
1  2  3  4  5  6  7  
2021 年 1 月 31 日
回复了 blueboyggh 创建的主题 问与答 能做 Linux 服务器的最小发行版是啥?
@blueboyggh 这个问题是虚拟磁盘造成的
关键字 vhd shrink 试试
2021 年 1 月 24 日
回复了 Osk 创建的主题 分享发现 旧闻:树莓派出新产品了 -- 树莓派 pico
接 #5
换句话说
定位应该是偏向初学者入门
而非专业开发了
2021 年 1 月 24 日
回复了 Osk 创建的主题 分享发现 旧闻:树莓派出新产品了 -- 树莓派 pico
有点神奇的设计 /定位
M0+给双核&频率冲到 133MHz
SDK 有看到硬体除法
不负责任猜测
双核是为了 MicroPython 、NodeMCU 这类的 interpreter 调整的
一些时序敏感的任务可以丢在另一个核心执行
2020 年 12 月 30 日
回复了 M1hahahaha 创建的主题 MacBook Pro 请 macbook pro M1, 8G 的兄弟回复一下
@M1hahahaha #31
兄弟 你心中都有不可质疑的答案了... 还发帖问做啥...

断电伤硬盘跟频繁 swap 伤硬盘是完全不同的概念
你怎会拿来类比...
人都会死 老死 病死 出意外死 很多种
你能说没生过病所以不会死?

还有直接按电源关机不等于"切"电源强制关机
除非你还在用 win2000 、win98...
2020 年 12 月 27 日
回复了 Devin 创建的主题 Android 安卓手机是否可以作为一台 Linux 主机使用?
喜欢折腾的话还行
有 root 比较方便
需要动到内核的通常都不能用
设定开机自启动服务比较麻烦
可能有些坑要自己想法解决
之前有 node.js 的磁碟 IO 巨慢的问题
不知修正没
所以我后来只拿来跑 go 写的小东西(简单的 web, 远端操作手机)
很久以前做过一个自用的小档案保存平台, 全部直接入库 mysql, 不过那些档案最大不超过 100kB
后果嘛... 除了后来要翻资料比较麻烦外, 其实也没啥后果, 吃灰还能怎样...

如果需求是:
1. 减少空间占用
2. 不依靠外部服务
3. 存放档案数量少, 方便备份
那我会选择 index+单一大档
一个档案(sql 啥的都好)存放偏移,长度,(UUID/档名)
另一个大档案直接 append 要存的内容(要不要加密处理随你高兴)
取出要取出某个档案就去 index 找出偏移跟长度
再从那个大档里面拉出来就好
备份就更简单了
index 档+单一大档
没了...


@debuggerx #49, @0bit #59: 赞同你们的说法, 就是视野限制又铁头, 当作回给其他路过得人参考搂...
2020 年 10 月 25 日
回复了 testcaoy7 创建的主题 硬件 关于超微型主机(电脑棒)的选择
先看内存多少吧
不少还在 2G 4G
储存再大也是卡的怀疑人生...
2020 年 9 月 4 日
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
@gantleman #61
先不题游戏(尤其是技能造成)的复杂度没你想的那么简单
光你这算法就能得证"毫秒级"是不够的
不知道您是否真的有去算过?
1 秒 /8640 次 ~= 0.116 毫秒 /次 (~0.116 ms/req)
也就是一次请求要在 116 微秒内完成
已经是"微秒级"了
再加上还有计算要做
"毫秒级"是肯定不够的
我还是不懂为啥你一直认为 "redis 性能" 可以直接跟 "内存操作"放在同一个等级....
2020 年 9 月 3 日
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
@gantleman #57
老兄 你好像没搞清楚我想表达的点?
我只想说你#52 讲的
"redis 的异步读写每秒可以支持 10 万次,操作都是按毫秒级,技能释放是用户按秒级别的计算。redis 操作再慢还能比用户的操作还慢?为什么你把完全不同量级的东西都能搅和在一起说。"
这点有个的错误: redis 毫秒级对于 PvP 游戏是不够用的
一点都没提到"12 人 PvP 游戏有硬件不够用的问题"
麻烦您再看清楚一点...

10ms 跑完哪些东西, 这个部份其实 @dogfeet #50 就有点出来了啊
不是我想杠 只是觉得您好像只看关键字...

可能我叙述不太清楚
另外再补充一下,
我弄的这个 PvP(老)游戏,
属于 TPS 射击对战
您可以想成 OW 的 TPS 版, 但是技能、攻击判定更复杂...
根据手上的资料,
用户操作最慢也是 0.5 秒一次, 众数在 200~250ms 之间, 顶尖的大概是在 100ms 上下
若把攻击判定算进来, 100ms 5 次都不是不可能
跟您所谓的"秒级"差异蛮大的....
2020 年 9 月 3 日
回复了 gantleman 创建的主题 推广 3D 游戏的万人同屏技术详解(2)
@gantleman #52
抱歉啊老兄 看了你这回覆我反而觉得是你没写过 PvP 游戏伺服器...
毫秒级很厉害吗?
现在一堆游戏伺服 game tick 随便都是 60 100Hz
至少都要微秒甚至奈秒及才够用
拿极端点的 100Hz 说,
10ms 就要跑完所有计算
请问您的"毫秒级"是能跑几次?
反而是 @dogfeet #48 #50 #51 的叙述比较正确
ps.个人写过最高 12 人的 PvP 游戏 可以肯定都是直接对内存做计算&操作
2020 年 5 月 25 日
回复了 MaxJin 创建的主题 问与答 U3D 和 webGL 的比较
U3D 是指 Unity3D?
两个差异很大呢...
WebGL 只有绘图部份, 要比的话也应该跟 OpenGL 跟 Direct3D 比较才对
Unity3D 是游戏引擎, 除了绘图部份还有物理引擎等等的其他库(印象有网页版输出, 底层也是用 WebGL 绘制)
自己撸一个不困难啊
私钥签名一个到期日
公钥放程序内检查到期日+签名
就只怕检查的动作被 bypass 掉
2019 年 5 月 12 日
回复了 a74074011 创建的主题 Android 请教下 MTK 的充电电源控制 current_cmd
https://android.googlesource.com/kernel/mediatek/+/refs/heads/android-mediatek-sprout-3.10-marshmallow-mr1/drivers/power/mediatek/battery_common.c#3484
照这个源码来看
应该只有"0 0" "0 1" "1 0" "1 1"四种输入
前面那位设定充电电流要不要限制
后面那位设定要不要充电
所以不充电应该是"x 1"
充电应该是"x 0"
x 为 0 或 1 任意
@ZoomQuiet #4
来晚了....
不过 @jessynt #1 的方法是可行的
很久之前就做过好几个类似的
整理一下放出来给你参考: https://github.com/cs8425/ffmpeg-ws-relay
透过 websocket 连续传送单个 jpg 或是 png 格式的 frame
只要在里面加一段把每个 frame 写到档案去的程式
要降 fps 也只要修改一下几个 frame 再广播一个即可
2019 年 3 月 30 日
回复了 cs8425 创建的主题 分享创造 kcptunB, 解决存在已久的卡死问题
@noli #10 #12
刚刚去装了台 VM 测试
如果`net.inet.tcp.fastopen.server_enable`设为 0 是有错误讯息没错
但是仍可以正常连线
无法复现不能连线的状况, 请提供更详细的资讯
版本: FreeBSD freebsd 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64
`s.lock == true`
你这个操作不是 atomic, 也没有上锁
在 golang, 每个 http request 是一个 goroutine, 是能并发的
有机会同时进入`time.Sleep(60 * time.Second)`这行
当然会造成 9 个卡住又同时完成
2019 年 3 月 24 日
回复了 cs8425 创建的主题 分享创造 kcptunB, 解决存在已久的卡死问题
@sobigfish #8
暂时不能, 等您提交 golang cross compile for iOS 的 PR
2019 年 3 月 23 日
回复了 cs8425 创建的主题 分享创造 kcptunB, 解决存在已久的卡死问题
@noli #6
依样画葫芦, json 设定跟 cli 选项名称一样, 加上`"ser": "socks5",`就好
2019 年 3 月 23 日
回复了 cs8425 创建的主题 分享创造 kcptunB, 解决存在已久的卡死问题
@noli #3
兼容, 不过建议把`--keepalive`换成`--keepalivems`
其他比较可能会用到的参数为: `--keepalive-timeout`, `--streambuf`, `--ser`, `--dns`
2019 年 3 月 23 日
回复了 cs8425 创建的主题 分享创造 kcptunB, 解决存在已久的卡死问题
@noli #1
当`--sockbuf`较小, "网站 A --> kcptun"的速度远大于"kcptun --> 使用者"的速度时会发生
常见于使用者高速下载东西的同时还想要浏览其他网页时会卡卡的
会发现这问题是因为很久之前看油管都是同时搜寻+连开分页载入影片
结果只有一个分页有载入, 其他分页会卡住(包括搜寻的页面)
原本以为是频宽问题
多方尝试后最终确认是 multiplexing 的 smux 造成的
`--sockbuf`不够大, 其中一个 stream 快写慢读会造成 buffer 用尽导致其他 stream 都卡住
已经可以由 test 复现问题, 请移驾到 smux 专案察看详情
1  2  3  4  5  6  7  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   1518 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 16:41 · PVG 00:41 · LAX 08:41 · JFK 11:41
♥ Do have faith in what you're doing.