精华内容
下载资源
问答
  • 快速切换技术的目标是尽可能减少切换时延并保证在切换过程中通信不中断,也没有数据包的丢失。快速切换技术主要有两种解决方案。一是切换前建立LSP机制,还有就是基于组播的快速切换机制。切换前建立LSP机制的基本...
  • 在蜂窝移动通信系统中,切换可在服务小区信号变坏时把用户(UE)及其上下文从源小区迁移到目标小区,从而将UE切换到目标小区继续会话过程。LTE网络中切换仅支持与核心网连接(ECM-CONNECTED)状态的终端。终端在同一MME...

    在蜂窝移动通信系统中,切换可在服务小区信号变坏时把用户(UE)及其上下文从源小区迁移到目标小区,从而将UE切换到目标小区继续会话过程。

    LTE网络中切换仅支持与核心网连接(ECM-CONNECTED)状态的终端。

    终端在同一MME,服务网关也不更改场景下,终端切换主要流程如下:

    0816b7cb5a8369c94a3408a02f1be79d.png

    根据以上流程,终端切换可分为三阶段:

    •切换准备:源小区切换判决(UE和eNB的测量控制和测量结果评估),目标小区的资源准备(Step#1Step#6)

    •切换执行:UE接收切换命令和新小区无线资源获取(Step#7Step#11)

    •切换完成源小区资源释放(Step#12到Step#18)

    切换时延

    切换时延是衡量系统性能指标之一。根据3GPP 36.881切换时延可定义为:终端接收到源小区切换命令的时间(RRC连接重配置中包括目标小区信息-- mobilityControlInfo)开始,到终端(UE)发送RRC连接重配置完成给目标小区截止;也就是说切换延迟是在切换执行(步骤)期间所花费的时间。

    切换时延因素

    切换过程中与延迟相关的因素包括:切换执行相关所有步骤,即从Step#7到Step#11

    e818e18a18b0198cd7b8457ba87c86eb.png

    Step#7:RRC连接重新配置消息中包括Mobilitycontrollinfo;在这一步UE接收到接入(目标小区)必要参数(即新的C-RNTI、目标eNB安全算法标识及可选的专用RACH前导-前导序列码、目标eNB SIBs等)的RRC Connection Restruction消息,并由源eNB下发命令,执行切换。切换进程中的延迟包括:RRC连接重构、移动性控制及相关重构,具体内容如下:

    • 层2 Reset/重配置;

    • MAC层Reset;

    • 对所有新建的RBs重建/重配置PDCP和RLC;

    • 对RRC消息进行加密和完整性保护;

    • 层3重配置(测量配置等)

        在TS36.331的11.2节定义,切换在RRC层最大允许时延为15 ms.

    Step#8:SN状态转移: 在这一步源eNB向目标eNB发送SN状态转移消息,以传递上行PDCP SN接收状态;下行链路PDCP SN发送使用那个E-RABs的PDCP状态 (即RLC AM)。由于这是eNB与eNB的信令与空中接口无关;其可以与后续的Step 9并行执行,此步中的延迟可被总延迟忽略。

    Step#9:终端接收切换命令后在目标小区上同步(Step#7:RRC Connection Reconfiguration  message中包括 mobilitycontrolinfo信息) ,UE此步中执行的内容如下

    • 物理层同步和重新配置;

    • 终端开始与目标Pcell进行下行(DL)同步;

    • 物理层重配置;

    • 通过RACH接入目标小区(如果mobilityControlInfo,中指定了一个专用的RACH前导,则遵循不竞争流程;如果没有指定前导序列码,则遵循一个基于竞争接入流程);

    • 层2重配置

    • 密钥更新:UE向目标eNB索取密钥和安全算法配置,以便在目标小区使用。

    根据TS 36.133定义,当接收到RRC消息终端即开始切换,UE在最后一个包含RRC命令的TTI结束后,准备开始在新(小区)上行PRACH信道中发送数据;此处Dhandover是RRC进程延滞和(数据)“中断时间”;该中断时间定义为:旧小区PDSCH上最后一个包括RRC命令的TTI,到UE在新小区PRACH信道进行传输的时间差,其中不包括RRC进程的延迟。

    中断时间

    • 目标小区搜索;

    • 终端无线时钟处理/基带调整,根据目标eNB密钥进行加密算法应用;

    • 无线接入相关(根据随机接入序列码接入时机的获取时延);

    Step#9.1:目标小区搜索:在多数情况下目标小区是根据UE的测量报告选择,可假定是“已知的”,因此其延迟可被认为是0毫秒。

    Step#9.2: UE射频处理/基带重新调整时间,安全更新;其实际数值根据不同的参数有很大差异,为此可认为UE 处理时间(射频/基带重新调整,获取目标eNB特定密钥,配置安全算法在目标小区使用)在 TS  36.133定义中为20 ms

    Step#9.3获取目标eNB中首个可用PRACH延迟: 假设一个典型RACH配置中 每5个子帧有1 个RACH可用,该步的最小延迟为0.5ms,典型延迟为2.5 ms

    Step#9.4前导码传输:最后一个延迟单元是每次前导传输需要1个子帧,即1ms

    Step#10:上行指配+UE的TA。

    Step#10:在这一步中,目标eNB为UE的接入进行了UL资源和TA分配。假设LTE FDD和子帧数连续,如果UE在子帧 n 中发送RACH序列,根据规范eNB最早可以在子帧 n + 3中发送RAR响应 (5.1.4 of TS 36.321)。假设授权解码或TA延迟不包括在这一步,这一步的最小延迟将是3 ms,典型场景的平均延迟将是5 ms

    Step#11: UE发送RRC连接重新配置完成:当成功接入目标小区时,UE发送(包含C-RNTI)的RRCConnectionReconfigurationComplete 消息以确认切换;同时还把上行缓冲区状态报向目标eNB发送,表明UE完成了切换过程。目标eNB验证在RRCConnectionReconfigurationComplete消息中发送的C-RNTI。之后目标eNB可开始在下行向UE发送数据。

    根据TS 36.213中6.1.1节,UE最早可在 k1 > = 6个子帧之后发送RRC ConnectionReconfigurationComplete ;这一步延迟一般为6 ms,其中:包括UE处理延迟(调度授权解码和UL数据的时间对齐 + 层1数据编码)和RRC连接重配置传输完成。典型场景每Step时间延迟表:

    Component/ Step

    Description

    Time (ms)

    7

    RRC Connection Reconfiguration Incl. mobilityControlInfo

    15

    8

    SN Status Transfer

    0

    9.1

    Target cell search

    0

    9.2

    UE processing time for RF/baseband re-tuning, security  update

    20

    9.3

    Delay to acquire first available PRACH in target eNB

    0.5/2.5

    9.4

    PRACH preamble transmission

    1

    10

    UL Allocation + TA for UE

    3/5

    11

    UE sends RRC Connection Reconfiguration Complete

    6

    Minimum/Typical Total delay [ms]

    45.5/49.5

    注意:上述数值假设条件是在第一次就尝试成功。现实中接入尝试并不总是正确的,特别是在切换场景中,信道质量可能会降低;其中有些步骤可能需要重新传输,实际延迟值会更高。

    展开全文
  • 利用辅基站在切换过程中传输数据,以降低传统切换方式中因完全断开双连接导致数据传输中断所引起的时延。首先,对传统切换机制进行分析并进行问题定位;其次,提出和详细阐述新型切换机制的信令交互流程,并分别建立...
  • 实验目的:中断方式按键(PA0)实现流水灯,每个灯之间的切换时延是2秒。 1.在文件stm32f4xx.h中找到STM32F40_41xxx系列HSE_VALUE(L144)改为8000000 在文件system_stm32f4xx.c中修改STMF40_41xxx系列 PLL_M=8 L...

    实验目的:中断方式按键(PA0)实现流水灯,每个灯之间的切换时延是2秒。
    1.在文件stm32f4xx.h中找到STM32F40_41xxx系列HSE_VALUE(L144)改为8000000
    在这里插入图片描述
    在文件system_stm32f4xx.c中修改STMF40_41xxx系列
    PLL_M=8 L371
    PLL_N=336 L401
    PLL_P=2 L403
    在这里插入图片描述
    systick.c

    #include "stm32f4xx.h"
    #include <stdint.h>
    #define rSysTickCtrl *((volatile unsigned long*)0xE000E010)
    
    static uint32_t systicknum = 0;
    
    
    //定时器中断函数
    void SysTick_Handler(void)
    {
        if(systicknum != 0)
        {
            systicknum--;
        }    
    }
    
    void delay_ms(uint32_t m)
    {
        systicknum = m;	
    		SysTick_Config(SystemCoreClock/1000);
    		NVIC_SetPriority(SysTick_IRQn, 0); 
        while(systicknum != 0);
    		rSysTickCtrl &=  ~(1 << 0) ; // bit0 -> 0  disable SysTick
    }
    
    void delay_us(uint32_t u)
    {
    	systicknum = u;
    	SysTick_Config(SystemCoreClock/1000000);
    	//NVIC_SetPriority(SysTick_IRQn, 1); 
    	while(systicknum != 0);
    	rSysTickCtrl &=  ~(1 << 0) ; // bit0 -> 0  disable SysTick
    }
    

    rj_led.c

    #include "rj_led.h"
    #include "systick.h"
    
    void led_init()
    {
       GPIO_InitTypeDef P;
    	/*使能GPIOD的时钟*/
    	RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
    
    	/*配置PD0,PD1,PD2,PD3,为输出模式,输出类型为输出推挽,
    	               速率为50MHz,无上拉下拉电阻*/
    	P.GPIO_Pin = GPIO_Pin_0|GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_3;
    	P.GPIO_Mode = GPIO_Mode_OUT;
    	P.GPIO_OType = GPIO_OType_PP;	
    	P.GPIO_Speed = GPIO_Speed_50MHz;
    	P.GPIO_PuPd = GPIO_PuPd_NOPULL;
    	GPIO_Init(GPIOD, &P);
    }
    
    void led_ctrl(int led_n)
    {	
    	switch(led_n)
    		{
    			case 1:
    				{            /*控制LED1亮,其他灯熄灭,给PD0端口置1,PD1,PD2,PD3端口置0*/
    					GPIO_SetBits(GPIOD, GPIO_Pin_0);
    					GPIO_ResetBits(GPIOD, GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_3);
    					break;
    				}
    			case 2:
    				{            /*控制LED2亮,其他灯熄灭,给PD1端口置1,PD0,PD2,PD3端口置0*/
    					GPIO_SetBits(GPIOD, GPIO_Pin_1);
    					GPIO_ResetBits(GPIOD, GPIO_Pin_0|GPIO_Pin_2|GPIO_Pin_3);
    					break;
    				}
    			case 3:
    				{             /*控制LED3亮,其他灯熄灭,给PD2端口置1,PD1,PD0,PD3端口置0*/
    					GPIO_SetBits(GPIOD, GPIO_Pin_2);
    					GPIO_ResetBits(GPIOD, GPIO_Pin_1|GPIO_Pin_0|GPIO_Pin_3);
    					break;
    				}
    			case 4:
    				{              /*控制LED4亮,其他灯熄灭,给PD3端口置1,PD1,PD2,PD0端口置0*/
    					GPIO_SetBits(GPIOD, GPIO_Pin_3);
    					GPIO_ResetBits(GPIOD, GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_0);
    					break;
    				}
    			default:
    				break;
    		}
    }
    
    void delay(int num)
    {
    		while(num--);
    }
    
    void led_loop()      //LED等循环点亮;
    {
    	int led_count=1;	
    	for(led_count=1;led_count<5;led_count++)
    	{
    		led_ctrl(led_count);
    		delay_ms(200);
    	}	
    }
    
    

    rj_int_key.c

    #include "stm32f4xx.h"
    
    
    /*
    	KEY -> PA -> EXTI -> NVIC -> CPU EXTI_IRQHandler
    */
    void key_int_init(void)
    {
    	//时钟使能;
    	RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA|RCC_AHB1Periph_GPIOE,ENABLE);
    
    	/*配置端口,为输入模式,速率为50MHz,不上拉*/
    	GPIO_InitTypeDef p;
    	p.GPIO_Pin=GPIO_Pin_0;
    	p.GPIO_Mode=GPIO_Mode_IN;       
    	p.GPIO_Speed=GPIO_Speed_50MHz;
    	//p.GPIO_OType=GPIO_OType_PP;  //输出推挽;
    	p.GPIO_PuPd=GPIO_PuPd_NOPULL;
    
    	GPIO_Init(GPIOA,&p);
    	p.GPIO_Pin=GPIO_Pin_2|GPIO_Pin_3|GPIO_Pin_4;
    	GPIO_Init(GPIOE,&p);
    	
    	/*SYSCFG选择器的配置*/
    	RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);	//时钟使能;
    	SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOA,EXTI_PinSource0);  //选择PA0作为外部中断的输入引脚;
    	SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOE,EXTI_PinSource2);   //PE2
    	SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOE,EXTI_PinSource3);  //PE3
    	SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOE,EXTI_PinSource4);   //PE4
    	
    	/*外部中断控制器的配置*/
    	RCC_APB2PeriphClockCmd(RCC_APB2Periph_EXTIT, ENABLE);//时钟使能;
    	EXTI_InitTypeDef e;
    	e.EXTI_Line=EXTI_Line0|EXTI_Line2|EXTI_Line3|EXTI_Line4;
    	e.EXTI_Mode=EXTI_Mode_Interrupt;    //中断模式;
    	e.EXTI_LineCmd=ENABLE;
    	e.EXTI_Trigger=EXTI_Trigger_Rising;       //上升沿;
    	
    	EXTI_Init(&e);
    	
    	/*NVIC的控制*/
    	NVIC_PriorityGroupConfig(NVIC_PriorityGroup_2);//pre:2,sub:2 
    	NVIC_InitTypeDef n;
    	n.NVIC_IRQChannel=EXTI0_IRQn;
    	n.NVIC_IRQChannelCmd=ENABLE;
    	//n.NVIC_IRQChannelPreemptionPriority = 0x02;
    	//n.NVIC_IRQChannelSubPriority = 0x02;
    	NVIC_Init(&n);
    	
    	n.NVIC_IRQChannel=EXTI2_IRQn;
    	NVIC_Init(&n);
    	
    	n.NVIC_IRQChannel=EXTI3_IRQn;
    	NVIC_Init(&n);
    	
    	n.NVIC_IRQChannel=EXTI4_IRQn;
    	NVIC_Init(&n);
    	
    	NVIC_SetPriority(EXTI0_IRQn,0x07);
    	
    	
    }
    
    
    uint8_t	status = 0;
    void key_irqHandler(void)
    {
    	//	1.EXTI_GetITStatus 
    	if (EXTI_GetITStatus(EXTI_Line0) == SET)
    	{
    		status = 1;
    		//EXTI_ClearFlag 清除中断标识,否则会一直产生中断;
    		EXTI_ClearFlag(EXTI_Line0);
    	}
    
    }
    
    
    //中断函数,按一下亮,再按一下灭
    //int f1 = 0, f2 = 0, f3 = 0, f4 = 0;
    
    //void key_irqHandler(void)
    //{
    //	if (EXTI_GetITStatus(EXTI_Line0) == SET)
    //	{
    //		if (f1 == 0)
    //		{
    //			GPIO_SetBits(GPIOD, GPIO_Pin_0);
    //			f1 = 1;
    //		}
    //		else
    //		{
    //			GPIO_ResetBits(GPIOD, GPIO_Pin_0);
    //			f1 = 0;
    //		}
    //		EXTI_ClearITPendingBit(EXTI_Line0);
    //	}
    //	if (EXTI_GetITStatus(EXTI_Line2) == SET)
    //	{
    //		if (f2 == 0)
    //		{
    //			GPIO_SetBits(GPIOD, GPIO_Pin_1);
    //			f2 = 1;
    //		}
    //		else
    //		{
    //			GPIO_ResetBits(GPIOD, GPIO_Pin_1);
    //			f2 = 0;
    //		}
    //		EXTI_ClearITPendingBit(EXTI_Line2);
    //	}
    //	if (EXTI_GetITStatus(EXTI_Line3) == SET)
    //	{
    //		if (f3 == 0)
    //		{
    //			GPIO_SetBits(GPIOD, GPIO_Pin_2);
    //			f3 = 1;
    //		}
    //		else
    //		{
    //			GPIO_ResetBits(GPIOD, GPIO_Pin_2);
    //			f3 = 0;
    //		}
    //		EXTI_ClearITPendingBit(EXTI_Line3);
    //	}
    //	if (EXTI_GetITStatus(EXTI_Line4) == SET)
    //	{
    //		if (f4 == 0)
    //		{
    //			GPIO_SetBits(GPIOD, GPIO_Pin_3);
    //			f4 = 1;
    //		}
    //		else
    //		{
    //			GPIO_ResetBits(GPIOD, GPIO_Pin_3);
    //			f4 = 0;
    //		}
    //		EXTI_ClearITPendingBit(EXTI_Line4);
    //	}
    //}
    

    在这里插入图片描述
    实验框图:
    在这里插入图片描述
    演示视频:https://www.bilibili.com/video/BV1Pi4y1x7q1
    在这里插入图片描述

    展开全文
  • 密集异构网络通过加密部署小基站的方式提升空间复用,针对用户在小基站间频繁切换问题,提出了一种基于本地移动性的小区分簇网络...仿真结果表明,所提切换机制较当前切换方案减少了切换消耗,能有效降低切换中断时延
  • VOLTE语音时延问题定位

    千次阅读 2016-12-06 20:38:24
    现象两个终端拨打VOLTE存在语音时延的问题。其中,一个终端为4G VOLTE,位于SMC站下,另外一个终端为2/3G,位于宏站下。在此场景下,随着呼叫时间变长,极大概率出现4G终端接收到的语音延迟,时间为秒级,但是2/3G...

    现象

    两个终端拨打VOLTE存在语音时延的问题。其中,一个终端为4G VOLTE,位于SMC站下,另外一个终端为2/3G,位于宏站下。在此场景下,随着呼叫时间变长,极大概率出现4G终端接收到的语音延迟,时间为秒级,但是2/3G终端依然正常。

    定位

    尝试了其他场景,包括两路VOLTE(一个终端在SMC下,一个终端在宏站下以及两个终端都在宏站/SMC下),宏站下一路VOLTE一路2/3G,均未出现时延问题。首先,需要定位时延点是在核心网还是在基站设备。在出现问题的场景下,拔掉SMC的WAN口网线后,终端在几秒内仍然能够接收到语音,说明语音包已经到达了基站设备,缓存在了基站设备或终端中。
    在实验室进行复现,同时抓包,对比了交换机的镜像抓包以及基站内部tcpdump抓包,发现交换机的镜像抓包中,下行语音包以20ms的间隔均匀到达,在基站内部的tcpdump抓包中,存在攒包的现象,即较长一段时间内(几百毫秒级别),基站没有接收到任何网口数据,随后基站以极小的间隔收到了这一段的所有语音包。怀疑是由于网口的攒包现象,造成了语音时延。
    做了一个测试版本,在frwk接收UDP报文的代码中,手动增加时延。在出现问题的场景下,手动构造收包时延。发现构造时延后,终端果然出现语音延迟,至此,已经基本确认了产生语音延迟的直接原因。
    下一步,需要确认发生攒包现象的原因。又做了一个测试版本,可以手动创建一个指定优先级的任务,该任务持续执行死循环若干秒。在终端建立呼叫后,创建各个优先级任务进行测试,发现当创建的任务的优先级大于等于50时,终端出现时延,因此怀疑网口收包任务的优先级为50,在出现问题的场景下,存在高于这个优先级的任务持续运行的情况,随着时间积累,逐步到达影响通话的程度。

    解决

    咨询博通技术支持,得到网口接收任务的任务名irq/12-Timer1。博通的网口驱动同样采取中断+轮询的方式,博通使用定时器去触发轮询任务执行。在初始化脚本中提高该任务优先级至66后,手动创建优先级为65的任务执行死循环,不再出现语音时延的情况,确认修改有效。由于该任务优先级会影响到所有网口收包,因此技术支持并不建议将此调的过高。使用该版本升级后,呼叫保持2个半小时,终端语音时延不到1s。

    遗留问题

    在定位过程中,还有一些问题是没有解释清楚的:
    1. 为何只有一路VOLTE一路2/3G的情况下才会出现?
    使用手动构造时延的版本,在多个场景下进行了测试,均无法构造出语音时延。例如在两个终端都在小站下的情况,手动构造时延后,终端在手动构造时延期间无任何语音,随后语音立即恢复为当前语音,即时延过程中的语音丢失。而在出现问题的场景下,手动构造时延的现象是,时延结束后,终端语音变为时延时的语音,语音只是产生了时延而并没有丢失。
    2. 终端语音播放机制?
    从基站的行为来说,收包产生时延后,积攒的数据包会很快发送至终端,而非以20ms的间隔发送给终端(因为基站不区分语音和数据),因此,语音包应该是积攒在终端了。难道,终端在接收到语音包后完全不理会包到达的时间以及间隔,只是均匀地以20ms为间隔播放给用户,如果没有语音包就播空白音?
    3. 不同场景终端机制不同?
    但是,如果按照上面的分析,终端攒包的话,终端应该是分不清楚对方是2/3G还是VOLTE的,为何针对不通场景,终端表现还不一致?

    展开全文
  • 因此,结合IEEE 802.21媒体独立切换(MIH)协议提出一种基于L2触发的异构网络切换方案,通过NS-2仿真验证了L2触发的切换方案能有效减少切换时延和丢包,并评价了不同速度、不同预测系数对切换期间的中断概率、丢包率...
  • 根据阿里云底层监控,当一条跨可用区链路中断时,通常会导致持续3-5秒的1%左右的丢包(具体需要看中断链路数量占总链路数量的占比),而反映在业务上,则有可能造成时延敏感业务接近1分钟的部分超时报错。...

    前言

    作为阿里云底层提供的基础设施,内部的物理网络和许多网络产品在数据平面给客户的可操作性并不高,从一定程度上来说是个黑盒。当然,在传统的IDC环境,业务和物理网络之间也存在同样的隔阂。所以在遇到业务卡顿、延迟、不通等问题的时候,很容易怀疑到网络。因此如何抽丝拨茧,找到正确的方向对症下药才能够真正的解决问题。毕竟“真相只有一个”。

    在进行问题排查和处理的时候,难度最高的场景就是极度偶发,复现频率极低的问题。尤其在网络排查的领域,通常为了性能和控制资源消耗,不会将每一个数据包的情况都一一记录下来,对于一次偶发的应用层记录的超时,网络层通常没有明确的对应此次应用层调用的包交互记录,因此排查起来非常困难。

    在这次的案例中,我们通过一个客户端查询redis集群偶发超时的小案例,来说明一些诊断思路、排查手段,进而引出一些在网络方面提高业务稳定性的最佳实践。

    问题环境

    这次的问题是一个交互性web应用中的一个子模块,主要进行redis查询,可以简单将其理解为视频弹幕网站中“查询弹幕”的小模块。这个模块的拓扑非常简单:
    在这里插入图片描述
    在上面的拓扑中,客户使用ECS构建了一个Redis集群,前面用Codis实现了一层Redis Proxy (为了通用性,后面均用Redis proxy来描述),并将这组Redis proxy挂载在一个SLB后,通过SLB的单一入口提供服务。

    问题现象

    客户的主要问题是访问其自建Redis系统的客户端会不定期出现超时报错,尽管总体概率不高,但是报错概率高于其业务运行在原有机房的水平。超时报错主要有两种情况:

    1. 一般情况下超时数量与业务量呈正相关,非业务高峰期但是SLB、ECS的资源使用率均较低。
    2. 会存在突发性的大量超时。

    诊断思路

    作为问题排查的第一步,首先要了解到问题本身所处的上下文和环境。在平时诊断问题收集信息的时候,为了有条理的、全面的收集信息,笔者将需要收集的信息分为两种类型:资源因素和环境因素。

    • 资源因素:即发生问题的系统的拓扑。比如涉及的各种应用程序、主机、转发设备、链路资源等,并且要充分理解这些资源组建在拓扑中起到的作用。
    • 环境因素:即描述这个问题所需要的信息,比如报错日志,问题发生时间、频率,应用层设置的超时时间等等。

    了解资源因素和环境因素后,可以将问题的定义明确为:在哪些资源上发生了什么样的问题,然后根据该定义收集与问题相关的信息,并在解读和分析的时候通过数据排除所有的不可能,这样才能进行高效和准确的问题排查。

    在本案例中,资源因素已经在上文的拓扑中阐述,问题所涉及的环境因素包括:客户设置的是50ms超时,在客户端的报错是read timeout(代表排除了tcp的三次握手超时),报错频率为非业务高峰期一个小时10个左右,业务高峰期1小时上百个。但是偶尔(一周内偶尔发生一次到两次)无论业务高峰还是非业务高峰都会有较多的,上百次的read timeout和connect timeout。客户已经排查过redis,其查询时间每次耗时不超过10ms,而redis proxy没有记录转发的日志。

    排查方法

    因为所有可用的日志仅能定位到这个系统的两端(客户端、Redis),需要收集进一步的信息。面对这种超时类的问题,最直接、有效的办法就是进行抓包。而该问题发生的频率不高,整个系统流量也比较大,一直开着抓包很容易将磁盘撑满,因此需要使用循环抓包:

    tcpdump -i <接口|any> -C <每文件大小> -W <文件个数> -w <保存文件名> 抓包过滤条件
    

    该命令的意思是针对某个接口,按照过滤条件进行抓包,保存指定文件名前缀的文件下,最多占用每文件大小*文件个数 的磁盘空间并循环覆盖。开启循环抓包后,等待客户端报错再次出现,即可抓到现场的包交互过程。

    抓包的结果文件可以使用wireshark打开,但是使用循环抓包抓到的数据包文件较大、数量较多,可以使用下面的小技巧进行快速的过滤:

    //在安装了wireshark的电脑上都会有capinfos和tshark两个命令,以笔者使用的macOS为例
    ~$ capinfos -a -e *cap //使用capinfos查看抓包文件的其实时间和结束时间,选取包含报错时间+-超时时间的文件,其他文件就不需要了
    File name:           colasoft_packets.cap
    Packet size limit:   inferred: 66 bytes - 1518 bytes (range)
    First packet time:   2019-06-12 09:00:00.005519934
    Last packet time:    2019-06-12 09:59:59.998942048
    
    File name:           colasoft_packets1.cap
    Packet size limit:   inferred: 60 bytes - 1518 bytes (range)
    First packet time:   2019-06-12 09:00:00.003709451
    Last packet time:    2019-06-12 09:59:59.983532957
    
    //如果依然有较多文件,则可以使用tshark命令进行筛选。比如报错中提到Redis查询一个key超时,则可以用以下脚本找到这次查询请求具体在哪个文件中:
    ~$ for f in ./*; do echo $f; tshark -r $f 'tcp.payload contains "keyname"'; done
    

    找到对应的请求之后,再用wireshark打开该文件,找到对应数据包,跟踪对应流来找到五元组和整个流的上下文交互。

    在本案例中,通过对比客户端、redis proxy和redis 三层的抓包,发现客户端发出请求到收到响应的时间的确在问题发生时话费了100多ms,而这部分耗时主要发生在Redis将响应返回给Redis proxy的丢包重传导致。整体时序示意图如下:
    在这里插入图片描述
    对于从抓包中观察到的丢包现象,在通过阿里云内部监控确定了物理链路的确不存在丢包的情况下,我们发现Redis proxy所在的ECS上,虚拟化层面的后端驱动在向前端驱动送包的时候,前后端队列的丢包计数的增长趋势和业务超时的频率有相同趋势,进一步排查发现客户ECS操作系统内的网卡多队列没有开启,导致只有一个CPU处理网卡中断,而当流量有瞬间突增的时候,CPU来不及处理网卡中断导致前后端队列堆积,队列溢出后导致丢包。

    为了解决这个问题,我们建议客户将网卡多队列开启,并将不同网卡队列中断的CPU亲和性绑定在不同的CPU上。对于阿里云ECS,可以使用的网卡队列是和实例规格绑定的,具体可以参考ECS实例规格文档。简单的开启网卡队列并使用irqbalance 自动调度网卡队列中断CPU亲和性的方法可以参考阿里云官方文档

    本案例中客户开启网卡多队列并开启irqbalance服务之后,每小时都出现的访问超时问题已经解决,但是还是会有每隔几天会出现的突发性大量超时。经过汇聚客户的报错信息和阿里云底层的网络监控,我们最终确认这种每隔几天就会出现的突发性大量超时是因为阿里云底层的跨可用区间链路抖动导致的。

    阿里云的每一个可用区可以理解为是一个机房,而不同可用区之间可以互为同城灾备关系。为了确保可用区之间不会故障扩散,不同可用区机房需要保持一定物理机距离,并通过同城传输光缆将所有可用区相互连接实现可用区之间的互访。

    连接可用区之间的同城传输光缆的可靠性远低于机房内部跳纤,且经常容易受到道路施工、质量劣化的影响,导致链路中断。为了保证业务连续性,阿里云提供了充足的冗余链路并使用传输倒换、路由切换等技术确保部分跨可用区链路时故障可以自动收敛,但是在倒换过程中产生的丢包却无法完全避免。根据阿里云底层监控,当一条跨可用区链路中断时,通常会导致持续3-5秒的1%左右的丢包(具体需要看中断链路数量占总链路数量的占比),而反映在业务上,则有可能造成时延敏感业务接近1分钟的部分超时报错。因此在本案例中造成了突增的超时报错。

    假如客户使用资源时,可用区分布非常散乱,则会造成可用区间链路抖动对业务影响的频率升高。比如客户的客户端ECS分布在多个可用区(A、B),SLB在可用区C ,Redis proxy和Redis在可用区D、E,则A到C、B到C、C到D、D到E的跨可用区链路抖动都会影响到整个系统。

    最佳实践

    通过这个案例我们可以总结出关于主机网络和网络部署方面两个最佳实践:

    • 主机网络方面:打开网卡多队列并将网卡软中断打散以获取最佳的网络性能。总体来讲,为了获得稳定的网络性能,有以下通用建议:

    使用VPC实例:除了网络租户隔离、支持专线、VPN网关等好处外,VPC环境在底层转发能力上也比经典网络实例有大幅提高,最新一代实例均基于VPC环境实现,因此也提供了更强的网络转发性能。
    使用独享型实例:独享型实例采用严格的资源隔离技术,确保虚拟机不会收到“吵闹的邻居”影响。
    打开网卡多队列并绑定网卡软中断处理CPU亲和性:对于不同网卡队列使用不同CPU进行处理,提高网络处理性能
    将网卡多个队列分别绑定到某几个专用CPU上,而其他进程绑定到其他CPU上,让网卡软中断处理使用专门的CPU:适用于纯转发类、对网络性能要求极高的服务。

    //绑定网卡软中断的方法:
    //1. 首先看cat /proc/interrupts | grep virtio,在阿里云提供的标准操作系统中,virtio0是网卡队列
    ~$cat /proc/interrupts  | grep virtio
    //omit outputs
     31:  310437168          0          0          0   PCI-MSI-edge      virtio0-input.0
     32:  346644209          0          0          0   PCI-MSI-edge      virtio0-output.0
    //将第一列的中断号记录下来,修改下面的文件绑定CPU亲和性
    echo <cpu affinity mask> /proc/irq/{irq number}/smp_affinity
    //具体CPU affinity mask可以参考manpage https://linux.die.net/man/1/taskset,这里不再说明。
    
    • 物理网络方面:建议从业务容忍度和时延敏感度进行权衡来选择业务的部署。

    从业务容忍度的角度来说,如果tcp协议中发生了丢包,那么最坏情况下需要等待RTO超时才能够重传(tail drop场景,其他场景有fast
    retrans机制),而RTO超时的最小取值在kernel中的定义为200HZ,即200ms。对于内网互访或者同城互访这种时延较低的场景,可以理解为一次丢包的最坏情况就是200ms的重传,因此对于关键业务,至少将请求超时设置在200ms以上,让tcp有一次重传的机会。而对于非关键业务,一次查询是否返回数据并不关键的,则可以将请求超时设置的更小以便保护整个系统。因此业务容忍有两个方面:业务可以容忍错误,或者业务可以容忍重传。
    从时延敏感度的角度来说,为了确保时延敏感业务尽量少的受跨可用区链路影响,建议尽量将时延敏感业务的整个业务调用都在一个可用区内完成。而不同的可用区之间尽管提供相同服务,但是之间不会经常跨可用区调用。比如web
    server层调用提供缓存服务的Redis在本可用区完成,只有缓存没有命中的少量情况,才有可能跨可用区查询数据库,甚至使用只读实例等其他技术,将跨可用区链路抖动的影响降至最低。

    结束语

    通过上面的案例和最佳实践的说明,可以看到“权衡”在业务系统架构涉及和部署当中是无处不在的。所谓优化就是在给定的环境下,为了实现业务目标,将资源倾斜到最需要的地方。另一方面,对于许多客户在上云前的系统架构中,受限与机房成本、位置等原因,可能没有使用过多机房的组网场景,而云计算对这些客户带来的除了基础设施跨代升级的便利之外,还提供了天然的容灾能力,而业务系统的架构和部署也需要增加因容灾所带来的组网场景的复杂化。

    展开全文
  • 中断 为了对计算机的硬件(键盘,硬盘,鼠标等)进行管理,内核需要和这些硬件通信。一种方式是使用轮训(polling)的方式,这种方式周期性地查看所有硬件设备的状态并做相应处理,这会造成很多不必要的系统开销。...
  • 本方案通过将多播技术应用于移动锚点(MAP),并且在切换完成之前提前完成新链路上标签交换路径(LSP)的建设,实现了移动节点(MN)移交切换时延的最小化,使得在切换过程中大大降低服务中断现象,最大限度地保证新链路...
  • 最近在研究ramcloud,我对ramcloud的其中一个指标很感兴趣, ramcloud宣称能达到5us的读时延,记住这是读时延,不是写时延,写io由于复制到其他服务器,所以肯定比读时延要高. 写时延是15us, 这么低的时延,有一个前提条件,...
  • 微移动切换算法提出了一个交叉路由的切换方案,该方案可以减少延迟服务中断期间所发生的切换过程. 微移动切换算法的实现是移动节点在向前推进的过程中,预先为下一个节点发送资源请求以保留该移动节点切换 发生,...
  • Linux 中断

    2018-10-24 20:29:17
    Linux中断,时钟和延时 转载 https://blog.csdn.net/qq_40732350/article/details/83239069 1 概述 ############### 由于中断服务程序的执行并不存在于进程上下文中,所以要求中断服务程序的时间要尽量短。因此,...
  • Mobile IP在IP层提供移动支持,移动主机可以从一个地方移动到另一个...介绍了其中的几种,并提出了改进的方案:采用预先建立的隧道来降低切换时延,应用本地广播和FA处的缓存来减少丢包,利用提前的资源预留来保证QoS。
  • 内部中断中断源来自CPU内部(软件中断指令、溢出、除法错误等,例如,操作系统从用户态切换到内核态需借助CPU内部的软件中断) 外部中断中断源来自CPU外部,由外设提出请求。 可屏蔽中断与不可屏蔽中断...
  • Linux性能优化-中断

    千次阅读 2018-12-19 18:59:50
    中断
  • 中断与时钟

    2013-04-10 17:17:15
    本章主要讲解 Linux 设备驱动编程中的中断与定时器处理。由于中断服务程序的执行并不存在于进程上下文,因此,要求中断服务程序的时间尽可能地短。因此,Linux在中断处理中引入了顶半部和底半部分离的机制。另外,内核中...
  • 基于扩展EAP协议的异构网络切换协同认证机制,王磊,王莉,在异构无线融合网络中,当移动设备发生切换过程时,接入系统时的认证过程会带来的严重时延问题,甚至会造成通信中断。本文在研究
  • 1. 开发背景 现有开源缓存代理... 由于twemproxy无法利用多核特性,因此性能低下,短连接QPS大约为3W,长连接QPS大约为13W,同时某些场景时延抖动厉害。 为了适应公有云平台上业务方的高并发需求,因此决定借...
  • 引言随着越来越多的用户开始将关键业务迁移上云,部分关键业务的场景如大型 SQL 数据库、NoSQL、视频编解码、推理训练等业务对存储提出了稳定低时延、高性能的业务诉求,CBS 的产品矩阵...
  • 怎样切换内网DNS?

    2019-06-02 11:44:01
    同时,还可以不经Internet,直接通过内网DNS访问其他云上服务内部地址,如OBS、SMN等,访问时延小,性能高。 在内网域名功能上线之前创建的ECS服务器,其关联VPC子网默认设置的DNS服务器为公共DNS,IP地址为114.114...
  • 1. 开发背景    现有开源缓存代理中间件有... 由于twemproxy无法利用多核特性,因此性能低下,短连接QPS大约为3W,长连接QPS大约为13W,同时某些场景时延抖动厉害。    为了适应公有云平台上业务方...
  • 开发背景 现有开源缓存代理中间件有twemproxy、codis等,其中twemproxy为单进程单线程模型,只支持memcache单机版和redis单机版,都不支持集群...同时某些场景这些开源软件时延抖动厉害。 为了适应公有云平台上业务...
  • 中断处理程序是异步中断,被其中断执行的代码(包括别的中断处理程序)可能正在执行非常重要的任务,为了避免被中断进程停止过长时间,中断处理程序的执行应该越快越好。 中断处理程序会禁用其服务的中断线(没有...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,485
精华内容 1,394
关键字:

切换中断时延