UGC Edition 중 하나의 속도가 몇 K에 불과한 BUG 분석

1743 단어 서버float
최근 UGC 프로젝트를 진행하면서 UDP 프로토콜을 사용하여 업로드를 했고 다음과 같은 간단한 체증 제어를 했습니다.
1. 각 세션마다 현재 계산된 전송 속도에 따라 균등하게 발송되는 발송 대기열이 있다
2. 서버는 1초에 하나의 제어 메시지를 되돌려줍니다. 포함된 정보는 서버가 데이터 패키지를 수신하는 속도와 패키지 분실률 등이 있습니다.
3. 클라이언트는 서버가 되돌아오는 제어 메시지에 따라 발송 대기열의 데이터 패키지의 발송 속도를 조정한다
오늘 한 대의 기계가 갑자기 한두 KB의 업로드 속도만 나타나는데 이것은 분명히 문제가 있다. 정상은 상행 대역폭을 가득 차지해야 한다.또한 오버타임 재전송된 패킷은 전체 대역폭 업로드 시간보다 오히려 N배 많습니다.이게 이상해!이치대로라면 발송 속도가 이렇게 느리면 시간 초과가 더 적어야 한다.
나중에 진지하게 분석하고 원인을 찾았습니다. 잊어버리지 않도록 기록하세요.
왜 몇 K밖에 안 올라와요?
발송 대기열의 발송 속도는 서버 분실률에 따라 조정되기 때문에 코드는 다음과 같다.
				if(lost < 5.0f)
				{
					send_speed	*= (110.0f - lost) * (110.0f - lost) / 10000.0f;
				}
				else
				{
					send_speed	*= (110.0f - lost ) / 100.0f;
				}

여기서 send_스피드는 부동점형.
이를 통해 알 수 있듯이 가방 분실률이 5%보다 적을 때는 1.1에서 1.2배로 증가하지만, 가방 분실률이 5%보다 크고, 특히 크면 발송 속도가 급격히 떨어지기 때문에 폭등세를 늦추고 있다.
그러면 결국send_스피드가 1인 결과.
코드를 보면 천천히 올라가도 속도가 바로 올라가야 하는데 왜 안 올라가지??
허허, 사실 서버가 되돌아오는 패키지 분실률도 진정한 패키지 분실률이 아니라 1초 동안 서버가 받지 못한 패키지입니다. 그러면 실제 잃어버린 패키지와 길에서 잃어버린 패키지가 포함됩니다.
이제 1초에 1~2개의 가방을 보내면 길에 있는 데이터 가방의 확률이 크게 높아진다.예를 들어 1초에 가방을 두 개밖에 보내지 않았는데, 그 중 하나가 아직 길에 있는데, 이 가방을 잃어버리는 확률이 50%인데, 속도가 어떻게 올라갈 수 있겠는가?
그리고 송신 대기열의 송신 속도는 DWORD,float가 DOWRD로 바뀌었고 1시 몇 분의 값이 모두 하얗게 올랐습니다. 모두 1입니다.
왜 코드가 이렇게 쓰였는지 나는 사건이 이렇다고 말할 수 밖에 없다. 네가 믿든 안 믿든 어쨌든 나는 믿는다.
왜 발송 속도가 느리고 시간 초과가 오히려 많습니까?
두 점 사이의 RTT는 사실 매우 작기 때문에, 나의 시간 초과 값은 4배의 RTT이기 때문이다.대기열에서push 16개의 가방을 보낼 수 있고, 가방 하나를 보내면push 1개의 가방을 보낼 수 있다.자, 이제 1초에 가방 두 개만 보낼 수 있고, 시간 초과는 대기열에 넣을 때부터 계산합니다. 그러면 대기열에 있는 시간이 4RTT보다 많습니다.
뒷말:
이렇게 좌절된 코드를 나도 어쩔 수 없었다. 맏형은 나에게 4일을 다 쓰라고 했고, 능력이 제한된 나는 초과 근무를 해서 거의 2주가 걸려서야 다 썼기 때문에 이런저런 오류가 생길 수밖에 없었다.맏형은 안색이 안 좋아서 나도 피곤해...

좋은 웹페이지 즐겨찾기