테스트 대상 기기: 삼성 갤럭시 노트3 네오, LGU+ (SM-N750L)
Android 버전: 4.4.2
스마트폰을 통한 네트워크 실험을 하는 과정에서, 여러 차례 와이파이에 연결된 스마트폰에 ping을 날려야 하는 경우가 있었다. 화면이 꺼져 있더라도 옵션을 통해서 와이파이에 항상 연결되어 있게 할 수는 있는데, 유독 화면이 꺼져 있을 때에 ping 속도가 느린 것 같다는 느낌이 들어서 실제로 테스트를 해 보았다.
샘플 수가 20개라서 사실 많지는 않지만, 그래도 동일한 환경에서 주변에 다른 방해하는 기기가 거의 없는 새벽 시간대에 해 본 것이라서 어느 정도 의미는 있을 것으로 생각한다.
테스트 환경으로, 라즈베리파이 2B에 hostapd를 돌려서 가상 AP로 만들고, 스마트폰이 그 AP에 연결되도록 했다.
라즈베리파이는 Raspbian Jessie 운영체제에 Atheros ath9k-htc 기반의 USB 무선랜카드를 달고 있고, IEEE 802.11n 모드로 AP를 돌렸다.
테스트용 스마트폰 외에 무선으로 연결된 다른 연결된 기기는 없었다.
아래는 화면이 꺼져 있을 때, 의 ping 결과이다.
pi@raspberrypi ~/exp $ ping 10.0.5.10
PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.
64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=289 ms
64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=113 ms
64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=344 ms
64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=157 ms
64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=204 ms
64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=164 ms
64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=188 ms
64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=9.65 ms
64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=237 ms
64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=276 ms
64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=80.7 ms
64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=105 ms
64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=126 ms
64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=205 ms
64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=220 ms
64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=258 ms
64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=254 ms
64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=290 ms
64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=312 ms
64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=135 ms
^C
--- 10.0.5.10 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19025ms
rtt min/avg/max/mdev = 9.658/198.845/344.289/84.791 ms
아래는 스마트폰 화면을 켜고, 바탕화면을 전환하거나 카카오톡 앱을 한번 켜 보는 등 화면을 켜져 있도록 유지했을 때의 ping 결과이다. 카카오톡을 켤 때 잠시 서버에 접속하는 경우를 제외하고는 스마트폰에서 별도로 트래픽을 발생시키지 않았다.
pi@raspberrypi ~/exp $ ping 10.0.5.10
PING 10.0.5.10 (10.0.5.10) 56(84) bytes of data.
64 bytes from 10.0.5.10: icmp_seq=1 ttl=64 time=146 ms
64 bytes from 10.0.5.10: icmp_seq=2 ttl=64 time=67.5 ms
64 bytes from 10.0.5.10: icmp_seq=3 ttl=64 time=81.2 ms
64 bytes from 10.0.5.10: icmp_seq=4 ttl=64 time=133 ms
64 bytes from 10.0.5.10: icmp_seq=5 ttl=64 time=128 ms
64 bytes from 10.0.5.10: icmp_seq=6 ttl=64 time=147 ms
64 bytes from 10.0.5.10: icmp_seq=7 ttl=64 time=175 ms
64 bytes from 10.0.5.10: icmp_seq=8 ttl=64 time=98.5 ms
64 bytes from 10.0.5.10: icmp_seq=9 ttl=64 time=109 ms
64 bytes from 10.0.5.10: icmp_seq=10 ttl=64 time=9.62 ms
64 bytes from 10.0.5.10: icmp_seq=11 ttl=64 time=66.1 ms
64 bytes from 10.0.5.10: icmp_seq=12 ttl=64 time=81.9 ms
64 bytes from 10.0.5.10: icmp_seq=13 ttl=64 time=108 ms
64 bytes from 10.0.5.10: icmp_seq=14 ttl=64 time=139 ms
64 bytes from 10.0.5.10: icmp_seq=15 ttl=64 time=146 ms
64 bytes from 10.0.5.10: icmp_seq=16 ttl=64 time=75.2 ms
64 bytes from 10.0.5.10: icmp_seq=17 ttl=64 time=5.52 ms
64 bytes from 10.0.5.10: icmp_seq=18 ttl=64 time=4.06 ms
64 bytes from 10.0.5.10: icmp_seq=19 ttl=64 time=4.30 ms
64 bytes from 10.0.5.10: icmp_seq=20 ttl=64 time=188 ms
64 bytes from 10.0.5.10: icmp_seq=21 ttl=64 time=78.3 ms
^C
--- 10.0.5.10 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20028ms
rtt min/avg/max/mdev = 4.062/95.085/188.859/54.672 ms
최소값, 최대값, 평균 모두 차이가 남을 알 수 있다.
평균을 기준으로 대략 2배 가량 전송시간(round trip time)의 차이가 발생했다.
참고로 같은 증상이 삼성 갤럭시 넥서스(버전 4.1.1)에서도 나타났다.
무슨 연유로 어디에서 이러한 지연이 발생하는지는 정확하게 알 수 없다. 하지만 아마도 스마트폰에서 의도적으로 지연을 발생시켰을 것으로 예상되며, 그 이유는 여러가지가 있겠지만 에너지 절약 차원의 목표가 있을 것이라고 추측만 하고 있다.
네트워크 실험을 할 때에는 (물론 화면을 끄고서 실험할 일은 거의 없겠지만) 스마트폰 화면의 꺼짐 유무도 잘 확인하는 것이 좋겠다.
'IT > Android' 카테고리의 다른 글
삼성 갤럭시 스마트폰의 블루투스 볼륨 동기화 해제 방법 (8) | 2018.08.13 |
---|---|
갤럭시노트8 앱서랍에서 홈화면 이동 시 버벅이는 증상 (2) | 2018.08.07 |
악질 앱 고발: 삼성 와치온(Watch On), 삼성 갤럭시 사용자에 한함 (0) | 2015.07.22 |
쓸데없이 배터리를 잡아먹는 안드로이드 OK 캐시백(Cashbag) 앱(버전 5.3.0) (2) | 2015.06.30 |
안드로이드 운영체제의 배터리 사용량이 매우 높을 때 (2) | 2015.06.20 |