0

0

以太网自协商机制--双绞线自协商(十四)

爱谁谁

爱谁谁

发布时间:2025-04-26 15:08:16

|

352人浏览过

|

来源于php中文网

原创

双绞线自协商总结篇(一)

自协商仲裁功能

理解双绞线自协商机制的关键在于自协商仲裁状态机。本文将通过几个常见的应用场景简要解析这一部分。如果希望更深入了解细节,请自行查阅IEEE 802.3相关章节。

自协商仲裁状态机状态图

以太网自协商机制--双绞线自协商(十四)

异常场景1

A端启用自协商功能,单端悬空后执行上电操作。

A端的状态机流程:

进入状态“AUTO-NEGOTIATION ENABLE”;

进入状态“TRANSMIT DISABLE”(设置break_link_timer为1.2s到1.5s,并启用它);

事件break_link_timer_done;

进入状态“ABILITY DETECT”;[此状态为最终稳定态]

在“ABILITY DETECT”状态中,以transmit_link_burst_timer(默认值为5.7ms到22.3ms,一般为14ms)为周期持续通过PairA管脚发送FLP Base Page Bursts。

异常场景2

A端启用自协商功能,B端关闭自协商功能,先连接好双绞线,然后执行上电操作。

A端的状态机流程:

进入状态“AUTO-NEGOTIATION ENABLE”;

进入状态“TRANSMIT DISABLE”(设置break_link_timer为1.2s到1.5s,并启用它);

事件break_link_timer_done;

进入状态“ABILITY DETECT”;

[因为B端自协商关闭,ability_match永远为false];

事件linkstatus[TX]=READY(B端为100M)或

事件linkstatus[NLP]=READY(B端为10M);

进入状态“LINK STATUS CHECK”(设置autoneg_wait_timer为0.5s到1s,并启用它);

事件autoneg_wait_timer_done 且

single_link_ready=true;

进入状态“FLP LINK GOOD CHECK”;

事件linkstatus[HCD]=OK

(B端为100M时,HCD为100BASE-TX半双工;B端为10M时,HCD为10BASE-T半双工);

进入状态“FLP LINK GOOD”;[此状态为最终稳定态]

B端的状态机流程:

由于B端自协商关闭,与自协商仲裁状态机无关,这里不再赘述。

异常场景3

A端启用自协商功能(千兆PHY),B端启用自协商功能(千兆PHY),先连接好4芯双绞线(pin4,5,7,8无双绞线),然后执行上电操作。

A端的状态机流程:

进入状态“AUTO-NEGOTIATION ENABLE”;

进入状态“TRANSMIT DISABLE”(设置break_link_timer为1.2s到1.5s,并启用它);

事件break_link_timer_done;

/进入Base Page协商阶段/

进入状态“ABILITY DETECT”;

事件ability_match=true

(A,B互相FLP Base Page交互后);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Base Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/进入Next Page协商阶段/

/Next Page-Message/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Next Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/Next Page-Unformatted-1/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Next Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/Next Page-Unformatted-2/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Next Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/FLP交互结束/

事件(ack_finished=true 且

(mr_np_able=false 或

desire_np=false 或

mr_lp_np_able=false)) 或

(ack_finished=true 且

mr_np_able=true 且

mr_lp_np_able=true 且

tx_link_code_word[NP]=0 且

np_rx=1);

进入状态“FLP LINK GOOD CHECK”(设置link_fail_inhibit_timer为0.75s到1s,并启用它);

[HCD为1000BASE-T全双工。因为MDI侧RJ45接口的PairC,PairD没有连接,1000BASE-T link完整性测试无法通过,“linkstatus[HCD]=OK”永远无法满足];

GentleAI
GentleAI

GentleAI是一个高效的AI工作平台,为普通人提供智能计算、简单易用的界面和专业技术支持。让人工智能服务每一个人。

下载

事件((linkstatus[HCD]=FAIL 或

linkstatus[HCD]=READY) 且

link_fail_inhibit_timer_done)或

incompatible_link=true;

进入状态“TRANSMIT DISABLE”(设置break_link_timer为1.2s到1.5s,并启用它);

事件break_link_timer_done;

/进入Base Page协商阶段/

/进入Next Page协商阶段/

/FLP交互结束/

/进入Base Page协商阶段/

/进入Next Page协商阶段/

/FLP交互结束/

……

一直在上述状态中循环,始终无法建立正确链接。

B端的状态机流程与A端基本相同,这里就不赘述了。

这里可能有读者会质疑,我们使用了4芯网线实现了两个千兆PHY的100BASE-TX模式的正确连接。笔者在这里解释一下,笔者异常场景3的分析过程是基于完全硬件无软件参与的PCS的自协商仲裁状态机。读者们遇到的场景,往往是计算机网卡驱动或者交换机的端口管理软件主动参与了“自协商广告能力设置和Base Page的NP比特设置”,从而在该场景下的百兆正确连接。

