odroid u2 Utility backup & RTL8188EU Setting

fan control script : set_odroid_fan.sh
명령어로 치면
$ sudo echo manual > /sys/devices/platform/odroidu2-fan/fan_mode
$ sudo echo 255 > /sys/devices/platform/odroidu2-fan/pwm_duty
하면 풀로 돌아갑니다.
USB에 뭔가를 꼽았을때, HDMI와 혼선을 일으키는 경우가 많고, 기본적으로 FHD에서는 성능 문제인지 껌뻑임이 많으므로, /mnt/boot/boot.ini 에서 1280x720p 모드로 설정하는게 좋습니다. 여러가지 이유로 EDID설정보다는 non-EDID로 그냥 ODROID에 설정된 porch값을 쓰는게 좋습니다. 디스플레이에서 정해주는 EDID정보대로 ODROID가 맞춰주기가 힘들거든요… 드라이버가 범용성이 좀 떨어져서요… 왜냐면.. 개발해봤으니까….

최근에 이마트와 다이소 등지에서 USB LAN을 산것이 있습니다. 우연힌지는 모르겠지만, TP-LINK 725WN -> RTL8188EUS 이고
다이소 5000원짜리도 RTL8188EUS이네요. 예전에 롯데마트에서 샀던 건 RTL8188CUS였고요. 왠만한 싼 802.11n 지원 usb lan카드는 이것이 많은 것 같습니다.
Odroid U2 Mate 16.04 LTS에는 RTL818x -> rtl8187.ko 만 깔려 있고, 아래 드라이버 설치후 활성화하면 사용가능합니다만,, 유선 환경이 안되면, 참 힘들죠. 기본적으로 가장 좋은건 RTL8192나 RTL8812칩셋을 쓴것인데, Iptime A2000UA가 RTL8812AU라 하나 구비해두면 편합니다.

sudo modprobe 8188eu

참고글: https://www.thelinuxrain.com/articles/getting-realtek-8188eu-wireless-adapters-to-work-in-linux-and-possibly-other-wireless-realtek-chipsets

아래 사이트에 첨부된 드라이버 : rtl8188eu-master

https://community.linuxmint.com/tutorial/view/1344

2018/8/11자로 다운로드 받은 드라이버 소스코드 내부 readme.md 파일 참고 : rtl8188eu-master

최소한 build-essential & git정도는 설치를 해야하고, 기본적인 시스템 업데이트도 필요합니다.
sudo apt install build-essential

드라이버 소스코드 배포 github : https://github.com/lwfinger/rtl8188eu

 

알고리즘 이것저것 공부하고 문제풀다가 심심해서 만들어 본 무조건 덧셈.

그냥 이래저래 알고리즘 공부하다가 또, 이전에 Deep Learning공부하던것도 떠오르며 드는 생각은 알고리즘은 꽤나 옛날~ 70년대도 전에 만들어지고, 현재에도 유용하게 사용하는 것들이 많은데, 그때의 문제 공간과 요즘의 문제공간, 그리고 환경이 다르다는 것을 다시 떠올려보고, 여태 잘 쓰이고 있는 이유를 생각해보면서, 아무래도 모든 문제는 공간과 시간의 문제인것으로 결론을 내려봤습니다. 과거의 공간보다 현재의 공간이 더 확장되고, 그만큼 시간도 늘어난 것 같습니다. 컴퓨터는 계속 발전하여, 공간(물리적인 부분)*시간(논리적인 부분)의 가용한 총량을 계속 늘려주고 있는 셈인거고요.

그리고는 그냥 막무가내로 1부터 UINT_MAX까지 더해보는 프로그램을 짜봤습니다. 십몇년전, 학생시절, 또 그보다더 어린시절에도 해봤던 것 같은데, 그때는 엄두가 안 났던것을 그냥 가볍게 할 수 있는 세상이네요. 현재 돌려본 PC는 페넘2 HexaCore 2.8Ghz(boost 3.1Ghz)입니다. 복잡하게 짠게 아닌데, Window10이 똘똘한건지, CPU3개정도가 50%를 찍으며 돌아가네요.

sum(1:4294967286) 의 결과가 78905.8ms가 나옵니다. 연산이 길어서 IO출력은 무시해도 될 것 같고요. 거의 cache내에서 add compare2회 정도가 돌았을 것이라서, 효율이 좋았을 것을 생각한다면.
4294967286/78905.8ms = 54431579 operation-set / second 가 나오네요. 기준 클럭으로 돌았다고 생각하면, 54431579/2800000000 = 0.0194 instruction per clock정도가 나오는데. 대충 디스어셈블 해서, 루프내의 명령이 얼마정도 돌았나 싶은가 세보면, 대강 25개정도가 거의 꾸준히 동작하고 있었을거로 보면. 0.388 instruction / clock  가 되겠네요. IPS로 다시 환산하면, 54431579*25 Instruction/sec = 1360MIPS정도 되네요.

