RTS 임계 값, 조각화 및 기타 고급 WiFi 설정


19

배경 : 나는 시끄러운 환경에 있으며, 다소 많은 사용자 (바쁜 하루에 ~ 50-75)에 대해보다 안정적인 연결을 갖도록 WiFi 네트워크를 최적화하려고합니다. 4 개의 AP가 있으며 이미 채널과 전송 전력을 조정했으며 전반적으로 꽤 괜찮은 범위를 가지고 있습니다. 그러나 AP를 AP로 로밍하면서 Google을 핑 (ping)하고 건물을 돌아 다닐 때 여전히 패킷 손실이 약 10 % 정도 발생합니다.

내가 본 대부분의 WiFi AP에서 기본 RTS 임계 값은 2347 (여러 곳에서 읽은 것부터이 설정은 "비활성화 됨"으로 설정 됨)으로 설정되고 조각화 임계 값은 2346으로 설정됩니다. 내 특정 브랜드의 라우터 2346과 2346에 설정되어 있습니다. 몇 가지 질문이 있습니다 ...

  1. 2346의 값은 어디에서 파생됩니까? 그러나 Frag에 대한 메모는 다소 임의적 인 것으로 보입니다. 임계 값은 256 이상이어야하며 짝수 여야합니다.

  2. RTS와 Frag는 어떻습니까. 임계 값 관련? 그들의 가치는 우연 일 수 없습니다.

  3. 수정 된 경우 함께 변경해야합니까?

  4. 초보자를 위해 낮추는 것이 안전한 가치는 무엇입니까?

우선 각 장치의 최대 대역폭을 확보 할 필요는 없지만 사용자에게 안정적이고 일관된 대역폭 / 연결을 제공합니다.


1
혼합 된 b / g 네트워크를 운영하고 있습니까? 그렇다면 많은 문제를 설명 할 수 있습니다.
Greg Askew

예, B를 비활성화하거나 이러한 장치에서 최소 데이터 속도를 설정하는 방법은 없습니다.
Bigbio2002

답변:


15
  1. 최대 802.11 프레임 크기 는 2346입니다 . RTS 및 조각화 임계 값을 최대로 설정하면 패킷이 임계 값을 충족하지 않습니다.

  2. 조각화 임계 값은 최대 프레임 크기를 제한합니다. 이렇게하면 프레임을 전송하는 데 필요한 시간이 줄어들어 더 많은 데이터 오버 헤드가 발생하더라도 프레임이 손상 될 가능성이 줄어 듭니다. RTS 임계 값은 송신기가 RTS / CTS 프로토콜을 사용해야하는 프레임 크기를 지정하며 , 이는 주로 숨겨진 노드 문제 를 해결하는 데 사용 됩니다. 이것은 분명히 오버 헤드를 추가합니다.

  3. 숨겨진 노드 문제가없는 경우 RTS 임계 값을 변경해도 성능이 향상되지는 않습니다. RTS / CTS가 RTS 임계 값에서 시작되도록하려면 조각화 임계 값보다 작거나 같아야합니다.

  4. 표준 이더넷 프레임이 두 개의 802.11 프레임 (1500/2 = 750 바이트 페이로드 + 34 바이트 오버 헤드 = 784 바이트)으로 조각화되고 표준 이더넷 프레임의 1/3보다 큰 모든 프레임이 RTS (534)를 사용하도록 설정하는 것으로 시작하겠습니다. 바이트).

내가 아는 한,이 두 설정은 모두 송신기에만 영향을 미칩니다. 예를 들어 AP에서 설정하면 AP는 전송에 AP를 사용하고 클라이언트는 전송에 사용하지 않습니다.


2

혼합 된 b / g 시나리오는 특히 차선책입니다. 다음과 같은 주제에 대한 이전 토론 중 일부를 검토 할 수 있습니다.

가장 느린 무선 클라이언트가 다른 모든 것의 연결 품질을 지시합니까?

또한 지점 A가 지점 B의 신호를 수신 할 수 있지만 B가 A의 신호를 수신 할 수없는 경우 또 다른 성능 저하가 발생합니다. ServerFault의 다른 누군가가이를 "숨겨진 송신기 효과"라고 ​​지적했습니다. 아래 링크에서 해당 현상에 대해 자세히 알아보십시오. 그들은 다음을 지적합니다.

수평 편광이 바람직한 반면 "... 저렴한 상업적 수평 편파 무 지향성 안테나의 결여는 수직 편파 안테나를 사용할 필요가있다. 좋은 전 방향성 수직 편파 안테나 파라볼라 안테나 거의 같은 요할 것이다. 사용 전 방향성 안테나는 "숨겨진 송신기"효과를 최소화하는 데 도움이됩니다. "

http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules


0

