3상 3선식 혹은 3상 4선식의 전원을 검침 할 수 있는 솔루션 개발이 금번 프로젝트의 목표 였습니다.


처음에는 계량기 솔루션으로 많이 사용되며, 일전 변압기 감시용 솔루션에 사용 하였던 테리디안의 71M6511 혹은 71M6513을 사용하려 하였습니다.


테리디안의 칩셋은 8051 core와 전력 검침을 위한 dsp가 같이 결합되어 있는 파워 미터 전용 ic로 제품군에 따라 매우 정밀한 측정이 가능 한 장점을 가지고 있습니다.


하지만 앞서 말씀드린바와 같이 시대에 뒤떨어진 8051 core와 작은 메모리 사이즈로 인해, 외부 확장 메모리를 붙이거나, 심지어 별도의 mcu를 붙여 제어하는 형태로 개발이 이루어지고 있습니다. 또한 개발 툴 역시 최소 100만원 이상의 장비를 별도 구매하여야 합니다.


이러한 단점으로 인해 효율적인 개발과 시간 단축을 위해 새로운 솔루션을 찾게 되었으며, MAX78630이 이러한 대안 이었습니다.


MAX78630에 대해 간단히 설명 드리면 아래와 같습니다.

MAX78630은 여러 상의 전원을 측정 하는 모니터링 시스템을 위한 chipset으로 자체 내장된 24-bit 검침 코어와 펌웨어가 내장되어 있습니다. 또한 설정값들을 자체 저장 할 수 있는 비휘발성 메모리 역시 내장되어 사용자가 별도로 설정 데이터를 관리할 필요가 없습니다.


저희는 LCD 및 기타 여러 기능들을 위한 I/O가 다수 필요하여, ST사의 STM32F103VB mcu를 선정하여 인터페이스 하였으며, 한정된 SPI 로 인해 usart 를 이용하여 chipset과 인터페이스 하였습니다.


hardware의 구성은 따로 아래 포스트를 통해 연재 하도록 하겠습니다.


여기서는 interface 만을 집중적으로 보도록 하겠습니다.


'ARM > Software' 카테고리의 다른 글

대표적 ASCII 정리  (0) 2010.06.07
C언어를 이용한 CGI 웹 프로그래밍 Intro...  (0) 2010.01.12
리눅스 rpm명령어  (0) 2009.11.10
부트로더 란?  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10

DEC HEX 기호
0 0x00 NUL (NULL Character)
1 0x01 SOH (Start of Header)
2 0x02 STX (Start of Text)
3 0x03 ETX (End of Text)
4 0x04 EOT (End of Transmission)
5 0x05 ENQ (Enquiry)
6 0x06 ACK (Acknowledgement)
7 0x07 BEL (Bell)
8 0x08 BS (Backspace)
9 0x09 HT (Horizontal Tab)
10 0x0A LF (Line feed)
11 0x0B VT (Vertical Tab)
12 0x0C FF (Form feed)
13 0x0D CR (Carriage return)
14 0x0E SO (Shift Out)
15 0x0F SI (Shift In)
16 0x10 DLE (Data link escape)
17 0x11 DC1 (Device control 1)
18 0x12 DC2 (Device control 2)
19 0x13 DC3 (Device control 3)
20 0x14 DC4 (Device control 4)
21 0x15 NAK (Negative acknowledgement)
22 0x16 SYN (Synchronous idle)
23 0x17 ETB (End of transmission block)
24 0x18 CAN (Cancel)
25 0x19 EM (End of medium)
26 0x1A SUB (Substitute)
27 0x1B ESC (Escape)
28 0x1C FS (File separator)
29 0x1D GS (Group separator)
30 0x1E RS (Record separator)
31 0x1F US (Unit separator)
32 0x20 SPC (Space)
- falinux forum에서 발췌..

'ARM > Software' 카테고리의 다른 글