너무 값이 안나온다 싶어서, 중간 IO빼고 돌려봤습니다. 12396.5ms가 나오고, 디어셈해서 명령어 개수는 13정도되네요.   4294967286 * 13/12396.5 ms = 4505MIPS라고 나오니. IO가 눈으로 보이는게 별로 없어도. 그걸 처리하는데 시간 쏟은게 많았던 듯 합니다.

똑같은 코드를 ODROID에서 한번 돌려보렵니다…. 뻗으면 안되는데 –;;

—- 2018/08/14
중고 구매한 Thinkpad X230T에서 돌려봤습니다. I5-3320M 인데, 대략 돌리는 동안 4Thread 45%정도 유지하고, 2Ghz로 동작하네요. Windows 기본속도는 2.6Ghz인데 Full로는 못 뽑나봅니다. 시간은 IO없이. 11972.1ms 가 나오네요.. 빠르네요. 모바일 프로세서인데 2012년도 생산이라 1055T보다 2년 뒤에 나왔을 뿐인데…

—- 2018/8/15
샤오미북 프로 15 에서 확인한 결과. I7-8550 쿼드코어 옥타쓰레드 에서 50%로 3.7Ghz full boosting으로 돌고 대략 9000ms가 나옵니다…. 중간 io안찍을때가 그런건데… 중간중간 출력코드 활성화 해도 14334ms정도가 나오네요… OS는 같았으니, 뭔가 다른 차이가 있는건지 모르겠네요.

코드 붙여 봅니다. Crayon Syntax highlighter를 설치했습니다. 2년전에 업데이트 되고 업데이트가 없는데. 다른 프로젝트로 옮겨간건지.. 취업한건지.. 아무튼 사용은 잘되는것 같고요..

디어셈블 코드는 아래와같이 나오네요.

 

알고리즘 자료구조 열공이 거의 끝나갑니다.

지금껏 거의 2주간 배운것들을 정리해보려합니다. 장황한 설명들은 다른 좋은 학교, 교수님, 블로그글에 있으니, 단어장 정리수준으로 언제/왜 써야 되는지에 집중해서 적어보려합니다.

  • Segment Tree

간략 설명: 특정한 범위를 표현하고 이를 Tree의 인덱스에 지정하고 이른 트리구조로 관리함, 각각의 인덱스에 매핑되는 값 혹은 특정한 데이터를 꺼내는 형태로 자료를 관리함. 트리는 인덱스를 기준으로 양쪽이 균등한 형태를 갖도록 구성함. 실제 노드는 배열로 구성시 배열의 인덱스와는 다름. 특정 구조체의 배열로 구현하여 사용하거나, 링크형태로 연결관계만 유지하고, 실제 데이터는 따로 담는 방법이 있겠음.

언제: 트리구조를 이용하므로, 검색시간이 O(N)->O(LogN)정도로 줄어드는 장점이 있고, 각각의 Range별 특정한 사전 연산등을 통하여, 값을 빠르게 얻을 수 있음. 대표적인 사용예를 특정구간의 합 또는 최대값을 구하는 용도로 사용. 메모리에 비교적 여유가 있다면, 각 노드에 직접 데이터를 담아서 사용하는 것이 노드 탐색시 처리할 수 있도록 하여 좋음. LIS구할때 자주 사용함. 전봇대 전선 교차 제거 문제 – 한쪽을 기준으로 소팅하고 반대쪽 연결 수열의 LIS를 찾는것이 교차되지 않는 전선들을 찾을 수 있음. 그외는 제거 대상

  • TRIE
  • 아이디어 또는 트릭 목록

Binary Search/Tree -> O(N) -> O(LogN)으로 전환하는 개념. 나누고 합하는 개념이 들어가고 공간상으로 넓게 퍼뜨려 시간을 절약하는 방법. MergeSort, BinarySearch, BinaryTree,

Memoization : 여러번 반복하여 상태가 변화하고 해당 상태에 따라서 다음번 결과가 바뀌는 경우, 각각의 상태의 결과를 따로 저장해두었다가 다시 사용하는 방법, 단일한 Path가닌 여러 path로 상태가 영향을 줄 경우에 유용함.

Early Determination/ Lazy Propagation: 트리등의 값 변경, 작업의 스케쥴이 여러건 들어오고, 데이터의 포맷이 같고. 당장 상태 변경이 필요치 않으며, 입력에 대한 출력만 요구하고, 출력을 100% 정확하게 사전에 예상할 수 있는 방법이 있을 경우, 그리고 차후에 상태 변경을 하여도 무방한경우 사용