自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(99)
  • 资源 (8)
  • 收藏
  • 关注

原创 本地代码大模型评测实战(五):公平对比的5个陷阱

摘要(149字): 模型评测中的公平对比存在5个关键陷阱:1)思维模式差异导致能力评估偏差;2)错误处理方式不同造成通过率失真;3)单次运行的随机方差影响排名;4)训练数据泄露导致分数虚高;5)小样本量带来的统计不显著。评测时应统一思维模式设置、规范错误处理、多次运行取均值、使用时间切分的题目并扩大样本量。真正可靠的比较需要同时报告严格/宽松通过率、置信区间和错误明细,避免被表面数字误导。评测方法的选择比模型本身的差异影响更大。

2026-07-29 20:33:43 303

原创 本地代码大模型评测实战(四):8个坑和1个崩溃

坑发现难度修复成本一句话解法1思维循环高中流式输出+滑动窗口检测器2mmap双重映射中低--no-mmap(仅Windows)3DRY采样器高低移除所有惩罚参数4中低移除5Windows SSH进程中高在桌面session运行bat6GBK编码低低7中低用PrismML的llama.cpp fork8CUDA版本低低放对应版本DLL到程序目录先花半天时间搭好崩溃恢复和日志系统,再开始跑评测。

2026-07-29 20:13:21 311

原创 本地代码大模型评测实战(三):测试数据告诉我的13件事

第一,失败不是均匀的。模型在不会做的题上花更多时间、写更长代码、推理更久——所有"失败"的信号都指向同一个行为模式:死磕。这对推理服务的成本模型有直接影响。第二,评测的噪声比你想的大。12% 的翻转率、17 道分歧题、19 道全难题——任何声称"模型 A 比模型 B 强 X%"的结论,都需要考虑这些噪声源。单次跑分的置信度远低于你的想象。第三,能力是多维的。修 bug 和写代码是两种能力,思维链在 Hard 题上的优势是显著的,模型之间有独特的互补性。单一通过率掩盖了太多信息。

2026-07-29 20:10:08 373

原创 本地代码大模型评测实战(二):评测框架

本文评测了本地代码大模型PrismML-Ternary-Bonsai-27B在DebugBench上的修bug能力表现。关键发现:1)模型修bug通过率62.2%,比从零写代码高18个百分点;2)Easy题96.7%通过率,但Hard题降至53.2%;3)语法和逻辑错误修复率接近(79%),但多重错误处理较差(66.5%);4)76%的失败源于遗漏import等简单问题。结论表明模型擅长模式识别式bug修复,但面对复杂多错误时表现欠佳,在实际应用中更适合分步修复而非一次性解决。

2026-07-29 20:06:13 211

原创 本地代码大模型评测实战(一):9个模型、316道题、一张改装显卡

本地代码大模型评测实战摘要 本次评测对比了9个代码大模型在316道编程题目上的表现,包含本地部署和云端API模型。关键发现: 性能排名:DeepSeek V4 Pro(API)以66.6%通过率领先,本地模型ThinkingCap-Qwen3.6-27B(Q4_K_M)以59.5%居首,PrismML-Ternary-Bonsai-27B(Q2_0)以50.5%通过率仅需7GB显存。 硬件方案:使用改装RTX 3080(20GB显存)实现低成本高性能推理,相比RTX 4090节省75%成本。 评测陷阱:小样

2026-07-29 20:01:11 341

原创 TRINITY-Router: 用数据证伪LLM路由假设 - 8模型316题实验报告

这个项目的核心教训:论文里的路由效果之所以显著,是因为选择了模型间差异大、互补性强的任务域。竞赛级编程不是这样的域,它有一个明确的胜者,其他模型要么追不上,要么已经饱和。1414 题,测试调试能力(single-method + design-class bug),探测路由在非编写域的可行性。路由器的核心思路来自 OpenFugu 论文:用一个小语言模型读取题目,提取特征,通过线性头选择最佳模型。路由器的损失函数是 pass@1(代码能否通过测试),这是不可微分的二元信号,无法求梯度。:强模型都接近饱和。

2026-07-05 03:10:29 510 1

原创 SmartDNS nftset 多目标写入:从 Bug 到 PR 合并的完整路径