"숨겨진 노드 문제가없는 경우 RTS 임계 값을 변경해도 성능이 향상되지 않는다"는 것에 동의하지 않습니다. CTR / RTS를 사용하면 항상 데이터 충돌 가능성이 줄어 듭니다. 모든 데이터 충돌로 인해 데이터가 손상되어 데이터를 다시 보내야하므로 충돌이 적다는 것은 데이터를 다시 보내지 않고 데이터를 다시 보내지 않으면 WiFi 성능을 크게 향상시킬 수 있습니다. 물론 네트워크에 눈에 띄는 충돌이있는 경우에만 가능합니다.

세부 사항을 설명하려면 : 노드는 항상 일정 시간 동안 대기하고 자신의 채널을 지정하기 전에 가능한 전송을 위해 채널을 감지해야합니다. 전송이 감지되지 않는 경우에만 자체 전송을 시작할 수 있습니다. RTS / CTS가 없으면이 전송은 직접 데이터 전송입니다. 이제 두 노드가 모두 동일한 아이디어를 가지고 있고 거의 동시에 데이터 전송을 시작하면 이러한 전송이 충돌합니다. 결과적으로, 수신 된 모든 데이터가 다른 모든 노드와 AP에 대해 손상되기 때문에 어느 쪽도 전송으로 전송되지 않습니다.

RTS / CTS가 사용되는 경우, 센싱 후에 노드가 RTS 패킷을 전송하여 전송이 시작됩니다. 해당 RTS 요청이 CTS 응답으로 응답 된 경우에만 데이터 전송이 시작됩니다. 물론 두 노드가 동시에 전송하려는 경우 RTS 요청은 RTS가 전혀 수신되지 않는 것과 동일한 부정적인 영향을 줄 수 있습니다. 차이점은 전체 네트워크가 데이터 충돌보다 RTS 충돌에서 훨씬 빠르게 복구된다는 것입니다. 따라서 RTS 충돌은 데이터 충돌보다 전체 네트워크 성능에 덜 해 롭습니다.

단점은 RTS / CTS 자체에는 자체 네트워크 대역폭이 필요하며 다른 데이터 전송이나 RTS / CTS 전송이 발생하지 않는 새로운 감지 시간이 발생한다는 것입니다. 설상가상으로, 물론 RTS / CTS는 항상 네트워크가 지원하는 가장 느린 속도를 사용하여 수행되어야합니다. 그렇지 않으면이 속도 만 지원하는 노드는 볼 수 없습니다. 따라서 기본적으로 RTS / CTS는 항상 전체 네트워크의 이론적 처리량을 낮춘다 고 말할 수 있지만 네트워크가 숨겨진 노드 문제 (동일한 네트워크를 사용하는 다른 노드의 노드로 인해 발생할 수 있음)로 인해 많은 충돌이 발생하는 경우 더 많은 노드가 임의의 충돌 가능성을 증가시킬수록 실제 처리량이 증가 할 수 있습니다. 숨겨진 노드의 수가 아니라

나는 연구를 읽었습니다 (다시 찾을 수 있었으면 여기에 링크를 업데이트하고 추가 할 것입니다). 네트워크가 실제로 작지 않은 경우 (6 개 미만의 노드와 작은 영역 만 포함하지 않는 한) 다른 것으로 격리되지 않았 음을 제안합니다 RTS / CTS를 사용하는 동일한 채널을 사용하는 네트워크는 실제로 거의 항상 긍정적 인 영향을 미칩니다. 왜 임계 값입니까? 데이터를 보내는 데 RTS / CTS 핸드 셰이크보다 많은 시간이 걸리는 경우 네트워크가 아주 작은 데이터 충돌에서 복구해야하는지 또는 RTS 충돌에서 복구해야하는지에 따라 RTS / CTS를 사용하면 별다른 이점이 없습니다. 많은 차이가 있습니다. RTS 충돌에서 더 나은 복구는 RTS 패킷이 매우 작고 데이터 패킷이 일반적이지 않기 때문입니다. 그러나 매우 작은 데이터 패킷의 경우 RTS / CTS는 실질적인 이득없이 오버 헤드를 추가합니다.

이제 조각화 임계 값이 어떻게 네트워크 성능을 향상시킬 수 있는지 알게되었습니다. 한편으로는 전송되는 패킷의 크기를 제한하며 위에서 설명한 것처럼 충돌시 패킷이 작을수록 네트워크가 더 빨리 복구됩니다. 반면에 충돌이 발생한 경우 전체 패킷이 아닌 충돌이 발생한 조각 만 다시 보내면됩니다. 그러나 전송되는 모든 조각에는 고유 한 오버 헤드가 있으므로 조각이 많을수록 더 많은 오버 헤드가 발생하고 오버 헤드는 기본적으로 데이터 전송에 사용될 수있는 대역폭 낭비입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.