전력 검침 칩셋 MAX78630 인터페이스  (0) 2016.07.13
C언어를 이용한 CGI 웹 프로그래밍 Intro...  (0) 2010.01.12
리눅스 rpm명령어  (0) 2009.11.10
부트로더 란?  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10
이번에 회사에서 맡은 프로젝트는 웹 프로그램입니다...
제품은 IP 전화기 및 중앙 단말기와 연동되는 키폰 입니다..
제가 맡은 부분은 하드웨어나 펌웨어가 아닌... 웹 입니다 ...
그것도 임베디드 상에서의 웹... 공유기에서나 사용될 줄 알았는데 이렇게 맡게 되네요...
문제는... 이겁니다.. CGI... Perl 이나 java를 이용한 것이 아닌.. C를 이용한 CGI 웹 프로그래밍 이죠..

구현해야 할 내용은 다음과 같습니다..

1. 로그인 부분 구현
2. 키폰의 LCD 부분에 표기될 정보를 사용자로부터 입력받아 장비에 세팅
3. 네트워크 설정 세팅부
4. 웹을 통한 펌웨어 업그레이드
5. 웹을 통한 환경설정 업데이트 부분
등 입니다..

프로젝트는 이제 막바지에 다다르고 있으며 차후 같은 프로젝트의 진행시 도움 및 현재 유사한 프로젝트로 인해 날밤을 세우시는 개발자 분들을 위해 이 글을 남기고자 합니다..
진행 될 강좌는 크게 아래와 같이 나누고자 합니다..

1. CGI란 무엇인가
2. CGI 구동을 위한 아파치 서버의 설정
3. HTML FORM을 이용하여 서버로 데이터 전송 방법
4. FORM으로부터 데이터를 입력받아 처리하는 법
5. 한글 처리 방법
6. 기타...

'ARM > Software' 카테고리의 다른 글

전력 검침 칩셋 MAX78630 인터페이스  (0) 2016.07.13
대표적 ASCII 정리  (0) 2010.06.07
리눅스 rpm명령어  (0) 2009.11.10
부트로더 란?  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10
rpm 명령어
간단한 rpm 명령어를 정리해 보려 한다.

나중에 기회되면 이 옵션들이 멀 뜻하는지 정리해야지

- 패키지 설치하기
$rpm -Uvh <패키지 이름>

- 패키지가 설치되어 있는지 확인
$rpm -qa | grep <패키지 이름>

- 패키지 제거하기
$rpm -e --nodeps <패키지 이름>
(--nodeps는 rpm패키지를 삭제할 때 의존성을 무시하라는 옵션)

'ARM > Software' 카테고리의 다른 글

대표적 ASCII 정리  (0) 2010.06.07
C언어를 이용한 CGI 웹 프로그래밍 Intro...  (0) 2010.01.12
부트로더 란?  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10
LN2440SBC 메모리 맵  (0) 2009.11.10

부트로더(Boot Loader)

부트로더란 위키페디아에 이렇게 정의되어 있다.

"부트로더(Boot loader)란 운영 체제가 시동되기 이전에 미리 실행되면서 커널이 올바르게 시동되기 위해 필요한 모든 관련 작업을 마무리하고 최종적으로 운영 체제를 시동시키기 위한 목적을 가진 프로그램을 말한다."

이게 첫번째 부트로더의 정의이다.

이어서 위키페디아에는 '두 번째 단계의 부트로더'로 이렇게 정의되어 있다.

"시동을 위한 프로그램은 운영 체제 그 자체가 아니라, 두 번째 부트 로더로, 이를테면 NTLDR, 리눅스 로더, GRUB을 들 수 있다. 운영 체제를 적절하게 불러들이고 끝내 실행할 수 있는 상황으로 만들어 준다. 시스템은 그 자체를 초기화하며 운영 체제의 동작에 일반적으로 필요한 장치 드라이버와 다른 프로그램들을 불러들인다. 여러 개의 운영 체제를 선택할 수 있다는 뜻의 듀얼 부팅도 참조하라."