gnome-shell 每次 ACPI resume 后必现 segfault 2026-06-02 Fedora 44 AMD Phoenix APU (Radeon 780M) 一、故障现象原始日志解读 dmesg 里的原始一行: 逐字段拆开: error 5 的含义:x86\64 page f...gnome-shell 每次 ACPI resume 后必现 segfault 2026-06-02 Fedora 44 AMD Phoenix APU (Radeon 780M) 一、故障现象原始日志解读

2026-06-29 18:10:39 306

原创 sing-box 透明网关冻结:从 SIGQUIT Goroutine Dump 定位三重自锁 Bug

gnome-shell 每次 ACPI resume 后必现 segfault 2026-06-02 Fedora 44 AMD Phoenix APU (Radeon 780M) 一、故障现象原始日志解读 dmesg 里的原始一行: 逐字段拆开: error 5 的含义:x86\64 page f...gnome-shell 每次 ACPI resume 后必现 segfault 2026-06-02 Fedora 44 AMD Phoenix APU (Radeon 780M) 一、故障现象原始日志解读

2026-06-29 17:55:00 499

原创 N100软路由(五) 成型与加固--AP模式Mesh组网与网络优化

本文是N100软路由家庭网络改造系列的最后一篇,主要完成了从光猫桥接到软路由PPPoE拨号后的网络优化工作。内容包括将TP-LINK WTA301路由器改为AP模式(注意必须使用LAN口连接上游)、Mesh组网配置、解决双DHCP过渡期问题、网络速度测试(达到878/113Mbps)、配置SQM/CAKE算法解决Bufferbloat、PPPoE MTU设置(1492)、实现光猫管理页面的持久访问、IPv6配置等。文章详细记录了改造过程中遇到的五个主要坑点,强调网络问题需要依靠数据而非直觉来解决。最终实现了

2026-06-09 10:26:53 244

原创 N100软路由(四) 翻车现场--端口绑定引发的连锁故障

这篇技术文章记录了家庭网络改造过程中遇到的端口绑定故障。作者在将光猫改为桥接模式后,由于端口绑定配置变更,导致光猫管理页面无法访问,同时WiFi设备也受到影响。故障原因是端口绑定修改后,部分端口仅支持PPPoE透传,无法访问管理网络。文章提供了通过直连光猫其他端口的临时解决方案,并提醒了TR069自动配置可能重置超级密码的风险。最后总结了技术操作前要全面评估影响、保留恢复手段的经验教训。这是该系列文章的第四篇,下一篇将讨论网络优化方案。全文约800字,技术细节详实,故障排查思路清晰。

2026-06-09 10:20:12 188

原创 N100软路由(三) 拨号大战--PPPoE为什么就是拨不通

本文记录了家庭网络改造中PPPoE拨号失败的排查过程。主要问题包括:1)PPPoE PADO超时,原因是光猫桥接连接未绑定端口导致二层不通;2)运营商误将桥接模式改为路由模式;3)认证失败,发现实际用户名需添加"ad"前缀。通过分析日志、抓包和逐层排查,最终解决了三层不同问题(二层连通性、运营商配置错误、认证凭据),成功拨号获取公网IP。文章还介绍了PPPoE的四步建立过程,帮助理解故障原因。

2026-06-09 10:17:35 247

原创 N100软路由(二) 硬件上阵--J4125软路由与iStoreOS

本文介绍了从硬路由WTA301升级到J4125软路由的过程。J4125采用x86架构,配备4个2.5G网口和8GB内存,运行基于OpenWrt的iStoreOS系统。作者遇到一个关键问题:背板网口标注与系统识别编号完全相反,导致网络配置出错,通过命令行验证后才确认正确的端口映射关系。此外,文章还分享了PPPoE的离线配置技巧,包括禁用运营商DNS以防止劫持。最终,这台功耗仅10W的无风扇设备为后续网络改造奠定了基础,但真正的挑战——PPPoE拨号连接将在下一篇文章中展开。

2026-06-09 10:14:57 272

原创 N100软路由(一) 知己知彼--搞懂你家网络到底在干什么

本文介绍了家庭网络双重NAT问题的发现与解决思路。作者因PS5联机受限和NAS访问问题,发现家中存在光猫和路由器双重NAT的情况。通过分析光纤入户架构和光猫的两种工作模式(路由模式和桥接模式),作者指出桥接模式才是理想方案。进一步检查光猫配置后,发现当前网络实际使用了光猫的路由模式,而桥接通道处于闲置状态。文章最后明确了下一步改造方向:激活光猫的桥接功能,让软路由直接PPPoE拨号,从而实现单层NAT的网络结构。