正常场景1

A端启用自协商功能(千兆PHY),B端启用自协商功能(千兆PHY),先连接好8芯双绞线,然后执行上电操作。

A端的状态机流程:

进入状态“AUTO-NEGOTIATION ENABLE”;

进入状态“TRANSMIT DISABLE”(设置break_link_timer为1.2s到1.5s,并启用它);

事件break_link_timer_done;

/进入Base Page协商阶段/

进入状态“ABILITY DETECT”;

事件ability_match=true

(A,B互相FLP Base Page交互后);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Base Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/进入Next Page协商阶段/

/Next Page-Message/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Next Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/Next Page-Unformatted-1/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Next Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/Next Page-Unformatted-2/

事件ack_finished=true 且

mr_np_able=true 且

desire_np=true 且

mr_lp_np_able=true 且

mr_next_page_loaded=true 且

((tx_link_code_word[NP]=1) 或

(np_rx=1));

进入状态“NEXT PAGE WAIT”;

事件ability_match=true 且

((toggle_rx XOR ability_match_word[12])=1);

进入状态“ACKNOWLEDGE DETECT”;

事件ability_match=true

(A,B互相FLP Base Page(ACK=1)交互后);

进入状态“COMPLETE ACKNOWLEDGE”;

/FLP交互结束/

事件(ack_finished=true 且

(mr_np_able=false 或

desire_np=false 或

mr_lp_np_able=false)) 或

(ack_finished=true 且

mr_np_able=true 且

mr_lp_np_able=true 且

tx_link_code_word[NP]=0 且

np_rx=1);

进入状态“FLP LINK GOOD CHECK”(设置link_fail_inhibit_timer为0.75s到1s,并启用它);

事件linkstatus[HCD]=OK

(HCD为1000BASE-T全双工);

进入状态“FLP LINK GOOD”;[此状态为最终稳定态]

B端的状态机流程与A端基本相同,这里就不赘述了。

这里笔者抛砖引玉一下,千兆双绞线自协商正常完成需要多少时间呢?MultiGBASE-T自协商正常完成又需要多少时间呢?

FLP示波器测量

当双绞线PHY单端悬空时,自协商双方持续性周期性发送FLP-BasePage。双方完成BasePage的“ACKNOWLEDGE DETECT”和“COMPLETE ACKNOWLEDGE”状态机之后,才会进入Next Pages(千兆PHY)/Extended Next Pages(MultiGBASE-T PHY)交互阶段。所以当双绞线的端口单端悬空时,用示波器测量PairA(RJ45的pin1,2)的FLP波形,用户永远只能抓到BasePage的内容(即使是千兆PHY/ MultiGBASE-T PHY,也无法抓到Next Pages/Extended Next Pages的波形,因为单端悬空时“自协商仲裁状态机”永远在“ABILITY DETECT”态)。

笔者这里提个问题,只给你一台示波器和一台交换机,能否判断出这台交换机的PHY的类型吗?(FE PHY ? GE PHY ? MultiGBASE-T PHY?)

重新自协商功能

在双绞线双方已经建立正确链接的情况下,双绞线的任何一端改变自协商的广告能力并不会自动重新执行自协商的过程。需要执行下面的任一动作,新设置的自协商广告能力方可通过重新自协商而生效(以博通的MultiGBASE-T PHY BCM84891L举例):

Software reset (7.0.15,7.65504.15),软件设置为1,然后软复位完成(寄存器会自动恢复为0),接着PHY硬件会按照最新的自协商广告能力重新进行协商。

Restart Auto-Negotiation (7.0.9,7.65504.9),软件设置为1,然后PHY硬件会按照最新的自协商广告能力重新进行协商,协商完成后寄存器会自动恢复为0。

Auto-Negotiation Enable bit toggles (7.0.12,7.65504.12),软件设置为0,然后设置为1,接着PHY硬件会按照最新的自协商广告能力重新进行协商。

管理员手动地将双绞线重新插拔一次,接着PHY硬件会按照最新的自协商广告能力重新进行协商。

双绞线自协商总结篇未完待续……

热门AI工具

更多
DeepSeek
DeepSeek

幻方量化公司旗下的开源大模型平台

豆包大模型
豆包大模型

字节跳动自主研发的一系列大型语言模型

WorkBuddy
WorkBuddy

腾讯云推出的AI原生桌面智能体工作台

腾讯元宝
腾讯元宝

腾讯混元平台推出的AI助手

文心一言
文心一言

文心一言是百度开发的AI聊天机器人,通过对话可以生成各种形式的内容。