즉, 단순하게 말해 부트로더는 컴퓨터에 전원이 들어왔을 때(혹은 리셋 버튼이 눌러졌을 때) 가장 먼저 시작되는 프로그램이다. 데스탑PC의 BIOS와 역할이 비슷하다. 데스크탑에서 Del이나 F2키를 누르면 BIOS Setup에 들어가지는데 부트로더에도 이런 Setup과 같은 기능들이 있다. Command Mode에서(임베디드를 하면 보드에 처음에 부트로더를 올리게 되는데, 보드에 부트로더가 올라가게 되면 여러 명령어를 칠 수 있는 Command Mode가 나타난다. ) 호스트 컴퓨터로부터 커널 이미지나 루트파일 시스템(램디스크 이미지)을 다운로드하거나 커널 파라미터를 세팅하는 등의 기능을 제공한다. 부트로더는 사용하고자하는 시스템에 맞게 작성해서 사용해야만 한다.

그럼 부트로더가 가장 먼저 실행되서 구체적으로 무슨 일을 할까?
- 하드웨어에 대한 초기화(cpu speed, 메모리, 인터럽트, 시리얼)를 해준다.
- OS의 커널(kernel) 로드  
- 그 밖에 커널(kernel) 이미지나 루트(root) 이미지를 다운로딩 할 수 있는 기능
- 몇몇 파라미터를 커널에 넘겨주는 일

부트로더의 종류는 여러가지다. 여기서는 임베디드에서 사용하는 부트로더의 종류를 살펴보면
Samsung - ArmBoot
ATMEL - SAMBoot
WinCE - eboot
Linux - uboot
등 여러가지가 있는데, 내부적으로부터 거의 동일하다. 만약 하드웨어 스팩이 같은데 다른 부트로더를 쓰고 싶으면 사용해도 된다. 하지만 그 하드웨어의 메모리 구조에 맞게 부트로더를 수정하거나 다시 작성해야만 한다.


※ 참고
호스트상에서 컴파일된 커널이나 Root이미지를 시리얼을 이용하여 SDRAM에 다운로딩이 가능하다. 이렇게 다운로드한 이미지를 플래쉬 디스크에 쓸 수 있어야 한다. 왜냐하면, SDRAM에 존재하는 것은 전원을 껏다 키게 되면, 다운로드한 이미지는 날아가 버린다. 즉 다시 또 다운로딩을 해야 한다. 그래서 부트로더에는 SDRAM에 있는 이미지를 플래쉬 디스크에 쓸 수 있는 기능이 필수 적이다.

'ARM > Software' 카테고리의 다른 글

C언어를 이용한 CGI 웹 프로그래밍 Intro...  (0) 2010.01.12
리눅스 rpm명령어  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10
LN2440SBC 메모리 맵  (0) 2009.11.10
리눅스 시리얼 프로그래밍 예제  (0) 2009.11.10
ftp 명령어 정리
ls : 현재 접속된 서버에 있는 파일의 목록을 확인

cd : 디렉토리 이동

mkdir : 디렉토리 생성

pwd : 현재 디렉토리 확인

get : FTP 서버에 있는 파일 1개를 클라이언트로 다운로드

put : 클라이언트에 있는 파일 1개를 서버로 업로드

mget : FTP 서버에 있는 파일 여러 개를 클라이언트로 다운로드

mput : 클라이언트에 있는 파일 여러 개를 서버로 업로드

ascii : 업로드/다운로드하는 파일이 아스키 파일(텍스트 파일)이라는 것을 미리 지정

bin : 업로드/다운로드하는 파일이 바이너리 파일(텍스트 파일 외 나머지)이라는 것을 미리 지정

'ARM > Software' 카테고리의 다른 글

리눅스 rpm명령어  (0) 2009.11.10
부트로더 란?  (0) 2009.11.10
LN2440SBC 메모리 맵  (0) 2009.11.10
리눅스 시리얼 프로그래밍 예제  (0) 2009.11.10
RTC 없이 보드 시간 동기화  (0) 2009.11.10
LN2440SBC 메모리 맵
실제로 플래시 메모리를 어떻게 나누어 쓰는지 나타내는 메모리 맵이다.

