반응형

OS: Ubuntu 14.04 (amd64)

g++ version: 4.8.4



C++11에 정의되어 있는 thread를 코드에 사용해서 이클립스에서든 Makefile을 직접 써서든 그냥 빌드하면 컴파일 에러가 나는데, 이 때는 -std=c++11 플래그를 추가하라고 나와 있다. [5]

다만 쓰려는 코드가 또 쓰레드이기 때문에 -pthread도 추가하도록 되어 있다.


하지만 위와 같은 플래그를 추가하고 나서도 실행 단계에서 아래와 같은 에러가 나면서 실행이 중단된다.


terminate called after throwing an instance of 'std::system_error'

  what(): Enable multithreading to use std::thread: Operation not permitted


StackOverflow [1, 2]를 보면 gcc의 버그라는 게 결론이고, gcc 패키지에도 버그로 보고되어 있다 [3]. 


해결책으로 특정 flag를 추가해 줘야 한다고 나와 있다.

기본적으로 -Wl,--no-as-needed 를 추가해 주면 된다고 한다.


그런데 내 경우에는 g++ 4.8.4를 쓰고 있어서 flag 하나를 더 추가해 줘야 한다는 댓글이 있어서 최종적으로 -std=c++11 -pthread -lpthread -Wl,--no-as-needed 이렇게 추가를 했더니 빌드와 실행 모두 잘 되었다.


Eclipse CDT에서 설정하는 방법은 [4]에 설명되어 있다. Project Properties에서 C/C++ Build 부분은 빌드할 때 옵션이고, C/C++ General 쪽에 해주는 설정은 아마 에디터에서 보여지는 문법상의 에러를 표시할 때 필요한 것 같은데, 이상하게 에디터 쪽에서는 잘 적용이 되지 않는 것 같았다.




<참고자료>

[1] http://stackoverflow.com/questions/19463602/compiling-multithread-code-with-g

[2] http://chat.stackoverflow.com/transcript/message/12447014#12447014

[3] https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1228201

[4] http://wiki.eclipse.org/CDT/User/FAQ#CDT_does_not_recognize_C.2B.2B11_features

[5] http://stackoverflow.com/questions/9131763/eclipse-cdt-c11-c0x-support



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04 (amd64)

ns-3 version: 3.26



ns-3를 설치하는 과정에서 Visualizer (PyViz)도 활성화시키려면 python 관련 패키지들 몇개를 미리 설치해야 하는데, ns-3 공식 안내 페이지 [1]에 나온 대로 설치를 시도하면 python-gnomedesktop 패키지를 설치할 수 없다고 나온다.


$ sudo apt-get install python-dev python-pygraphviz python-kiwi python-pygoocanvas python-gnome2 python-gnomedesktop python-rsvg

Reading package lists... Done

Building dependency tree       

Reading state information... Done

E: Unable to locate package python-gnomedesktop



python-gnomedesktop 대신 python-gnome2-desktop-dev 를 설치하면 된다.


$ sudo apt-get install python-dev python-pygraphviz python-kiwi python-pygoocanvas python-gnome2 python-gnome2-desktop-dev python-rsvg



<참고자료>

[1] PyViz, https://www.nsnam.org/wiki/PyViz 

[2] http://stackoverflow.com/questions/36252495/unable-to-locate-package-python-gnomedesktop-installing-pyviz-in-ns3




반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 14.04 (amd64)

Linux Container template: ubuntu



우분투 데스크탑과 우분투 서버에서는 문제가 없었지만, 우분투 템플릿으로 Linux Container (LXC)를 새로 생성하고 나서 새로운 패키지를 추가하려고 하면 add-apt-repository 명령이 없다고 에러 메세지가 나온다.


이 때 먼저 software-properties-common 패키지를 설치하고 나면 add-apt-repository를 쓸 수 있다.


$ sudo apt-get -y install software-properties-common




*참고


참고로 add-apt-repository 명령을 치면 무조건 사용자에게 추가할 것인지 한 차례 물어보고 엔터 키를 치면 진행을 하게 되는데, 여기서 사용자의 입력을 생략하고 무조건 실행되도록 하려면 맨 끝에 -y 옵션을 주면 된다. [1]


$ sudo add-apt-repository ppa:openjdk-r/ppa -y


위 예시는 openjdk 패키지를 설치하기 위한 ppa를 추가한 것이다.