2026-06-09 10:08:43 504

原创 手撕 coredump:一次 gnome-shell ACPI 唤醒 segfault 的完整诊断之旅

为什么写这篇 网上搜 Linux SSD 迁移,教程一大堆,但几乎全是同平台迁移(Intel 到 Intel 或者 AMD 到 AMD)。涉及 Intel 换 AMD 的跨平台迁移,要么只提一句"记得重建 initramfs"就完了,要么压根没提 Secure Boot、BitLocker、BLS ...问题现象 HP Z66 G6 14 (AMD Ryzen 7 H 255, Fedora 44, kernel 7.0.8) 通过 HDMI 线直连 5K 外接显示器,显示器提示"无信号"。 笔记本内屏 (

2026-06-03 17:01:18 375

原创 Claude Code + DeepSeek: role:system 400 错误的诊断与修复

文章摘要: Claude Code升级到v2.1.156后,claude-deepseek命令返回400错误,提示"unknown variant 'system'",而其他三家服务商工作正常。经排查发现,Claude Code新版本对所有服务商都会发送含role: "system"的消息,但DeepSeek的API端点对此校验更严格。为解决此问题,开发了一个本地代理服务,在请求到达DeepSeek前过滤掉role: "system"的消息条目。该代理通过bashrc集成自动启动,保持轻量级设计(约200行

2026-05-29 18:40:19 597

原创 HP Z66 G6 外接显示器无信号排查:amdgpu DCN 3.1 EDID 超时与 HDMI 2.1 FRL 协商问题

为什么写这篇 网上搜 Linux SSD 迁移,教程一大堆,但几乎全是同平台迁移(Intel 到 Intel 或者 AMD 到 AMD)。涉及 Intel 换 AMD 的跨平台迁移,要么只提一句"记得重建 initramfs"就完了,要么压根没提 Secure Boot、BitLocker、BLS ...问题现象 HP Z66 G6 14 (AMD Ryzen 7 H 255, Fedora 44, kernel 7.0.8) 通过 HDMI 线直连 5K 外接显示器,显示器提示"无信号"。 笔记本内屏 (

2026-05-20 20:40:53 415

原创 Fedora 跨平台 SSD 迁移实战:ThinkPad Intel 到 HP Z66 AMD

为什么写这篇 网上搜 Linux SSD 迁移,教程一大堆,但几乎全是同平台迁移(Intel 到 Intel 或者 AMD 到 AMD)。涉及 Intel 换 AMD 的跨平台迁移,要么只提一句"记得重建 initramfs"就完了,要么压根没提 Secure Boot、BitLocker、BLS ...

2026-05-09 01:53:06 388

原创 Intel BE200 WiFi 7 固件崩溃导致全系统冻结 22 秒的排查与修复

Intel BE200 WiFi 7 固件崩溃导致全系统冻结 22 秒的排查与修复 现象 某天正常使用笔记本时,系统突然完全卡死:鼠标不动、键盘无响应、屏幕定格。大约 22 秒后自动恢复。恢复后查看 ,满屏都是 soft lockup 告警: 一次性锁了 11 到 34 个 CPU,持续 22-30...Intel BE200 WiFi 7 固件崩溃导致全系统冻结 22 秒的排查与修复 现象 某天正常使用笔记本时,系统突然完全卡死:鼠标不动、键盘无响应、屏幕定格。大约 22 秒后自动恢复。恢复后查看 ,满屏

2026-05-06 19:27:01 486

原创 迅雷下载导致 Windows 11 频繁卡死?一根 SATA 线的锅

背景 家里有台组装的桌面工作站,平时用来跑 AI 训练和挂迅雷下载。最近一段时间频繁遇到系统整个冻住的情况——鼠标不动、键盘没反应,只能长按电源强制关机。一开始以为是 Windows 11 的锅,后来发现每次卡死都和迅雷下载有关,特别是往某块特定的硬盘写数据时。 机器配置: - CPU:12 代 I...

2026-05-04 19:04:03 285

原创 DeepSeek Anthropic 端点协议转换缺陷分析:为什么它在 Claude Code 上表现不佳

摘要 DeepSeek 提供的 Anthropic 兼容端点 () 在协议转换层面存在若干字段级缺陷,导致在使用 Claude Code 等重度依赖 Anthropic 协议的客户端时,跨文件推理能力、工具调用可靠性、以及多轮会话成本显著劣于官方端点。本文通过三阶段递进分析——受控 A/B 对照实验...

2026-05-03 23:35:43 917

原创 OVS-DPDK 性能调优:Bonding模式、vIOMMU 与 Packed Virtqueue 深度分析

OVS-DPDK 性能调优深度解析 本文基于 PVP(Physical-Virtual-Physical)拓扑的实测数据,系统分析 OVS-DPDK Bonding 三种模式的性能表现、vIOMMU 开销、Packed Virtqueue 效果以及 VLAN 标签的影响,并给出关键 PMD 指标的诊...

2026-04-23 17:00:14 285

原创 802.11 无线协议:k/v/r 与 WiFi 乒乓原理

背景:为什么需要这三个协议 早期 WiFi(802.11a/b/g/n)里,AP 是被动的——客户端完全自己决定什么时候漫游、连哪个 AP,AP 只能接受或拒绝,无法主动引导。 这在 Mesh 大面积覆盖场景下效率很低:客户端可能死抱信号差的远端 AP 不放。802.11k/v/r 三个协议赋予了 ...

2026-04-21 11:23:58 530

原创 iwlwifi/iwlmld missed beacons 与 802.11ax HE beacon timing 固件 Bug

问题现象 Fedora 43, kernel 6.19.11, Intel WiFi (iwlmld 驱动), 5GHz 802.11ax (HE) 连接。 dmesg 持续刷屏: 每条消息间隔精确 0.102s = beacon interval (100ms),说明每个 beacon 周期都丢。...

2026-04-21 11:22:04 498

原创 Windows 11 OpenSSH Server 完整排错指南(微软账号场景)

Windows 11 台式机(i5-12490F, RTX 3080 20GB),使用微软邮箱账号登录系统(whoami显示admin-pc\admin),需要从Linux笔记本SSH远程连入WSL2 Fedora进行GPU训练测试。:~/.ssh/目录有多个密钥(id_rsa, id_ecdsa, id_ed25519等),SSH客户端逐个尝试,超过MaxAuthTries限制。:Windows微软账号的密码通过SSH无法正常验证(Windows UAC/Microsoft Account机制限制)

2026-04-20 11:22:10 849

原创 默认参数与不定长参数传参时常见问题

本文主要讲述在进行默认参数传参与不定长参数传参时遇到的一个问题。python版本:python3.7python运行环境:win10+pycharm请看如下情况1:def paramdefined(p0, p1='a', *var, **keyvalue): print(f'p0的值为{p0},p1的值为{p1},var的值为{var},keyvalue的值为{keyvalue}')a = (1, 2, 3, 4, 5)b = {'name': 'houminxi', 'tel':

2020-08-16 18:40:56 1107

原创 Python3实现快速排序

Python3实现快速排序这里是对几年前用python2快排的一些改进。这里仍然交代一下算法的基本思想和实现步骤。最后谈下可优化的一些方法。#基本思想通过一趟排序将要排序的数据分割成独立的两个部分,其中一部分的所有数据都比另外一部分的所有数据都要小,然后再按次方法对这两部分数据分别进行快速排序,整个排序过程递归进行,以此来达到整个数据列变成有序数列。步骤如下:1.设置两个变量i和j,令序列第一个元素为基准元素(pivot)。2.i指向序列最左,j指向序列最右,j从右往左试探,i从左往右试探,直到

2020-08-06 17:36:32 616

原创 验证函数接收不定长参数时的拷贝类型

环境配置本人使用windows的环境来验证的该问题,环境配置如下:不定长参数拷贝方式在学习python3的函数的时候遇到了一个待考证的问题,在对函数进行不定长参数定义后,调用该函数传入参数时,函数会对参数的值进行拷贝。这里有个疑问就是形参拷贝实参时是什么类型的拷贝?如果是浅拷贝的话,那么实参变量中可变对线的值发生改变的话是否也会引起传入函数的值发生改变。假如定义一个函数以字典的方式接收不...

2020-04-12 20:09:44 511

翻译 开源网络负载测试工具-基准测试

这是一篇讲述主流测试工具在不同时延并发下性能表现的硬核翻译博文。原博主在没有触发协调遗漏问题上把主流测试工具挨个捅了一遍。看了该博文你将拥有深度网络测试装逼姿势。

2019-08-26 23:04:15 4115

翻译 开源网络负载测试工具测评

这是一篇讲述主流测试工具评价的软文。

2019-08-19 20:19:36 4553

原创 vegeta工具性能压测指南

高QPS性能测试工具阅读本文你将可能知道什么:理解vegeta的压测原理和设计目的,并且以正确的姿势使用该工具。解读vegeta的报告并通过笔者实际测试经验合理的设置压测参数。学会使用vegeta压测https的GET请求和POST请求。(虽然vegeta的说明文档中也有写)阅读本文你将无法知道什么:本文不会详述网络测试整个模型,测试指标之间的关联性。如果你不太清楚如何进行网络测...

2019-08-13 00:41:50 10481

原创 四层TCP协议测试利器-Tcpkali

前言本文详述四层协议测试工具TCPkali的基本用法。TCPkali是一个可以用来测试四层TCP协议,七层HTTP协议和websocket协议的测试工具。当然这个工具最好用的还是在于能够独立的进行TCP和websocket测试。tcpkali能最主要的好处就是它是C/S架构的测试工具。它可以建立起一个服务器并监听你指定的端口,按照测试需求接受压力端发来的请求包并按照你输入的参数对包做丢弃或者回应...

2019-08-12 00:29:54 3202

翻译 HTTP(S)基准测试工具,性能测试工具,restAPI(RESTful)测试工具

本博客翻译于github上一位作者所收录的七层测试工具。特将其记载并翻译出来仅供以后查看。原github的地址如下:https://github.com/denji/awesome-http-benchmarkHTTP(S) 基准测试工具以下工具按照字母顺序排列,并未按照工具性能排列给出。ab – 用C编写,单线程,请求发起缓慢apib – 使用C编写,涵盖了ab的大部分功能,被设计成为...

2019-07-28 20:00:11 2522

原创 七层网络性能基准测试中的协调遗漏问题--Coordinated Omission

本文首先描述七层网络的服务模型中,响应时间,并发连接数和QPS存在的关系。以此关系论述在进行基准测试时面临失速情况下测试工具所反馈的时延报告存在的问题。因为测试计划所导致的请求等待和因为统计工具的采样所导致结果呈现差异。最后以wrk2工具来实际展现了在经过校验的时延和未经过校验的时延在直返分布图上所呈现的差异。

2019-07-27 14:21:24 1885

原创 JMeter-调整分布式压力机的堆栈大小

笔者因实在苦于单机JMeter实在无法满足测试需求,好在JMeter支持分布式压力测试与结果的回收统计。在进行JMeter分布式测试时发现,给定过高压力仍然会导致JAVA的OOM错误。笔者在这个时候还是没想清楚怎么一回事,知道查看压力机JMeter进程时发现远程压力机在执行JMeter压测的时候仍然使用的是JMeter默认的堆栈配置,这样难免在分配给高线程压力的时候造成OOM(Out Of ...

2019-07-23 23:59:30 1816

原创 Jmeter性能调优建议

Jmeter性能调优建议Jmeter作为免费的开源压测软件有着非常强大的功能。支持四层到七层协议的测试,主要还是TCP协议,http,https,websocket(需要下载额外的拓展包来支持该协议测试)。Jmeter的功能很丰富但本篇博客不对Jmeter功能做过多详细介绍。相信很多同学在执行Jmeter的过程中如对被测物实行高压力压测的过程中会报出类似于OMM(Out Of Memory)的错...

2019-07-23 00:32:21 12876

翻译 官档翻译-启用High Precision Event Timer (HPET) Functionality

原文地址:http://doc.dpdk.org/guides/linux_gsg/enable_func.html#enabling-additional-functionalityBIOS准备针对惠普的机器1.HIGH PRECISION Timer建议开启grep hpet /proc/timer_list2.需要内核开启HPET_MMAP内核配置。在很多linux的发布版本中例...

2018-12-21 11:02:45 3344

翻译 官档翻译-从源码编译DPDK注意事项

注意:下篇中描述的有些步骤可以在Quick Start Setup Script章节中提到http://doc.dpdk.org/guides/linux_gsg/quick_start.html#linux-setup-script浏览源码安装DPDK首先解压下载下来源码压缩包,然后进入到解压之后DPDK源码目录中。tar xJf dpdk-.tar.xzcd dpdk-DPDK的...

2018-12-21 11:01:20 791 1

翻译 官档翻译-安装dpdk前的准备工作

翻译地址:http://doc.dpdk.org/guides/linux_gsg/sys_reqs.html编译DPDK所需系统要求1.GUN make2.coreutils: cmp,sed,grep,archetc3.gcc:版本 4.9+4.需要安装kernel - devel.x86_64或者 kernel - devel.ppc645.针对32和64位的系统需要考虑不同的安...

2018-12-21 10:59:36 509

原创 rfc2544_tput_test脚本中增加丢包率功能

RFC2544转发测试过程pktgen-dpdk的rfc2544_tput_test.lua脚本在运行RFC2544测试时,默认会以设定的50%速率发送测试包(默认的测试包长是64, 128, 256, 512, 1024, 1280, 1518 )。假设发包的端口是万兆网卡,那么初始的发包速率是万兆网卡速率的一半发包。通过l2fwd转发包之后pktgen-dpdk会统计本次测试收到的包。如果收...

2018-12-19 17:59:19 1615

原创 l2fwd--增加自定义修改目的mac地址功能

前言这个功能是由我同事针对特定测试需求在l2fwd脚本中二次开发的功能。用以支持l2fwd转发流量能够自定义指定用户输入的mac地址。今年初我同事因为各种原因离开公司和团队,谨以此博客来纪念我同事无私的奉献。并希望有同样功能诉求的人在看到这篇博客时,这个工具能对你们有所帮助。功能详解l2fwd脚本运行时会绑端口,将绑定的端口上的流量进行转发。但是仔细一想转发只是完成了一个流向转换的过程。以p...

2018-12-18 13:56:30 1922 3

Pacemaker入门手册_Clusters_from_Scratch

简介pacemaker入门并且教你如何部署一个可用的HA集群。

2017-06-15

dpdk18版本下l2fwd自定义修改目的mac地址

将解压包解压之后,有一个main.c.dmac的文件,将其.dmac后缀去掉。然后放入l2fwd文件夹中。 编译如下: # export RTE_SDK=/root/dpdk # export RTE_TARGET=build # make CC main.o LD l2fwd INSTALL-APP l2fwd INSTALL-MAP l2fwd.map 适配dpdk-17.11.1,命令通过新增-d指定端口的dmac。 ./build/l2fwd -c 3 -n 2 -- -p 3 -d 11:11:11:11:11:11 -d 22:22:22:22:22:22 Port0的dmac为: 11:11:11:11:11:11 Port2的dmac为: 22:22:22:22:22:22 运行时输出信息增加了port的用户指定dmac显示: … Initializing port 0... done: Port 0, MAC address: 52:54:00:46:8D:C0 Initializing port 1... done: Port 1, MAC address: 52:54:00:F0:6C:50 Port 0, Destination MAC address: 11:11:11:11:11:11 Port 1, Destination MAC address: 22:22:22:22:22:22

2018-12-18

wrk2工具--修复了时延详情中统计的包个数与最后总结果发包个数不一致的情况

在3.10.0-957.5.1.el7.x86_64的内核编译完成,直接修改文件权限可用。

2019-07-27

pps测试软件

linux内核下测试极限三层网络pps值,通过增加udpsender的数量可以使udpreceiver接收更多的包。从而接近网络限速。

2018-12-09

dpdk17版本下的l2fwd支持目的mac地址手动修改

编译如下: # export RTE_SDK=/root/dpdk-stable-17.11.1 # export RTE_TARGET=build # make CC main.o LD l2fwd INSTALL-APP l2fwd INSTALL-MAP l2fwd.map 适配dpdk-17.11.1,命令通过新增-d指定端口的dmac。 ./build/l2fwd -c 3 -n 2 -- -p 3 -d 11:11:11:11:11:11 -d 22:22:22:22:22:22 Port0的dmac为: 11:11:11:11:11:11 Port2的dmac为: 22:22:22:22:22:22 运行时输出信息增加了port的用户指定dmac显示: … Initializing port 0... done: Port 0, MAC address: 52:54:00:46:8D:C0 Initializing port 1... done: Port 1, MAC address: 52:54:00:F0:6C:50 Port 0, Destination MAC address: 11:11:11:11:11:11 Port 1, Destination MAC address: 22:22:22:22:22:22

2018-12-18

TRITON - Web Security

websence的Triton软件用于提供webproxy

2016-07-08

LTM client GUI

微软LTM操作文档说明

2016-07-08

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除