왜 이게 중요하냐면 나중에 커널을 어느부분에 올려야 되고, 루프파일 시스템을 어느부분에다가 올려야 되는지 중요하기 때문이다.

이 주소를 알아야지만 이러한 것들을 설치할 때 설치가 정확하게 된다.

메모리 번지
0x04000000------------------------
                          User Area             } 0x00E00000
0x03200000------------------------


                     Root File System        } 0x03000000


0x00200000------------------------

                            Kernel                } 0x001D0000

0x00030000------------------------
                        Config Area             } 0x00010000
0x00020000------------------------
                   BootLoader(U-Boot)      } 0x00020000
0x00000000------------------------

'ARM > Software' 카테고리의 다른 글

부트로더 란?  (0) 2009.11.10
리눅스 FTP 명령어 정리  (0) 2009.11.10
리눅스 시리얼 프로그래밍 예제  (0) 2009.11.10
RTC 없이 보드 시간 동기화  (0) 2009.11.10
패킷 교환 네트워크에서의 지연과 손실  (0) 2009.11.10

현재 시간날짜가 보드에 세팅이 안되는 문제
LN2240SBC 보드에서 현재날짜와 시간을 세팅할려고 하는데 저장이 안되었다.

$date 090807142008.50

이런식으로 세팅을 하고 보드를 재부팅하면 설정한 내용이 저장이 안된다.(날짜와 시간이 초기화됨)

검색해보니까 RTC가 없어서 그런거라고 하던데..

해결법은 ETRI 박호준님께서 해주셨다.
------------------------------------------------------------------
안녕하세요 공모대전 Qplus 담당 박호준입니다.

날짜 및 시간 설정은 커널 드라이버단까지는 구현이 완료되어 있는 상태입니다.

다만 시스템 초기화시 두 시간을 동기화하지 않는데 그 원인이 있습니다.


리눅스에서는 시스템의 RTC의 시간을 처리하는데 hwclock이라는 유틸리티를 사용합니다.  Qplus에서는 busybox가 이부분을 처리하도록 되어 있지요.  다만 hwclock은 응용 프로그램이고 RTC는 시스템이기 때문에 드라이버를 사용할 디바이스파일이 필요한 것 뿐입니다.


아래의 절차를 따라 하십시오.

# mknod /dev/rtc c 10 135 <-- /dev/rtc라는 디바이스 파일을 만듭니다.
# date 090807142008.50 <-- 가급적 현재 시간에 맞도록 해야 합니다.
# hwclock -w <-- RTC의 시간을 커널 시간에 맞춥니다.


시스템 재부팅시 자동으로 RTC의 시간을 커널 시간에 반영

hwclock -s 명령을 /etc/rc.d/rc.sysinit 파일 중간쯤에 삽입합니다.


RTC에 시간을 설정 유지하는 것과 시스템 시간을 정확히 유지하는 것은 다른 문제입니다.  일반적으로 인터넷 시간 서버를 사용하는것이 원칙이며 국내에서는 time.kriss.re.kr이 메인인 것으로 알고 있습니다.  이것을 이용하는 방법은 ntpdate나rdate같은 것이 있는데요.. 사용법은 질문의 요지를 벗어나므로 생략하도록 하겠습니다.

1.6 패킷 교환 네트워크에서의 지연과 손실

- 패킷은 한 호스트(근원지)에서 시작하고, 일련의 라우터를 통과하고, 다른 호스트(목적지)에서 긴 여행이 끝난다.


- 패킷이 경로를 따라 한 노드(호스트 혹은 라우터)에서 다음 노드(호스트 혹은 라우터)로 전달되므로, 그 패킷은 경로상의 각 노드에서 다양한 지연을 겪게 된다. 이들 지연에서 중요한 것으로는 노드 처리 지연(nodal processing delay), 큐잉 지연(queuing delay), 전송 지연(transmission delay), 전파 지연(propagation delay)을 들 수 있다. 이 지연들 중 쌓여서 전체 노드 지연을 일으킨다.