일반적인 우분투 터미널에서는 결국 sudo privilege를 얻기 위해서 사용자 패스워드를 입력해야만 하지만, 적어도 기본적으로 root 계정으로 켜지는 Linux Container의 경우에는 저렇게 해 주면 자동으로 진행되므로 편한 점이 있다.


# add-apt-repository ppa:openjdk-r/ppa -y




<참고자료>

[1] http://askubuntu.com/questions/304178/how-do-i-add-a-ppa-in-a-shell-script-without-user-input




반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 16.04 (amd64)



새로 설치한 지 얼마 안된 우분투 16.04 머신에서 원래 잘 되던 패키지 설치(apt-get install)가 갑자기 진행이 안되면서 아래와 같이 install-info 를 processing하는 동안 에러가 발생했다는 메세지를 내뱉었다.


아래 출력은 openmpi 관련된 패키지를 설치하려고 시도하면서 발생한 에러를 그대로 가져온 것이다.



skylit@ns3sim:~$ sudo apt-get install libopenmpi1.10 libopenmpi-dev openmpi-common openmpi-bin 

Reading package lists... Done

Building dependency tree       

Reading state information... Done

The following additional packages will be installed:

  autotools-dev libhwloc-dev libhwloc-plugins libhwloc5 libibverbs-dev libibverbs1 libltdl-dev libnuma-dev libtool ocl-icd-libopencl1

Suggested packages:

  libhwloc-contrib-plugins libtool-doc opennmpi-doc autoconf automaken gfortran | fortran95-compiler gcj-jdk opencl-icd gfortran openmpi-checkpoint

The following NEW packages will be installed:

  autotools-dev libhwloc-dev libhwloc-plugins libhwloc5 libibverbs-dev libibverbs1 libltdl-dev libnuma-dev libopenmpi-dev libopenmpi1.10 libtool ocl-icd-libopencl1 openmpi-bin

  openmpi-common

0 upgraded, 14 newly installed, 0 to remove and 267 not upgraded.

1 not fully installed or removed.

Need to get 3,618 kB of archives.

After this operation, 15.5 MB of additional disk space will be used.

Do you want to continue? [Y/n] 

Get:1 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 autotools-dev all 20150820.1 [39.8 kB]

Get:2 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 libltdl-dev amd64 2.4.6-0.1 [162 kB]

Get:3 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 libtool all 2.4.6-0.1 [193 kB]

Get:4 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 libhwloc5 amd64 1.11.2-3 [99.5 kB]

Get:5 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 libibverbs1 amd64 1.1.8-1.1ubuntu2 [25.0 kB]

Get:6 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 libopenmpi1.10 amd64 1.10.2-8ubuntu1 [2,025 kB]

Get:7 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 openmpi-common all 1.10.2-8ubuntu1 [129 kB]

Get:8 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 openmpi-bin amd64 1.10.2-8ubuntu1 [100 kB]

Get:9 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 libnuma-dev amd64 2.0.11-1ubuntu1 [31.7 kB]

Get:10 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 libhwloc-dev amd64 1.11.2-3 [155 kB]

Get:11 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 ocl-icd-libopencl1 amd64 2.2.8-1 [29.7 kB]

Get:12 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 libhwloc-plugins amd64 1.11.2-3 [13.2 kB]

Get:13 http://kr.archive.ubuntu.com/ubuntu xenial/main amd64 libibverbs-dev amd64 1.1.8-1.1ubuntu2 [77.6 kB]

Get:14 http://kr.archive.ubuntu.com/ubuntu xenial/universe amd64 libopenmpi-dev amd64 1.10.2-8ubuntu1 [537 kB]

Fetched 3,618 kB in 1s (2,992 kB/s)      

Setting up install-info (6.1.0.dfsg.1-5) ...

/usr/sbin/update-info-dir: 2: /etc/environment: LC: not found

dpkg: error processing package install-info (--configure):

 subprocess installed post-installation script returned error exit status 127

Errors were encountered while processing:

 install-info

E: Sub-process /usr/bin/dpkg returned an error code (1)

skylit@ns3sim:~$



SuperUser에 찾아보니 /etc/environment 파일을 아래와 같이 고치면 해결된다고 한다.


/etc/environment 파일:

LC_ALL="en_US.UTF-8"