讯飞写作
讯飞写作

基于讯飞星火大模型的AI写作工具,可以快速生成新闻稿件、品宣文案、工作总结、心得体会等各种文文稿

即梦AI
即梦AI

一站式AI创作平台,免费AI图片和视频生成。

ChatGPT
ChatGPT

最最强大的AI聊天机器人程序,ChatGPT不单是聊天机器人,还能进行撰写邮件、视频脚本、文案、翻译、代码等任务。

相关专题

更多
硬盘接口类型介绍
硬盘接口类型介绍

硬盘接口类型有IDE、SATA、SCSI、Fibre Channel、USB、eSATA、mSATA、PCIe等等。详细介绍:1、IDE接口是一种并行接口,主要用于连接硬盘和光驱等设备,它主要有两种类型:ATA和ATAPI,IDE接口已经逐渐被SATA接口;2、SATA接口是一种串行接口,相较于IDE接口,它具有更高的传输速度、更低的功耗和更小的体积;3、SCSI接口等等。

1958

2023.10.19

PHP接口编写教程
PHP接口编写教程

本专题整合了PHP接口编写教程,阅读专题下面的文章了解更多详细内容。

658

2025.10.17

php8.4实现接口限流的教程
php8.4实现接口限流的教程

PHP8.4本身不内置限流功能,需借助Redis(令牌桶)或Swoole(漏桶)实现;文件锁因I/O瓶颈、无跨机共享、秒级精度等缺陷不适用高并发场景。本专题为大家提供相关的文章、下载、课程内容,供大家免费下载体验。

2401

2025.12.29

java接口相关教程
java接口相关教程

本专题整合了java接口相关内容,阅读专题下面的文章了解更多详细内容。

47

2026.01.19

Python 自然语言处理(NLP)基础与实战
Python 自然语言处理(NLP)基础与实战

本专题系统讲解 Python 在自然语言处理(NLP)领域的基础方法与实战应用,涵盖文本预处理(分词、去停用词)、词性标注、命名实体识别、关键词提取、情感分析,以及常用 NLP 库(NLTK、spaCy)的核心用法。通过真实文本案例,帮助学习者掌握 使用 Python 进行文本分析与语言数据处理的完整流程,适用于内容分析、舆情监测与智能文本应用场景。

418

2026.01.27

TypeScript类型系统进阶与大型前端项目实践
TypeScript类型系统进阶与大型前端项目实践

本专题围绕 TypeScript 在大型前端项目中的应用展开,深入讲解类型系统设计与工程化开发方法。内容包括泛型与高级类型、类型推断机制、声明文件编写、模块化结构设计以及代码规范管理。通过真实项目案例分析,帮助开发者构建类型安全、结构清晰、易维护的前端工程体系,提高团队协作效率与代码质量。

25

2026.03.13

Python异步编程与Asyncio高并发应用实践
Python异步编程与Asyncio高并发应用实践

本专题围绕 Python 异步编程模型展开,深入讲解 Asyncio 框架的核心原理与应用实践。内容包括事件循环机制、协程任务调度、异步 IO 处理以及并发任务管理策略。通过构建高并发网络请求与异步数据处理案例,帮助开发者掌握 Python 在高并发场景中的高效开发方法,并提升系统资源利用率与整体运行性能。

44

2026.03.12

C# ASP.NET Core微服务架构与API网关实践
C# ASP.NET Core微服务架构与API网关实践

本专题围绕 C# 在现代后端架构中的微服务实践展开,系统讲解基于 ASP.NET Core 构建可扩展服务体系的核心方法。内容涵盖服务拆分策略、RESTful API 设计、服务间通信、API 网关统一入口管理以及服务治理机制。通过真实项目案例,帮助开发者掌握构建高可用微服务系统的关键技术,提高系统的可扩展性与维护效率。

174

2026.03.11

Go高并发任务调度与Goroutine池化实践
Go高并发任务调度与Goroutine池化实践

本专题围绕 Go 语言在高并发任务处理场景中的实践展开,系统讲解 Goroutine 调度模型、Channel 通信机制以及并发控制策略。内容包括任务队列设计、Goroutine 池化管理、资源限制控制以及并发任务的性能优化方法。通过实际案例演示,帮助开发者构建稳定高效的 Go 并发任务处理系统,提高系统在高负载环境下的处理能力与稳定性。

50

2026.03.10

热门下载

更多
网站特效
/
网站源码
/
网站素材
/
前端模板

精品课程

更多
相关推荐
/
热门推荐
/
最新课程
计算机系统从应用层到底层
计算机系统从应用层到底层

共6课时 | 0.4万人学习

开源物联网开发实例
开源物联网开发实例

共6课时 | 0.4万人学习

关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送

Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号