1.6.1 지연 유형


++그림 1.13++


- 그림 1.13의 각종 지연에 대해 살펴보자. 근원지와 목적지 사이 종단 간의 루트 일부로서, 한 패킷이 업스트림 노드로부터 라우터 A를 통해 라우터 B로 보내진다.


- 목표는 라우터 A에서의 노드 지연 특성을 파악하는 것이다. 라우터 A가 라우터 B에 이르는 하나의 외향(outgoing) 링크를 가지는 것에 주목하라. 이 링크 앞에 큐(버퍼)가 있다. 패킷이 업스트림 노드로부터 라우터 A에 도착하면, 라우터 A는 그 패킷에 대한 적당한 외향 링크를 결정하기 위해 패킷 헤더를 조사하고, 그 패킷을 선택된 링크로 보낸다. 이 예에서, 이 패킷에 대한 외향 링크가 라우터 B에 이르는 링크이다. 패킷은 링크에 현재 전송되는 다른 패킷은 없고 큐에 자신보다 앞선 다른 패킷들이 없으면, 링크로 전송될 수 있다. 만약 링크가 이미 이용되고 있거나 그 링크를 이용하기 위해 큐에서 대기하는 패킷이 있다면, 새로 도착하는 패킷은 큐에 들어간다.


<처리 지연>

- 패킷 헤더를 조사하고 그 패킷을 어디로 보낼지를 결정하는 시간은 처리 지연에 속한다.


- 처리지연은 업스트림 노드에서 라우터 A로 패킷의 비트들을 전송하면서 발생하는 패킷의 비트 수준 오류를 조사하는 데 필요한 시간과 같은 다른 요소를 포함할 수도 있다. 고속라우터에서의 처리지연은 일반적으로 수 밀리초이다. 이 노드 처리 후에 라우터는 그 패킷을 라우터 B에 이르는 링크의 큐로 보낸다.


<큐잉 지연>

- 큐에서 패킷은 링크로 전송되기를 기다리면서 큐잉 지연을 겪는다.


- 특정 패킷의 큐잉 지연 길이는 큐에 저장되어 링크로 전송되기를 기다리는 다른(앞서 도착한) 패킷의 수에 의해 결정된다. 따라서 주어진 패킷의 지연은 패킷마다 상당히 다르다. 큐가 비어 있고 다른 패킷이 전송 중인 상태가 아니라면, 이때 패킷의 큐잉 지연은 0이다. 반면에 트래픽이 많고 다른 많은 패킷이 전송대기 중이면, 큐잉 지연은 매우 길어진다.


<전송 지연(저장 후 전달 지연)>

- 패킷들이 선입선출 방식으로 전송된다고 가정하면, 인터넷에서 일반적인 것처럼 패킷은 앞서 도착한 다른 모든 패킷들이 전송된 다음에 전송될 수 있다. 패킷의 길이를 L비트로, 라우터 A에서 라우터 B까지 링크의 전송률은 R bps(R bps라는 의미는 1초에 R비트를 처리한다는 의미이다. 예를 들어 패킷의 길이가 100비트이고, 링크의 전송률은 10 bps라고 한다면 이 링크는 1초에 10비트를 한번에 처리(전송)할 수 있다는 얘기다. 더 나아가 전송 지연을 생각하면 100bit/10bps = 10초 즉, 이 링크는 100bit를 처리(전송)하는 데 10초가 걸린다는 얘기다. 여기서 주의해야 할 것이 링크의 전송률과 링크의 전파속도는 전혀 다르다는 것이다. 위의 예를 들어 10 bps는 그 링크가 1초에 10비트를 처리(전송)할 수 있음을 의미하지만 그것이 1초에 10비트씩 다른 라우터로 전송된다는 말이 아니다. 다시 말해 1초마다 10비트를 처리할 수 있지만, 이 10비트가 링크를 통해 다른 라우터로 가는 시간은 그 링크의 전파속도와 관련있다.)로 나타내자. R은 라우터 B로 가는 링크의 전송률에 의해 결정된다. 예를 들어, 10Mbps 이더넷 링크의 경우 R은 10Mbps이다. - 전송 지연(저장 후 전달 지연)은 L/R이다. 이것은 패킷의 모든 비트들을 링크로 밀어 내는데(전송) 필요한 시간이다.