실제로 내가 /etc/environment 파일을 열어 보니, LC와 ALL 사이, 그리고 en과 US 사이가 밑줄이 아니라 공백으로 되어 있었다. (LC ALL="en US.UTF-8"


그런데 나는 해당 파일을 전혀 손댄 적이 없었고, 처음에는 이것저것 패키지 설치가 잘 되었던 기억이 나는데, 도대체 어떻게 고쳐진 것일까? ;;





<참고자료>

[1] "Ubuntu 10.04 - install-info error during update", 
http://superuser.com/questions/129049/ubuntu-10-04-install-info-error-during-update



반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 16.04 (amd64)

Host Spec (VM): Quad core 2.6GHz (Intel Zeon, Haswell), 4GB RAM

LXC template: ubuntu



지난 여름에는 라즈베리파이 4개를 가지고 무선 메쉬 네트워크를 만들고, 각각의 라즈베리파이가 AP 역할을 함으로써 서로 다른 AP에 물린 클라이언트들 사이에 통신이 되도록 하였고, 이를 중개하는 multi-constrained 라우팅 프로토콜을 Java로 개발해서 테스트를 했었다.


사실 성능을 생각하면 C로 개발해야 하지만 무지막지하게 늘어나는 개발 시간 때문에 그나마 익숙하게 다룰 수 있는 Java로 개발을 했었고, 이제 와서 보니 이게 ns-3에서 시뮬레이션을 돌릴 때 결국 C나 파이썬으로 포팅해야 되는 어려움으로 돌아오고 말았다. ㄷㄷ


하지만 ns-3는 real-world program을 돌릴 수 있는 몇 가지 방법을 제시하고 있었고, 그 중에서 Linux Container (LXC)를 이용한 방법이 있어서 튜토리얼을 따라하며 환경을 구축해 보았다.


실제로 예제를 그대로 따라해서 2개의 노드가 IEEE 802.11g로 서로 애드혹 네트워크로 연결되고 각각의 노드에서 ping, ssh 등을 테스트하는 데에는 아무 문제가 없었다.

여기서 더 나가서 내가 개발한 Java 기반의 라우팅 프로토콜을 실행시키는 과정이 생각보다 오래 걸렸지만, 이것도 각 컨테이너를 인터넷에 먼저 연결시키고 apt-get으로 필요한 패키지를 다 설치하고 나니 어쨌든 내가 라즈베리파이에서 돌리던 모양 그대로 실행시킬 수 있었다.


여기까지는 일단 그대로 실행이 되는지부터 봐야 해서 노드 3개까지만 만들어서 해 본 거였고, 이제 본격적으로 시뮬레이션을 돌리기 위해서 노드 생성과 Java 프로그램 실행을 자동화하는 스크립팅 작업을 했는데 이것 또한 시간이 은근히 많이 걸렸다. ㅜㅜ


우여곡절 끝에 이제 내가 마음대로 원하는 만큼의 노드(컨테이너)를 자동으로 생성/실행할 수 있게 되었고, 네트워크 토폴로지는 ns-3에서 역시나 마음대로 설정해 주면 되었다.


드디어 대망의 첫 실험...

자신있게 10개의 노드를 명령어 한 줄로 간지나게(?) 자동으로 뙇 생성하고, 토폴로지는 4-4-2 그리드 형태로 만든 다음, 실험 시작을 누르고 나서 시범적으로 9번 노드에서 이웃 노드인 10번 노드한테 ping을 날려 봤더니...


root@node9:/# ping 10.0.0.10

PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.

64 bytes from 10.0.0.10: icmp_seq=1 ttl=64 time=3665 ms

64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=4356 ms

64 bytes from 10.0.0.10: icmp_seq=3 ttl=64 time=5375 ms

64 bytes from 10.0.0.10: icmp_seq=4 ttl=64 time=7245 ms

64 bytes from 10.0.0.10: icmp_seq=5 ttl=64 time=8166 ms

64 bytes from 10.0.0.10: icmp_seq=6 ttl=64 time=9149 ms

64 bytes from 10.0.0.10: icmp_seq=7 ttl=64 time=10225 ms

64 bytes from 10.0.0.10: icmp_seq=8 ttl=64 time=11106 ms

64 bytes from 10.0.0.10: icmp_seq=9 ttl=64 time=12252 ms

64 bytes from 10.0.0.10: icmp_seq=10 ttl=64 time=13146 ms

64 bytes from 10.0.0.10: icmp_seq=11 ttl=64 time=14062 ms

64 bytes from 10.0.0.10: icmp_seq=12 ttl=64 time=15261 ms

64 bytes from 10.0.0.10: icmp_seq=13 ttl=64 time=16784 ms

64 bytes from 10.0.0.10: icmp_seq=14 ttl=64 time=18056 ms

64 bytes from 10.0.0.10: icmp_seq=15 ttl=64 time=19286 ms

64 bytes from 10.0.0.10: icmp_seq=16 ttl=64 time=20347 ms

64 bytes from 10.0.0.10: icmp_seq=17 ttl=64 time=21576 ms

64 bytes from 10.0.0.10: icmp_seq=18 ttl=64 time=22208 ms

64 bytes from 10.0.0.10: icmp_seq=19 ttl=64 time=22970 ms

64 bytes from 10.0.0.10: icmp_seq=20 ttl=64 time=23673 ms

64 bytes from 10.0.0.10: icmp_seq=21 ttl=64 time=24549 ms

64 bytes from 10.0.0.10: icmp_seq=22 ttl=64 time=24565 ms

64 bytes from 10.0.0.10: icmp_seq=23 ttl=64 time=24311 ms

64 bytes from 10.0.0.10: icmp_seq=24 ttl=64 time=24205 ms

64 bytes from 10.0.0.10: icmp_seq=25 ttl=64 time=23996 ms

64 bytes from 10.0.0.10: icmp_seq=26 ttl=64 time=23627 ms

64 bytes from 10.0.0.10: icmp_seq=27 ttl=64 time=23452 ms

64 bytes from 10.0.0.10: icmp_seq=28 ttl=64 time=23325 ms

64 bytes from 10.0.0.10: icmp_seq=29 ttl=64 time=23048 ms

64 bytes from 10.0.0.10: icmp_seq=30 ttl=64 time=22669 ms

64 bytes from 10.0.0.10: icmp_seq=31 ttl=64 time=22337 ms

64 bytes from 10.0.0.10: icmp_seq=32 ttl=64 time=21869 ms

64 bytes from 10.0.0.10: icmp_seq=33 ttl=64 time=21127 ms

64 bytes from 10.0.0.10: icmp_seq=34 ttl=64 time=20186 ms

64 bytes from 10.0.0.10: icmp_seq=35 ttl=64 time=19246 ms

64 bytes from 10.0.0.10: icmp_seq=36 ttl=64 time=18327 ms

64 bytes from 10.0.0.10: icmp_seq=37 ttl=64 time=17383 ms

64 bytes from 10.0.0.10: icmp_seq=38 ttl=64 time=16449 ms

64 bytes from 10.0.0.10: icmp_seq=39 ttl=64 time=15512 ms

64 bytes from 10.0.0.10: icmp_seq=40 ttl=64 time=14573 ms

64 bytes from 10.0.0.10: icmp_seq=41 ttl=64 time=13607 ms

64 bytes from 10.0.0.10: icmp_seq=42 ttl=64 time=12676 ms

64 bytes from 10.0.0.10: icmp_seq=43 ttl=64 time=11745 ms

64 bytes from 10.0.0.10: icmp_seq=44 ttl=64 time=10816 ms

64 bytes from 10.0.0.10: icmp_seq=45 ttl=64 time=9876 ms

64 bytes from 10.0.0.10: icmp_seq=46 ttl=64 time=8953 ms

64 bytes from 10.0.0.10: icmp_seq=47 ttl=64 time=8012 ms

64 bytes from 10.0.0.10: icmp_seq=48 ttl=64 time=7037 ms

64 bytes from 10.0.0.10: icmp_seq=49 ttl=64 time=6042 ms

64 bytes from 10.0.0.10: icmp_seq=50 ttl=64 time=5064 ms

64 bytes from 10.0.0.10: icmp_seq=51 ttl=64 time=4069 ms

64 bytes from 10.0.0.10: icmp_seq=52 ttl=64 time=3074 ms

64 bytes from 10.0.0.10: icmp_seq=53 ttl=64 time=2080 ms

64 bytes from 10.0.0.10: icmp_seq=54 ttl=64 time=1087 ms

64 bytes from 10.0.0.10: icmp_seq=55 ttl=64 time=102 ms

64 bytes from 10.0.0.10: icmp_seq=56 ttl=64 time=5.94 ms

64 bytes from 10.0.0.10: icmp_seq=57 ttl=64 time=5.57 ms

64 bytes from 10.0.0.10: icmp_seq=58 ttl=64 time=5.82 ms

64 bytes from 10.0.0.10: icmp_seq=59 ttl=64 time=5.49 ms

64 bytes from 10.0.0.10: icmp_seq=60 ttl=64 time=5.55 ms

^C

--- 10.0.0.10 ping statistics ---

60 packets transmitted, 60 received, 0% packet loss, time 59063ms

rtt min/avg/max/mdev = 5.498/13466.053/24565.805/8177.166 ms, pipe 25

root@node9:/# 



Aㅏ...

저기 중간에 점도 찍히지 않고 당당하게 5자리를 찍어주는 저 결과는 뭥미?

24205는 뭔가요? 저게 진정 와이파이 RTT인가여? 털썩...


각 컨테이너에서 아무 프로그램도 돌고 있지 않을 때는 이웃노드 간에 ping을 날리면 약 5ms가 되어야 정상인데, 보는 것처럼 데이터 패킷도 아닌 ICMP 패킷 하나가 바로 옆으로 가는 데 24초를 넘어섰다. ㄷㄷㄷ 저것도 계속 RTT가 커지기만 하길래 24초쯤 되는 상황에서 돌아가는 모든 Java 프로그램을 죽였더니, 한참이 지나고 나서야 ping이 정상으로 돌아온 것이다.


내가 Java 프로그램을 잘못 만들었구나 자책하려고 했지만, Host 머신에서 CPU 사용량을 확인해 보니 ns-3 프로세스가 혼자 97% ~ 110% 사이를 왔다갔다 하고 있었고, 정작 내가 개발한 Java 프로세스들은 별로 CPU를 차지하고 있지 않았다. (라즈베리파이2에서도 3-9% 수준이긴 했음)


일차적으로 생각해 본 원인은 ns-3 프로세스가 L2 이하를 시뮬레이션 시키고 있는데, 10개의 노드 각각이 라우팅을 위해서 Hello 패킷을 비롯한 컨트롤 패킷을 매 초마다 발생시키니까 싱글 코어만으로는 계산하는 양이 감당이 안돼서 응답이 늦어지는 바람에 ping이 20초를 넘어서는 저런 사단이 난 것 같았다.


아~망했어요 ㅠㅠ

나는 ns-3 코어가 적어도 100노드 정도의 scalability는 책임질 수 있을 거라 생각했는데... 이건 뭐 컨테이너가 제아무리 가벼워도 각자 발생시키는 패킷의 양이 늘어나면 ns-3 코어가 감당을 못하는 상황이라니...


현재까지는 ns-3에 멀티코어 활용하도록 고친다던지, 아예 컨테이너도 없이 real-world 프로그램을 직접 네트워크와 연동하는 방법(DCE라고 하는데... 결국 컨테이너로 해결을 못하면 이것도 공부해야 함...)은 아직 확인하지 못했다.


내가 ns-3에 멀티코어 활용 방법을 아직 몰라서 이런 것이라고 믿고 싶다. ㅜㅜ 

그런데 왠지 보니까 기본적으로 멀티코어를 활용하도록 설계했을 법도 한데 안한 점과 구글 검색(ns-3 multi core)에서 첫 페이지에서 그런 옵션을 켜는 법이라던지 하는 간단한 해결방법이 보이지 않는 것을 보면... 


야~신난다 @_@

대안으로 나온 것이 컨테이너도 없이 DCE라고 직접 프로그램 코드를 바로 실행하는 방법도 있지만 이건 C++만 된다고 한다. DCE에 Java 프로그램을 붙이는 방법이 있는지 찾아보고, 이마저도 없으면 쌩으로 Java를 모두 C++ 또는 파이썬으로 포팅하는 대규모 토건사업이 펼쳐지겠지 ㄹㅇㅁㄴㄹㅇㅁㄹㅁㅈ 일자리 창출 인정? =_=


정신줄 그만 놓고, 해결 방법을 찾아봐야겠다. ㅜㅜ


반응형
블로그 이미지

Bryan_

,