저는 교실 Wi-Fi 시스템의 부하 테스트를 준비하고 있습니다. 학생들은 수업이 시작될 때 모두 노트북을 켜고 웹 브라우저를 시작한 다음 수업을 시작합니다. 여기에는 플래시 기반 수업(학교 내 서버에서)을 다운로드하는 과정이 포함되며 일반적으로 다운로드 용량은 절반에서 2MB입니다.
어떤 경우에는 로드 시간이 5~10분까지 늘어납니다. 따라서 시스템의 모든 부분을 모니터링하여 병목 현상이 있는 위치와 단일 Wi-Fi 액세스 포인트를 합리적으로 사용할 수 있는 클라이언트 수는 몇 명인지 자신 있게 확인하고 싶습니다. 그래서 우리는 최대 50명의 클라이언트를 대상으로 테스트를 실행하고 어떤 일이 일어나는지 확인할 계획입니다. (대부분의 사람들이 액세스 포인트당 20-25개의 클라이언트를 권장한다는 것을 알고 있지만 클라이언트는 이를 테스트하고 싶어합니다. 그리고 클라이언트에게 보여줄 좋은 데이터를 얻고 싶습니다. 어떤 식으로든).
나는 이미 서버를 모니터링하는 방법을 알고 있습니다. Wi-Fi 액세스 포인트는 SNMP를 지원하고 꽤 많은 변수를 제공하는 것 같지만 너무 많이 헤쳐나가고 싶지는 않습니다.
따라서 문제는 시스템이 과부하되는 경우, 클라이언트가 대기 중인 경우, 충돌이 발생하는 경우 등을 특성화하기 위해 모니터링해야 하는 주요 Wi-Fi 관련 변수는 무엇입니까?
거기에 있어야 할 일반적인 이름을 듣고 파일을 직접 검색하게 되어 기쁩니다. 그러나 세부 사항을 보고 싶거나 필요하다면 우리가 사용하는 액세스 포인트는 다음과 같습니다.유비쿼터스 나노스테이션 2. Ubiquity 제품의 MIB 파일은 하단에 링크되어 있습니다.그들의 SNMP 페이지. 나는 또한 그들이 적어도 일부를 지원하는 것 같다는 것을 발견했습니다.미크로틱 MIB.
답변1
간단한 접근 방식은 IF-MIB::ifInOctets.<ifIndex>/ IF-MIB::ifOutOctets.<ifIndex>OID를 주기적으로 모니터링하고 사용 가능한 대역폭을 확인하는 것입니다. 연결된 MikroTik MIB에서 mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>및 mtxrWlStatRxRate: 를 읽어 현재 설정된 속도를 확인할 수 있습니다 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>. 물론 이것은 무선 세부 사항을 고려하지 않지만 인터페이스에서 사용 가능한 총 대역폭이 병목 현상인지 여부(전체 채널 용량에 가까운 사용량을 볼 수 있는 경우일 가능성이 높음)에 대한 대략적인 아이디어를 제공할 수 있습니다.
일반적으로 스테이션이나 안테나의 위치가 좋지 않고 선택한 채널의 주파수에서 에테르가 깨끗하지 않은 한 단일 G 채널(54MBps 2,4GHz)에서 대략 2-3MB/s의 처리량을 기대할 수 있습니다.
AP 측의 재시도 및 오류에 대한 보다 구체적인 정보가 필요한 경우 dot11CountersIEEE802dot11 MIB의 테이블, 특히 해당 인스턴스의 및 값 dot11RetryCount을 읽을 수 있습니다.dot11MultipleRetryCountdot11FailedCount
802.11에는 충돌이 없지만 물리적 캐리어 감지 및 선택적으로RTS/CTS 핸드셰이크프레임을 전송하기 전에. 모니터링하면 dot11RTSFailureCountCTS가 RTS 요청에 얼마나 자주 응답하지 않아 송신 스테이션에 채널을 부여하지 않는지 대략적으로 알 수 있습니다.
대부분의 트래픽을 생성하는 액세스 포인트인 경우(즉, 스테이션이 주로 데이터를 수신하는 경우) 상대적으로 낮은 양의 재시도 및 RTS 실패를 볼 수 있습니다. IF-MIB::ifOutDiscards.<ifIndex>무선 인터페이스나 유선 인터페이스를 살펴볼 수도 있습니다. IF-MIB::ifInDiscards.<ifIndex>이 숫자는 버퍼가 가득 차서 추가 프레임을 수신할 수 없을 때마다 증가합니다(즉, AP는 최대 속도로 전송하지만 이더넷 인터페이스에서는 프레임을 전송합니다). 더 빠른 속도로 계속 도착하세요).
답변2
당신이 하려는 것이 AP에 과부하가 걸렸다는 것을 클라이언트에게 증명하는 것뿐이라면 dot11RetryCount 및 dot11MultipleRetryCount OID를 사용할 수 있습니다.
dot11RetryCount - 1.2.840.10036.2.2.1.4
dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5
이를 통해 공기가 얼마나 혼잡한지 대략적으로 추정할 수 있습니다. 재시도 횟수가 dot11TransmittedFrameCount의 약 10%를 초과하면 속도가 느려지기 시작합니다.
다음은 Cisco의 MIB 개체 워커입니다. 검사할 다른 OID를 알아내야 하는 경우 도움이 될 것입니다.