<전파 지연>

- 일단 비트가 링크에 전해지면, 라우터 B까지 전파되어야 한다. 링크의 처음에서 라우터 B까지의 전파에 필요한 시간이 전파 지연이다.


- 비트는 링크의 전파속도로 전파된다.


- 링크의 전파속도는 빛의 속도와 같거나 약간 작다.


- 전파속도는 링크의 물리 매체(광섬유, 꼬임쌍 동선 등)에 따라 다르다.


- 전파 지연은 d/s이다.(d는 라우터 A와 라우터 B 사이의 거리이고, s는 링크의 전파속도이다. s는 링크의 전송률이 아니다!!)


- 일단 패킷의 마지막 비트가 B 노드에 전파되면, 이 비트와 앞선 모든 비트는 라우터 B에 저장된다. 라우터 B에서 이러한 과정(처리 지연, 큐잉 지연, 전송 지연, 전파 지연)이 다음 노드로 전달되기 위해 반복된다.


<전송 지연과 전파 지연 비교>

- 전송 지연은 라우터가 패킷을 내보내는 데 필요한 시간이다.(패킷 길이와 링크 전송률의 함수이며, 두 라우터 사이의 거리와는 관계없다.) 반면, 전파 지연은 비트가 한 라우터에서 다음 라우터로 전파되는 데 걸리는 시간이다.(두 라우터 사이의 거리에 대한 함수이며, 패킷 길이나 링크 전송률과는 관계없다.)


- 링크의 전송률과 링크의 전파속도를 같다고 혼동하지 말 것!!!


<지연 시간을 명확히 해주는 예>

100km마다 요금계산소가 있는 고속도로를 생각하자. 고속도로 요금계산소 사이를 링크로, 요금계산소를 라우터로 생각할 수 있다. 차가 시속 100km(전파)로 고속도로를 달린다고 가정하자(차가 요금계산소를 지나면 바로 시속 100km 속도를 유지하며 달린다.) 함께 여행하는 10대의 차가 있고 이들이 일정한 순서대로 줄을 맞추어 달린다고 가정한다. 각 자동차를 비트로 생각하고 이들이 일정한 순서대로 줄을 맞춰서 달린다고 가정하자. 각 자동차를 하나의 비트로 생각한다면 일정한 순서대로 줄을 맞춘 10대의 차는 하나의 패킷으로 생각할 수 있다. 또한 각 요금계산소는 12초마다 한 대의 차를 서비스(전송)한다고 하고(1분에 5대), 늦은 밤이라서 다른 차는 고속도로에 없다고 하자. 마지막으로, 이 차량 대열의 첫 번째 자동차가 요금계산소에 도착할 때, 입구에서 다른 9대의 차가 도착할 때까지 기다려서 그 뒤에 줄서서 대기한다고 하자(저장 후 전달 방식; 전체 차량 대열이 ‘전송’되기 전에 요금계산소에 ‘저장’되어야 한다.)


- 요금계산소가 전체 자동차를 밀어내는 데 걸리는 시간은 (10대)/(5대/분) = 2분이다. 이 시간은 라우터에서의 전송 지연과 유사하다.


- 한 자동차가 한 요금계산소에서 다음 계산소로의 이동에는 100km/(100km/hour) = 1시간이다. 이 시간은 전파 지연과 유사하다.


- 따라서 차량 대열이 한 요금계산서 앞에 저장되는 시간으로부터 다음 요금계산서 앞에 저장될 때까지의 시간은 ‘전송 지연’과 ‘전파 지연’의 합이다.(62분)


