차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- o_buntu:o_buntu [2013/03/26 01:07] – [소개] tower119
+++ o_buntu:o_buntu [2013/12/11 00:46] (현재) – 바깥 편집 127.0.0.1
@@ 줄 11: / 줄 11: @@
 생각
-. 여러가지 config중 어디 까지 지원을 해주는가?
+. 여러가지 configurate 어디 까지 지원을 해주는가?
 . A컴퓨터의 설정이 B컴퓨터에서 적용이 되는지 고려해야 할 변수가 너무 많다.
@@ 줄 21: / 줄 21: @@
 . 특정 하드웨어에 종속되는 부분 또한 매우 중요하다. 특정 하드웨어라 해서 Cam이나 Printer와 같은 다소 unique한 디바이스 뿐만 아니라 그래픽 하드웨어의 드라이버 지원에 따른 2/3D 가속 등 좀 더 일반적인 사례 여러가지가 있다.
+. 4. 15
+Samba (http://www.samba.org) 개선
+삼바는 느리다.
+핸드폰으로 자주 이용 하는데, HTTP나 FTP에 비해 매우 느림.
+기존 파일 뷰어 인터페이스가 편해서 쓰지 대용량 파일 전송 시에는 느리니까 안 씀.
+그러니 빠르게 해보자!!
+. 삼바 분석 - 삼바는 왜 느린가?
+) 네트워크 대역폭(bandwidth)을 얼마나 차지하는지 테스트
+    * 내부적으로 이루어지는 프로토콜 변환 자체가 느린 것인지?
+    * 기존 SMD(윈도우 기존 프로토콜)같으면 일반적인 Payload가 될 데이터에 추가적인 Header가 왕창 붙어서 대역폭을 차지해버리는지? -> 윈도우 측에서는 뭐가 오던 간에 동일한 SMD프로토콜로 해석해야 하기 때문에 아닐 듯?
+    * 위 두 가지 이유가 겹쳐서?
+    * 아니면 다른 이유 때문에?
+) 프로파일링 해보자
+    * 멤버십 내부 내트웍으로 테스트 하면 외부 변수가 많기 때문에 VM으로 띄워서 host(윈도우), guest(리눅스)간 전송 해보기
+    * 비교 대상은 FTP, 윈도우 host to 윈도우 guest
+    * 그런데 이걸 어떻게 프로파일 해야 되나?
+    * 프로파일러로 돌려본다? -> 프로파일러는 하나의 패킷이 어느 과정을 걸쳐 가는지 따위는 관심 없다.
+    * 이태리 장인 정신으로 한 줄 한 줄 Source trace? -> 언제 다 하나
+. 분석을 했으면 해결책을 찾자
+   * 지금 개인적인 생각으로는 프로토콜 변환 자체가 느린 것 같음.
+   * 어떻게 개선 해야 하나? -> 새로 만든다. 그런데 이 복잡한 걸 만들 수는 있나?
+   * 좀 바꾼다. -> 10년이 넘는 시간동안 개선되온 프로젝트인데 우리가 개선할 수 있나?
+그런데 이놈의 편집기는 레알 거지 같다.
+.04.24
+아이디어 1
+빅 데이터 처리를 위한 기본 환경을 갖춘다.
+이를 테스트 하기위해 핸드폰 앱 통계 어플을 제작하여 빅 데이터 인프라를 테스트 한다.
+www.tgrape.com에서 베타 서비스 중 (http://fingra.ph)
+아이디어 2
+Xen hypervisor를 위한 커널을 제작, 또는 수정 한다.
+아이디어 3
+ARM보드들을 클러스터링 하여 그 위에 하나의 Hypervisor을 설치하여 운용한다.
+OR
+각각의 ARM보드에 Hypervisor을 설치하고 Management할 수 있도록 구성한다.
+아이디어 4
+아이디어 1과 아이디어 3을 짬뽕하여 ARM보드 들을 클러스터링 하여 그 위에 Hypervisor을 구성하고 빅 데이터 처리를 위한 VM을 구축하여 핸드폰 앱 통계 어플과 같은 서비스를 제공한다.
+{{:o_buntu:h1.png?200|}}
+OR
+{{:o_buntu:h2.png?200|}}
+ARM 보드 클러스터링
+http://www-public.it-sudparis.eu/~trahay_f/odroid_supercomputer/
 ====== 참여자 ======
 박주연, 박진솔,  ... ?