이 예를 더 살펴보자. 요금계산소의 차량 대열(자동차 10대)에 대한 서비스 시간이 한 자동차가 요금계산소 사이를 이동하는 데 걸리는 시간보다 크다면 무슨 일이 발생할까?(즉, 자동차는 막 들어오는데 요금계산소에서 처리가 늦은 것이다.) 예를 들어, 자동차가 시속 1,000km로 달리고 요금계산소는 1분에 1대의 서비스를 한다고 하자. 이 때 요금계산소 간의 이동지연(전파 지연)은 6분이고((100km)/(1000km/h)=0.1h=6min), 차량 대열을 서비스하는데 걸리는 시간은 10분이다. 이 경우에 차량 대열에서 처음 몇 개의 자동차는 마지막 자동차가 첫 번째 요금계산소를 벗어나기도 전에 두 번째 요금계산소에 먼저 도착한다. 이러한 경우가 패킷 교환 네트워크에서도 발생할 수 있다. 패킷의 앞선 비트들이 패킷의 나머지 다른 비트가 라우터에서 전송되기를 기다리는 동안에 이미 다음 라우터에 도착할 수 있는 것이다.


전체 노드 지연 = 처리 지연 + 큐잉 지연 + 전송 지연 + 전파 지연


- 이런 지연 요소의 기여도에는 상당히 차이가 있을 수 있다. 예를 들어, 전파 지연은 대학 캠퍼스 내부의 두 라우터를 연결하는 링크에서는 무시할 수 있다.(수 마이크로초 정도) 그러나 정지 위성 링크로 연결된 두 라우터의 경우 전파 지연은 수백 밀리초이고, 전체 노드 지연에서 주요 요소이다.


- 전송 지연도 마찬가지로 무시할 수 있는 정도에서부터 상당한 지연에까지 이를 수 있다. 100Mbps나 그 이상의 전송률인 경우는 일반적으로 무시할 수 있으나 저속 다이얼업 모뎀 링크에서 보내지는 커다란 인터넷 패킷은 수백 밀리초에 이를 수 있다.


- 처리 지연은 보통 무시될 수 있다.


1.6.2 큐잉 지연과 패킷 손실

- 노드 지연 중 가장 복잡하고 흥미로운 요소는 큐잉 지연이다.(큐잉 지연 관련 논문과 책만 수천 개)


- 큐잉 지연은 처리 지연, 전송 지연, 전파 지연과 다르게 패킷마다 다를 수 있다. 예를 들어 동시에 10개의 패킷이 비어 있는 큐에 도착한다면, 전송된 첫 패킷은 큐잉 지연을 겪지 않지만 마지막으로 전송되는 패킷은 상당히 많은 큐잉 지연을 겪을 것이다.(다른 9개의 패킷이 전송되기를 기다려야 하므로) 따라서 큐잉 지연의 특성을 묘사할 때, 평균 큐잉 지연, 큐잉 지연의 분산, 큐잉 지연이 어느 특정 값을 넘을 확률 같은 통계 측정을 일반적으로 이용한다.


- 언제 큐잉 지연이 크고, 언제 미미한가? 이것에 대한 대답은 트래픽이 큐에 도착하는 비율, 링크의 전송률, 도착하는 트래픽의 특성, 즉 그 트래픽이 주기에 맞춰서 또는 버스트(burst)하게 도착하느냐에 의해 주로 결정된다. 이를 이해하기 위해, 먼저 a는 패킷이 큐에 도착하는 평균율이라고 하자(a의 단위는 패킷/초). R은 전송률, 즉 비트가 큐에서 밀려나는 비율(비트/초)임을 기억하자. 또한 편의상 모든 패킷이 L비트라고 가정하자. 이때 비트가 큐에 도착하는 평균율은 La비트/초이다. 끝으로, 큐가 매우 커서 무한대 비트를 저장할 수 있다고 가정한다. 트래픽 강도(traffic intensity), 즉 La/R은 큐잉 지연의 정도를 측정하는 데 매우 중요하다. La/R > 1이면, 비트가 큐에 도착하는 평균율이 비트가 큐에서 전송되는 비율을 초과한다. 이 경우에 큐는 끝없이 증가하고 큐잉 지연은 무한대에 도달한다. 따라서 트래픽 공학의 주요 규칙 중 하나는 “트래픽 강도가 1보다 크지 않게 시스템을 설계하라”는 것이다.


- La/R <= 1인 경우를 생각해보자. 여기서 도착 트래픽의 특성이 큐잉 지연에 영향을 미친다. 예를 들어 패킷이 주기적으로 도착한다면, 즉 하나의 패킷이 L/R초마다 도착한다면, 이때 모든 패킷은 빈 큐에 도착할 것이고 큐잉 지연은 없을 것이다. 반면에 패킷이 주기적이 아니라 몰려서(burst) 도착한다면, 상당한 평균 큐잉 지연이 생길 것이다. 예를 들어, N개 패킷이 동시에 (L/R)N ...


- 주기적인 도착에 대한 앞의 두 예는 다소 이론적인 것이다. 일반적으로 큐에 도착하는 프로세스는 랜덤(random)하다. 즉, 패킷의 도착에 전혀 고정된 패턴이 없다. 패킷은 임의의 시간만큼 떨어져서 도착하게 된다. 사실 현실적인 경우 La/R은 지연에 대한 통계를 완전히 분석하는 데 충분하지 않다. 그럼에도 불구하고 큐잉 지연에 대한 어느 정도의 직관적 이해를 얻는 데 유용하다. 특히 트래픽 강도가 0에 가까우면, 패킷 도착이 드물고 간격이 멀어서 다음에 도착하는 패킷이 큐에서 다른 패킷을 발견하는 경우가 없을 것이다. 그래서 평균 큐잉 지연은 0에 가까워진다. 반면에 트래픽 강도가 1에 가까우면, 패킷 도착이 전송용량을 초과하여 큐가 생성될 것이다. 트래픽 강도가 1에 접근할수록 평균 큐 길이는 점점 증가한다.


<패킷 손실>

- 현실에서 큐의 용량은 스위치 설계와 비용에 크게 의존하며, 일반적으로 유한 용량을 가진다. 큐 용량이 유한하기 때문에, 트래픽 강도가 1에 접근함에 따라 패킷 지연이 실제로 무한대가 되진 않는다. 대신에, 패킷이 도착해서 큐가 꽉 찬 것을 발견하게 된다. 이렇게 패킷을 저장할 수 없는 경우에 라우터는 그 패킷을 버린다. 즉, 그 패킷을 잃어버린다.


- 종단 시스템 입장에서 이는 패킷이 네트워크 코어로 전송되었으나 네트워크로부터 목적지에 나타나지 않는 것으로 보일 것이다.


- 손실 패킷의 비율은 트래픽 강도가 클수록 증가한다. 그러므로 노드에서의 성능은 흔히 지연뿐 아니라 패킷 손실 확률로도 측정한다.(손실 패킷은 애플리케이션 계층이나 트랜스포트 계층 프로토콜에 의해 종단 간에 재전송 될 수 있다)


<종단 간의 지연>

- 지금까지 노드 지연, 즉 한 라우터에서의 지연에 대하여 초점을 맞추었다. 이제 근원지에서 목적지까지의 지연을 살펴보자


- 근원지 호스트와 목적지 호스트 사이에 N-1개의 라우터가 있다고 하자. 그리고 네트워크가 혼잡하지 않으며(큐잉 지연을 무시할 수 있음), 각 라우터와 근원지 호스트의 처리지연은 dproc이고 각 호스트와 근원지 호스트에서의 전송률은 R 비트/초이다. 그리고 각 링크에서의 전파지연은 dprop라고 하자. 이제 노드 지연을 더하여 종단 간의 지연을 얻을 수 있다.

dend-end = N(dproc + dtrans + dprop)

여기서 dtrans = L/R이고, L은 패킷 크기이다.

+ Recent posts