devrepo

[운영체제] 디스크 스케쥴링(Disk Scheduling)은 어떻게 일어날까

TIlearn — Mon, 13 May 2024 16:34:57 +0900

디스크의 구조

디스크 스케쥴링을 알아보기 전에 디스크의 구조에 대해 자세히 알아보자.

디스크는 아래와 같이 구성된다.

디스크는 크게 track과 sector로 구성된다.

먼저 track은 한 면에 존재하는 것으로 위 그림에서 원의 안쪽으로 들어갈수록 트랙 번호가 커진다.

약간 달리기 경주할 때 track으로 생각하면 쉽다.

sector는 각 트랙에 존재하는 부분으로 한 sector를 읽음으로써 보통 데이터를 가져올 수 있다.

cylinder는 같은 위치에 있는 트랙들을 의미하고, surface는 디스크의 한 면을 의미한다.

디스크를 읽기 위해서는 디스크 암을 통해서 읽어야 한다. 이때, 디스크의 head에서 sector 값을 직접적으로 읽는다.

sector와 sector 사이에는 보이지 않는 책선이 존재한다. 이러한 책선에서 보통 데이터가 오류가 있는지 없는지 검증하는 오류 검사를 진행한다. 그렇기 때문에 너무 많은 데이터를 담도록 sector를 두지는 않는다.

디스크는 보통 다음과 같은 구조로 각 요소들을 둔다.

1개의 disk pack = 1개 이상의 disk
1개의 disk = 1~2개의 surface
1개의 surface = 20 ~ 1500 tracks
1 track = 4 ~ 20개의 sectors
1 sectors = 32 ~ 4096개의 blocks
1 block = 하나 이상의 sectors
Rotation 속도 = 3600 ~ 7200 rpm(3600 rpm은 1초에 60번 회전한다.)

디스크를 읽는 순서는 하나의 트랙에 있는 섹터(블록)를 전부 돈 후에 그다음 cylinder를 돈다. 이후 다시 안쪽 트랙으로 들어간다.

이러한 방식 덕분에 연속적인 블록 배열을 표현할 수 있는 것이다.

디스크 I/O 전송 시간

_Wait for Device_는 디스크가 충분히 1초에 60번 돌아갈 때까지 걸리는 시간을 의미한다.

_Seek Time_은 원하는 트랙으로 이동하기까지 걸리는 시간을 말하며,

_Rotational Delay_는 암이 원하는 Sector까지 이동하는 데 걸리는 시간을 말한다.

_Data Transfer_는 Sector에서 데이터를 실제로 읽는 데 걸리는 시간이다.

_Access Time_은 _Seek Time_과 _Rotational Delay_를 합한 것을 말한다.

CPU입장에서는 실제로 _Seek Time_를 줄이는 것이 성능을 향상할 수 있는 요소이기 때문에 이를 줄이는 것이 중요하다.

따라서 디스크 스케쥴링을 통해 _Seek Time_을 줄일 수 있도록 해야 한다.

디스크 스케쥴링 : FIFO

트랙이 온 순서대로 처리하는 것이다.

하지만, 트랙을 처리하기 위해 너무나 많은 거리를 거쳐야 한다. _Access Time_이 커져 성능이 안 좋아지는 것이다.

이를 해결하기 위해 나온 것이 SSTF(Shortest Seek Time First)이다.

디스크 스케쥴링 : SSTF

이 방식은 제일 가까운 트랙을 찾아가는 방식이다.

하지만, 우선순위에 기반한 방식이기 때문에 만약 트랙 넘버가 치우쳐진 트랙들이 많다면, 뒤에 있는 트랙들은 Starvation으로 인해 접근하지 못하는 상황이 발생한다.

이런 문제점을 해결하기 위해 SCAN이라는 방식을 사용한다.

디스크 스케쥴링 : SCAN

SCAN은 Elevator Algorithm 또는 Look Policy라고도 불린다.

한 방향으로 움직이는 것이 특징인데, 이렇게 하면 Starvation 문제를 해결할 수 있다.

[운영체제] I/O Control : Polling, Interrupt Driven I/O, DMA방법이란?

TIlearn — Mon, 13 May 2024 13:15:21 +0900

I/O, 즉 입출력을 제어하는 방법에는 여러 가지가 있다.

Polling
Interrupt Driven I/O
Direct Memory Access(DMA)

위 방법 중에서 먼저 Polling 방법에 대해 알아보자.

Polling이란?

Polling을 이해하기 위해서는 입출력이 이루어지는 과정부터 이해할 필요가 있다.

그림에서 System Call이 먼저 호출된다.

앞서서 배웠던 것처럼, Interrupt에 의해 Kernel 영역으로 실행의 흐름이 옮겨진다.

이때 I/O Management에서 실제로 입/출력을 담당하는 장치가 무엇인지 판단한다. 이게 가능한 이유는 중간에 Device-drive-interface가 존재하기 때문이다. Device-drive-interface는 실제 Device Driver와 I/O Management를 이어주는 역할을 하기 때문에 어떠한 Device Driver가 오더라도 I/O Management와 호환시켜 준다.

Device Driver는 해당 장치를 만든 회사에서 구현해야 한다. 운영체제 입장에서는 너무나도 많은 장치가 자신의 운영체제에 장착(?)될 수 있기 때문에 호환시켜 줄 I/O Management만 필요하지, Device Driver를 구현할 필요는 없다. 이러한 Device Driver는 장치가 어떠한 입력이 주어졌을 때, 어떤 출력(동작)을 내놓을지 정의해 놓아야만 한다.

Polling을 한 줄로 설명하자면, "끝날 때까지 계속 묻는 것"이라고 할 수 있다. 이를 위해서 장치 내부의 레지스터의 동작 과정을 알아야 한다.

이는 생각보다 단순하다. 장치는 Control Register, Status Register, 그리고 Internal Buffer로 구성되는데, Control Register는 Command(명령)을 전달하기 위해 사용되는 레지스터이고, Status Register는 현재 I/O가 완료되었는지, 진행 중인지 혹은 오류 등이 일어났는지 알려주는 레지스터이다.

먼저, 모든 레지스터는 Controller안에 위치한다. 여기에 있는 레지스터 값을 Host와 Device가 바꾸어 가며, 입/출력 로직을 진행한다.

최초에 장치로 요청이 들어오면, Controller안의 busy bit이라는 비트를 읽으며, 해당 비트가 1일 때는 장치가 다른 작업을 하고 있으므로 I/O를 진행할 수 없는 상태라고 파악한다. 만약 1이 아닌 0이라면 Control register안에 있는 write bit를 1로 세팅하고, data-out register에 입력 바이트 값을 집어넣는다. 이 data-out register는 Internal Buffer에 해당되며, 임시로 데이터를 저장하는 역할을 한다.

여기까지의 상태를 command-ready 상태라고 하는데, 이는 Host가 Device한테 입/출력할 준비됐어요~하는 것과 같다.

이내, Controller는 command-ready가 1로 set 된 것을 보고 busy bit를 1로 set 한다. 장치는 이제 control register(write command)를 읽고, data-out register를 통해 입력 값을 받아들여 I/O를 수행한다.

Polling 한다는 것은 위와 같은 방식으로 동작하는 장치에 대해서 주기적으로 status를 확인하는 방식이다.

하지만, Device Driver의 코드를 계속해서 실행시켜하기 때문에 busy wating이 발생한다는 단점이 있다.(Pragrammed I/O)

Interrupt-Driven I/O란?

Polling 방식에서는 입/출력이 빠른 것에는 효율적이나, 입/출력이 느린 것에는 효율적이지 않다. 매번 busy waiting을 하기 때문이다.

이에 따라 Interrupt-Driven I/O 방식이 나오게 되었다.

이 방식은 User Process에서 I/O 요청이 일어나면, Device Driver가 Device를 실행할 수 있도록 하는데, 만약 Device가 I/O 작업에 들어가게 된다면 현재의 프로세스를 Block 시킨다.

즉, I/O 작업 중인 프로세스를 Block 상태로 만들어버리기 때문에 다른 프로세스에서 작업하는 게 가능하다.

여기서 Block 된 프로세스로 인해 다른 프로세스로 컨텍스트 스위치가 발생하여 새로운 프로세스로 넘어갔다고 해보자. 그러다가 CPU가 Block 된 프로세스의 I/O 작업이 완료되어 수행이 완료되었다는 IRQ(Interrupt Request)를 받게 되면, IRQ를 받음으로 인해 ISR(Interrupt Service Routine)이 실행되고 인터럽트에 대한 함수를 처리한다. 그리고, Block 된 프로세스를 Ready 상태로 변경시킨다.

이제, Kernel Mode에서 프로세스로 돌아가야 한다. 이때 돌아가기 전에 프로세스에 도착한 시그널이 있는지, 혹은 남은 ISR이 있는지 등을 확인한다.

중요한 것은 이제 어떤 프로세스로 돌아갈 것이냐이다.

I/O작업이 완료된 프로세스로 돌아갈 것인지, 혹은 새로운 프로세스로 돌아갈 것인지 선택해야 한다.

이러한 과정은 스케쥴러가 결정하며, 만약 I/O 작업이 완료된 프로세스의 우선순위가 더 높다면 해당 프로세스로 돌아간다.

Direct Memory Access(DMA)

입/출력은 항상 Processor를 거쳐서 들어가거나 나간다.

하지만 입/출력이 굉장히 많아진다면, 인터럽트도 엄청나게 많이 나온다. 그러면 사용자 프로그램은 정상적으로 돌아가기 어려울 것이다.

이러한 문제를 해결하기 위해 나온 것이 DMA이다.

프로세서는 I/O 작업을 DMA 모듈로 위임한다. 이때 DMA 모듈은 하나가 아니라 여러 개가 될 수 있기 때문에 여러 I/O를 프로세서의 현재 동작과 관계없이 수행할 수 있다.

이후, I/O작업이 종료되면, DMA는 쌓아놓은 I/O 처리 결과를 프로세서로 한 번에 송신한다.

[운영체제] 인터럽트란 무엇이고, 어떻게 발생할까

TIlearn — Sun, 12 May 2024 15:56:47 +0900

커널로의 진입이 필요한 시점은 3가지 존재한다.

Interrupt
Trap (software interrupt)
System Call

이 중에서 인터럽트가 어떻게 커널 코드로 들어가고 어떤 처리가 일어나는지 알아보자.

인터럽트란?

인터럽트란 비동기적 이벤트가 발생했다는 사실을 주변장치로 알리는 방법을 뜻한다. 여기서 비동기란 이벤트가 언제 일어날 지 알 수 없다는 뜻인데, 이는 우리가 키보드를 언제 두드릴지 모르는 것과 같다고 생각하자.

반대로 동기란 이벤트가 일어날 시간이 정해져 있다는 뜻이다.

인터럽트가 발생하면 가장 먼저 PIC(Programmable Interrupt Controller)에 신호가 도착한다. PIC 칩은 곧장 CPU로 신호를 전달하는 프로세스를 거친다.

이때 Clock 인터럽트만 다른 인터럽트와 달리 PIC를 거치지 않고, 바로 CPU로 신호를 전달하는데, 이는 Clock 인터럽트가 굉장히 자주 일어나기 때문이다.

프로그램이 실행되는 도중에 CPU는 매번 인터럽트가 발생했는 지 확인한다. 만약 발생하지 않았다면 그대로 인스트럭션을 실행하지만, 발생했다면 인터럽트에 대한 처리를 진행한다.

만약 인터럽트가 발생하면, 실행 중인 프로세스는 곧장 커널 모드로 바꾼다. 그리곤, 레지스터 값들을 커널 스택에 저장하는데, 만약 이미 커널 모드 중에 있다면 굳이 Mode Change를 진행하지 않는다.

커널 모드로 바뀐 이후, 이제 인터럽트 핸들러(Interrupt Handler)를 실행한다. 인터럽트 핸들러는 누가 인터럽트를 발생시켰는지 확인하는 역할을 한다. 만약, PIC 쪽에서 연결된 인터럽트가 발생했다면, PIC가 해당 인터럽트에 대한 번호를 반환한다.

인터럽트 핸들러는 해당 번호를 받아, IDT(Interrupt Descriptor Table) = IVT라는 테이블에 등록된 함수를 실행한다. 이 함수는 실제로 인터럽트를 처리하는 함수가 된다. 다른 말로 Interrupt Service Routine(ISR)이라고도 한다.

이전에 Time Slice마다, 컨텍스트 스위치가 일어난다는 것을 배운 적이 있다. 이때 Time Slice를 판단하는 것도 사실, Clock Interrupt에 의해 수행된다. Clock Interrupt가 걸릴 때마다 IDT에서 time_intr()함수를 호출하여 count값을 증가시키기 때문이다. 이를 통해 1ms마다 count값이 100이 될 때까지 증가시키고, 100번째가 된다면 다른 프로세스로 콘텍스트 스위치 할 수 있도록 한다.

왜 1ms까지 매번 커널로 들어가야 할까?

운영체제로써, 미뤄놓았던 커널에서의 처리를 해야 하는데, 만약 100ms마다 커널로 들어간다면, 그 사이에는 확인할 수 없다. 즉, 한 번 들어갈때 운영체제에서 해야 할 부가적인 일을 처리하고 나오기 때문에 매번 들어가야 한다.

인터럽트가 처리되는 부분

인터럽트를 처리하는 부분은 사실 두 두분이다.

왜냐하면, 급하게 처리야 할 부분과 나중에 미뤄놓아도 좋을 부분을 분리하는 것이 좋기 때문이다. 예를 들어, 매우 중요한 커널 작업을 수행하는 도중에 수행 시간이 긴 장치 인터럽트가 걸린다면 굉장히 위험한 상황이 발생할 것이다.

따라서, ISR은 급하게 빨리 해야 할 일은 빠르게 실행하고, 미뤄놓아도 좋을 것은 뒤로 미룬다.

인터럽트 중간에 인터럽트가 발생한다면?

인터럽트 중간에 다른 인터럽트가 발생할 수 있다.

이때, 즉시 인터럽트 처리해야 할 것은 바로 처리하게 되는데 이때 아래와 같이 nested interrupt 형태가 된다.

위 그림에서 빨간 부분을 살펴보자.

해당 부분은 유저 프로그램으로 돌아가기 이전의 상황이다. 이때 곧바로 유저 프로그램으로 돌아가지 않고, 부가적인 일을 수행하게 된다.

여기서 말하는 부가적인 일이란 아래와 같은 것들이다.

미뤄놓은 인터럽트에 대한 처리
새로운 시그널이 오지 않았는지 확인
새로운 프로세스가 도착하지 않았는 지 등 확인

Trap Hanlding

Trap이란 동기적인 소프트웨어 인터럽트를 실행한다.

예를 들어, 0으로 나눈 경우 Divide by Zero 오류와 같은 것이나, 유효하지 않은 Machine code, Sementation fault(허용되지 않은 메모리 주소), protection fault(읽기만 허용되고 쓸 수는 없을 때 쓰려고 한 경우), page fault(실행해야 하는 메인 메모리에 없는 경우)등이 될 수 있다.

중요한 것은 page fault를 제외하고는 전부 프로그램을 중지시킨다. 오직 page fault만이 프로그램을 중지시키지 않는다.

소프트웨어 인터럽트이지만, 인터럽트를 거는 주체는 CPU이다.

Trap이 걸리면, 일단 프로세스를 중단시키고 커널로 들어가야 한다. 따라서, 커널 스택에 레지스터 값을 저장하고 똑같이 인터럽트 핸들러를 실행시키며 ISR 함수를 통해 인터럽트 함수를 처리한다.

System Call

System Call이란 프로세스가 운영체제에게 요청을 보내는 것을 말한다.

이때, 입력과 출력 외에도 System call을 부르는 경우는 많다.

유저 프로그램에서도 System Call이 불러지면, 처음에는 어셈블리 인스트럭션을 통해 명령을 수행한다. 이러한 어셈블리 인스트럭션은 IDT상에서 _0x80_ 메모리 주소 상의 값을 수행하도록 하는데, 여기에는 system call 함수가 존재한다.

sys call table이 존재하는 이유는 system call에 종류가 굉장히 많기 때문이다.

[운영체제] 입/출력 관리(I/O Management)

TIlearn — Mon, 6 May 2024 11:36:43 +0900

I/O Devices의 종류

I/O Devices는 입/출력을 관리하는 장치로 목적에 따라 여러 종류가 있다.

먼저, 키보드나 마우스, 디스플레이 등의 사람이 이용하는 장치가 있다. 그리고 센서나 Controllers, Actuators, Disk, tape driver 등의 기계가 이용하는 장치가 있으며 모뎀 등의 통신을 위한 장치가 존재한다.

세상에는 너무 많은 장치들이 있고, 운영체제 또한 다양하기 때문에 각 운영체제에 맞는 장치들을 적절히 잘 끼워넣을 필요가 있다.

어떤 방식으로 끼워넣는지 살펴보기 이전에 입/출력 장치의 일반적인 구성에 대해 알아보자.

I/O Devices

I/O Devices는 대개 3 개의 요소로 이루어진다.

Controller Register, Status Register, Internel Buffer이다.

엥? Register는 CPU에만 있는 게 아닌가? Devices에서 왜 Register가 들어갈까? 라는 생각이 들 수 있다.

맞는 말이다. 실제로도 Device 자체에 Register가 있는 게 아니라 Device driver가 Register값을 변경시킴으로써, Device로 전기적인 신호를 보낸다.

Controller Register이 하는 역할은 보통 Device가 1과 0을 통해서 해야할 명령을 수행한다.

Status Register는 현재 I/O 작업이 수행 전인지, 수행 중인지, 수행이 끝났는 지 체크한다.

I/O Management

앞서 말했듯이, 세상에는 너무 많은 장치들과 운영체제가 있기 때문에 이들 간의 호환성 문제를 해결하는 것은 매우 중요하다.

따라서 운영체제 자체에서 Status Register를 관리하는 것은 옳지 않다. 각 장치들마다 Status Register에 따라 동작하는 방식이 다를 수도 있기 때문이다.

그렇기 때문에 Kernel 영역이나, I/O만을 담당하는 특수한 커널 계층을 만들게 되었다. 바로 "Kernel I/O Subsystem"인 것이다.

이에 따라 그 밑의 하드웨어 단에서도 변화가 생겼다. 그냥 Device 자체를 연결시키는 것은 무리이기 때문에 이를 모듈 형태로 구현하였다. 모듈 형태로 구현한다면 쉽게 탈/부착 가능하기 때문이다.

하드웨어 영역은 Device와 Device Controller로 분리하였고, 소프트웨어 영역은 Device Driver와 Kernel I/O SubSystem으로 분리하였다. 소프트웨어 영역의 Device Driver를 통해 실제로 하드웨어에 접근하여 관리를 할 수 있게 된 것이다.

그렇기 때문에 Device Driver는 각 제조사 측에서 만들어야 한다.

device driver만 만들면 끝일까? Kernel I/O subsystem 상에서의 I/O 명령을 모든 device driver가 전부 수용할 수 있을까? 안그래도 OS도 여러가지인데 쉽지는 않을 것이다.

그렇기에 만든 것이 device-driver interface이다.

인터페이스란 서로 다른 구현체(여기서는 장치들)이더라도, 인터페이스를 통해서 동일한 명령을 수행하면 구현체에 따른 적합한 행동을 한다.

device driver가 여러 가지이더라도 운영체제에 맞는 device-driver interface를 작성한다면 문제 없을 것이다.

실제로 프로세스가 명령을 내리면, Device는 위와 같은 과정을 통해 명령을 수행한다.

특이한 것은 DDI(Device Driver Interface)가 마치 File System과 같이 동작한다는 것이다. 마치 파일을 읽고 쓰는 것 마냥 장치를 읽고 쓰도록 한다.

kernel I/O Management

I/O만 담당한다고 했던 _Kernel I/O Management_가 실제로 수행하는 역할은 무엇인지 한번 살펴보자.

Device Reservation
- 장치를 예약하고 할당한다.
- 앞서서 다른 작업을 하고 있다면, 대기 큐에 집어넣고 다른 작업을 수행한다.
Device Scheduling
- 큐에 들어가 있는 작업 중에서 어떤 작업을 수행할 지 정한다.
- 큐이지만, 들어온대로 작업을 하지 않을 수도 있다. 이는 "성능" 때문이다.
- 프로세스 스케쥴링(=프로세서 스케쥴링)과 비슷한 맥락이다.
Error Handling
- 디바이스 드라이버가 장치에 오류가 발생했음을 알린다.
Buffering
- 입/출력 내용을 임시로 저장한다
- 커널 메모리 안에 저장한다.
- 목적은 다음과 같다.
  - 장치와 커널간의 속도 차이를 극복하기 위해서
  - 대량의 내용을 전달하기 위해 사이즈를 조절
  - 출력 버튼을 눌렀을 때의 내용만을 출력하기 위해서 = Copy Semantics
Caching
- 컴퓨터의 실행 속도를 높이기 위해 커널 메모리 상에 임시로 데이터를 저장한다.
Spooling
- 보조 기억 장치의 공간의 일부를 출력을 위해 사용한다.

[운영체제] 파일 시스템 사례(Linux)

TIlearn — Sun, 5 May 2024 12:12:26 +0900

Unix에서의 파일 관리

이전에 알아보았듯이, Unix에서는 위와 같은 파일 시스템 구조를 지닌다.

inode는 특정한 파일에 대한 주요 정보를 가지고 있는 제어 구조라고 했다. 여기에는 직/간접적으로 연결되어 있는 파일들의 개수인 Link Count 등의 정보가 들어간다고 하였다. 또한 unix에서의 inode가 파일에 대한 제어 정보를 가지고 있는 FCB와 대응된다는 것도 기억해 보자.

자 이제 기억해야 할 것은 각각의 inode는 파일에 대한 제어 정보를 가지고 있다는 것이고, 여기서 파일을 저장하기 위해 _indexed allocation_ 방식을 사용한다는 것이다.

indexed allocation은 파일의 정보를 저장하기 위해 특정 Block을 Index를 관리하는 Block으로 두는 방식이었다. 여기서 특정 Block은 Index Block이라고 부르며 다른 Data Block들과 동일하게 취급한다.

아무튼, inode 안에서 Data Block을 관리하기 위해 정확히는 아래와 같은 구조를 사용한다.

그림을 보면 10개의 Direct Block과 3개의 Indirect Blocks가 있다.

먼저 Direct Block은 가장 먼저 저장되는 Data Block들에 대한 번호들을 저장한 Index Block이다. Direct Block 하나가 2^10인 1024Byte만큼의 Data Block들을 저장할 수 있기 때문에 총 10 * 2^10 * 4 = 40KB 만큼이 10개의 Direct Block의 크기라고 본다.

다음으로 Single Indirect는 Direct Block만으로도 파일의 크기를 전부 담을 수 없을 때 사용하는 Block이다.

여기에는 하나당 4KB인 Index Block들 자체들를 저장하는 간접적인 Block 하나를 사용한다. 하나의 Block은 1024개만큼의 Block 주소를 담을 수 있기 때문에 총 4KB * 2^10 = 4MB의 공간을 저장할 수 있다.

Double Indirect는 Single Indirect 만으로도 크기가 부족할 때 사용하는 것인데, 원리는 Single Indirect와 유사하다.

4MB만큼의 공간을 가지는 하나의 Index Block자체들을 저장하는 간접적인 Block하나를 추가로 만드는 것이다. 그러면, 총 4MB * 2^10 = 4GB만큼의 공간을 저장할 수 있다.

Triple Indriect도 4GB만큼의 공간을 가지는 Index Block들을 저장하는 간접적인 Block 하나를 추가하여 총 4TB만큼의 공간을 가질 수 있다.

즉, 하나의 Inode는 4KB + 4MB + 4GB + 4TB의 공간을 가질 수 있다.

Linux Virtual File System

리눅스에서도 파일 시스템의 종류에 관계없이 쉽게 유저가 파일에 접근하고 사용할 수 있도록 하기 위해 Virtual File System을 제공한다.

그림과 같이 파일 시스템이 달라지더라도 하나의 모듈로써 파일 시스템의 종류를 커널 안으로 넣을 수 있다. 이로 인해 사용자는 굳이 신경 쓰지 않더라도 File System을 이용 가능하다.

위에 보이는 _page cache_는 _disk cache_와 같은 의미로 disk에서 block을 읽어오면 임시로 저장하는 공간이라고 생각하면 된다.

Linux inode

모든 inode의 구조가 동일한 것은 아니다. 운영체제마다 조금씩 차이점이 존재한다.

Linux에서는 10개의 Direct Blocks를 사용하는 Unix와 달리 Direct Blocks를 12개 사용한다.

또한 파일 시스템의 종류에 따라서 inode의 크기 또한 다르다.

ext2, ext3에서는 128바이트
ext4에서는 256바이트이다.

File Operation

System Call은 프로세스가 운영체제에게 알리는 이벤트라고 하였다. File Operation도 결국 System Call이기 때문에 프로세스가 해당 이벤트를 알린다. 하지만, File에서 사용하는 System Call은 장치, 혹은 타입마다 다르기 때문에 특별한 테이블 구조를 만들어 사용한다.

위 그림과 같이 파일 시스템, 혹은 장치에 따라 같은 종류의 _open_함수이더라도 다른 동작을 해야 하는 경우가 생긴다.

NFS에서는 _nfs file open_함수가 불러지면, 다른 PC와 remote 통신을 하는 추가 작업이 수행될 수 있다.

즉, 각 테이블에는 그 목적에 부합한 함수들이 각각 구현되어 있다.

Linux File Operation

리눅스에서 File Operation이 수행되는 흐름은 위와 같다.

먼저 새로운 프로세스가 만들어지면 task struct라는 구조가 만들어진다. 이는 PCB와 동일한 것이고 이 안에 file structure 정보를 가진다.

file structure은 파일 시스템 아래에 있는 파일들에 참조 정보를 지닌다. 또한 각각의 파일들은 파일 시스템 내부에 정의된 구조에 따라서 inode라는 FCB정보를 가진다. 이는 어떤 파일 시스템을 가지냐에 따라 구조가 달라질 수 있다.

마지막으로 inode는 Disk 내부에 저장된 Block 할당 방식에 따라 파일 정보를 저장한다.

실제로 실행되는 코드를 살펴보자.

task struct와 files struct는 프로세스 단에서 실행되는 것이고, struct file과 file operation을 저장한 테이블인 file operations는 운영체제가 만들어 관리한다.

이때 file operation은 실행되는 파일 시스템 모듈에 따라 달리질 수 있음을 기억해 보자.

위와 같이 장치나 파일 시스템에 따라 open함수도 여러 File Operation 테이블에 따라 동작한다.

[운영체제] 데이터 블록(Data Block)의 관리

TIlearn — Sun, 5 May 2024 10:05:13 +0900

파일 시스템에서의 Data Blcok

파일에서는 Block이라고 하는 것을 저장단위로 사용한다.

이 Block 하나의 크기는 4096바이트이다.

디스크에서 파일을 저장할 때, Block을 무작위로 저장하지는 않는다. 어떻게 배치하느냐에 따라 그 전략이 달라진다.

우선, 지금은 잘 사용하지 않는 _Contiguous Allocation_에 대해 알아보자.

Contiguous Allocation

이름을 보고 유추할 수 있듯이, _Contiguous Allocation_방식은 파일을 저장할 때 연속적으로 Block을 배치한다.

이 방식을 사용하면 File Allocation Table을 사용하는데, 여기에 파일의 시작 Block과 Block의 길이를 저장한다. 물론 파일의 FCB에서도 파일의 시작 Block과 Block의 길이 정보를 같이 저장한다.

하지만, 이 방식을 굉장히 좋지 못한데 그 이유는 크게 두 가지다.

첫 번째로, _external fragmentation_이 발생한다.

fragmentation은 데이터가 연속적으로 저장됨으로 인해 부분적으로 빈 공간이 발생하는 것을 말한다. 이때 각 파일의 외부 공간에 대해서 fragmentation이 발생하는 것을 _external fragmentation_이라고 한다.

파일 내부에서 발생하는 fragmentation은 internal fragmentation이라고 한다.

두 번째는 파일 크기를 늘리기가 힘들다는 것이다.

각각의 파일들은 연속적으로 자리를 차지하고 있다. 그렇기 때문에 fragmentation에서는 부분적으로 공간을 늘릴 수는 있으나, 원하는 만큼 크게 늘리진 못한다. 만약 옮기고 싶다면 전체를 복사해서 새로운 공간에 할당해야 하기 때문에 시간도 굉장히 많이 든다.

위와 같은 단점들로 인해 Contiguous Allocation은 사용하지 않는다.

Chained Allocation(Linked Allocation)

이 방식은 Linked List를 사용하는 방법으로 생각하면 쉽다.

각 Block이 그다음 Block의 참조를 가진다. 따라서 _external fragmentaion_과 같은 문제는 없어진다.

하지만 이렇게 참조를 기반으로 연결되어 있다는 특성 때문에 또 다른 문제가 발생한다.

먼저, Block을 탐색하다가 중간에 참조가 끊어지면 그 뒤에 있는 Block은 읽지 못한다. 또한 하나의 파일 안에서 특정 블록에 대해 바로 접근하는 _direct access_가 불가능하다.

이러한 문제를 해결하기 위해 나온 것이 _indexed allocation_이다.

Indexed Allocation

_index allocation_은 여러 Block 중 임의로 하나를 파일의 인덱스를 관리하는 Block으로 만드는 방식이다.

이 방식으로 사용하면, 해당 Block은 파일을 구성하는 다른 Block들에 대한 정보를 순서대로 지니고 있게 된다.

즉, _Direct Access_가 가능하고, _Fragmentation_도 없다.

Free-Space Management

빈 공간을 관리하는 방법에도 여러 종류가 있다.

counting

counting 방식은 간단하게 시작 Block 번호와 해당 Block으로 부터 얼마만큼 Free Block인지 세는 방법이다.

Linked List (free list)

앞서 파일을 관리하는 방식 중, Chained allocation과 굉장히 유사하다.

마찬가지로 Free Block 들을 Linked List로 관리하여 공간을 관리한다.

이때, 새로운 Free Block을 할당하기 위해서 맨 앞의 head 값을 사용하기 때문에 할당은 간단하다.

하지만, 여전히 하나의 Block의 참조가 끊키면 다른 Block들도 다 못 사용하기 때문에 좋지 않다.

Grouping

이 방식은 앞선 Indexed Allocation 방식과 유사하다.

임의의 Block이 Free Block들에 대해 관리하는 방식이다.

하지만 Free Block들이 적지는 않다. 고작 4096바이트 밖에 되지 않고, 하나의 Free Block을 기록하기 위해 4바이트를 사용하여 총 1024개의 Free Block을 적을 수 있을 텐데, 어떻게 많은 Free Block을 관리할 수 있을까?

이는 바로 Grouping에서 사용하는 특수한 저장 방식으로 해결 가능하다.

초기에 Free Block들을 관리하기 위해 Super Block List에 모든 Free Block 정보를 넣는다. 여기 안에서 하나씩 꺼내서 각각의 Free Block들을 할당하는데, 만약 Free Block들이 너무 많아진다면 마지막으로 저장한 Free Block으로 이동하여 새롭게 Free Block을 저장한다.

위의 예시에서는 109번이 마지막으로 저장되므로 109번 Block으로 가서 다시 처음부터 Free Block을 저장한다.

사용하는 것도 마찬가지다.

109번 Block앞의 모든 Block을 전부 사용했다면 109번 Block을 Free Block에서 Block으로 할당하기 위해, 109번 Block 안에 있던 모든 정보를 Super Block List로 전부 이동시킨다.

Bit-vector

마지막으로 Bit-vector 방식인데, 이 방식은 모든 Block 들에 대해 Free Block은 1로, 할당된 Block은 0으로 두는 방식이다.

개념적으로는 아주 간단하고 좋은 방식이나 모든 Block들을 저장하는데 8K disk Block이 필요하다.

[운영체제] 파일시스템이란?

TIlearn — Wed, 1 May 2024 10:20:14 +0900

File Systems

파일 시스템이란 파일들을 담아놓는 자료구조이자, 자료들을 처리하는 알고리즘을 포함하는 Logical storage unit을 말한다.

이러한 파일 시스템은 다음과 같은 요소로 구성한다.

Boot block
Partition control block(super block)
Directory structure
- 운영체제에 따라 있을 수도 있고, 없을 수도 있다.
File control blocks
Data blocks
- 실제 파일의 내용을 저장하는 곳이다.

논리적으로 디스크를 나누어 놓은 것을 파티션이라고 하는데, 각 파티션에는 위와 같이 Partition Control Block이 존재한다. 여기에는 boot block, super block, FCB list와 data blocks로 이루어져 있다.

unix와 window에서도 이러한 구조를 살펴볼 수 있다.

unix에서 inode list가 FCB list이고, window에서는 master file table이 FCB list이다.

그리고 window에서 system files가 super block의 역할을 한다.

boot block은 부팅이 되는 과정에 있어 사용된다.

초기에 boot block에서 boot code가 나오고, 여기 있는 코드가 실행되며 OS 단으로 이동한다. 여기 있는 코드가 OS 영역의 코드를 메모리 내로 적재하는 것이다.

Partition Control Block (Super Block)

앞서 File System에 대해서 알아보았다.

이러한 File System은 독립적으로 존재하는 것이 아니라 누군가에 관리된다. 이를 해주는 것이 Partition Control Block이다.

Partition Control Block에는 다음과 같은 정보를 가진다.

File System의 사이즈(Block 개수)
File System의 빈 Data Block의 개수
빈 Data Block의 List
inode table안의 inode의 개수
File System안의 빈 inode의 개수
빈 inode의 List

File Control Blocks (inode List)

파일 하나 당 FCB가 하나씩 할당되는데, FCB(inode)들이 연결된 것을 inode List라고 한다.

각각의 inode는 128바이트만큼 영역을 차지한다.

또한 커널은 특정 inode를 구분하기 위해 배열에서 인덱스를 찾듯이 inode List에서도 인덱싱을 사용한다.

inode 2가 root 노드이다.

이때 관리자는 파일 시스템을 확인할 때 inode List의 사이즈를 가지고 있다.

[운영체제] 디렉토리를 알아보자.

TIlearn — Sun, 28 Apr 2024 21:32:04 +0900

File Directory

디렉토리는 파일들에 대한 정보를 가지고 있다.

이때 각각의 파일들은 그 자체로 존재하는 것이 아니라, 파일 원보으로 이어지는 포인터로 존재한다.

즉, 디렉터리는 각각의 파일 포인터인 FCB(File Control Block)를 지닌다.

디렉토리도 그 자체로 OS에 의해 소유되는 파일이다.

Hierarchical Directory

위 그림은 계층형 디렉토리(Hierarchical Directory)의 구조를 나타낸 것이다.

가장 위에 있는 요소를 _root_ 혹은 _master_라고 한다.

특히 현재 디렉토리를 _working directory_라고 하는데, 이러한 개념이 없다면 특정 파일의 경로를 구할 때 매우 힘들 것이다. 이는 _root_로부터 매번 경로를 절대적으로 확인해야하기 때문이다.

리눅스에서의 FCB 구조를 통해 더 쉽게 이해해보자.

_byte offset_은 현재 파일로 부터 위치한 상대적인 거리를 나타낸다. 그림과 같이 16바이트 단위로 파일들이 나열해있음을 확인해보면 된다.

_inode number_가 바로 FCB의 식별자이다. 이 값을 보고 계층형 구조에서 파일을 찾는게 가능해진다.

unix 운영체제에서는 _root_ 의 inode는 2번으로 고정되어있다. 이는 각 운영체제마다 다르다.

그러면 _root_ 로부터 특정 파일을 찾아갈 때까지의 흐름을 그림으로 살펴보자.

우선 _root_부터 시작해야 하므로, inode 2번에 저장된 주소 값을 읽어준다. 이 주소는 _root_ 디렉토리에 해당되는 주소이며 따라가면 _root_디렉토리의 data block이 나온다.

여기 data block에는 자기 자신, 부모 그리고 자신의 형제 노드에 대한 정보를 inode의 참조값 형태로 가지고 있다. 마찬가지로 연쇄적인 탐색이 가능한 것이다.

우리는 _/usr/member/list.txt_라는 파일을 탐색해보고자 한다. 즉, data block의 좌측에 적혀있는 번호(inode) 값을 통해 계속 찾아가야 한다.

_/user_ 디렉토리의 inode 값은 4이다. 이 inode의 값을 따라가 마찬가지로 data block을 찾아주자. 그러면 _/user_디렉토리에서도 자신의 자식 노드에 대한 정보를 찾을 수 있고, 여기서 _member_를 발견할 수 있다.

이러한 방식으로 파일에 대한 탐색을 진행한다면 결국 _list.txt_라는 파일에 도달할 수 있다.

Acyclic-Graph Directories

만약 어떤 동일한 파일을 찾기 위해서 두 가지 접근을 할 수 있다고 생각해보자. 예들들어 아래 그림과 같이 a라는 원본 자원과 직접 연결된 링크와 b라는 간접적으로 연결된 링크를 통해서 같은 자원에 도달할 수 있다. 이는 "바로가기"와 같은 기능을 떠올려보면 쉽게 구현 가능한 상황임을 짐작할 수 있다.

여기서 만약 a와 a밑에 연결된 파일의 자원을 지웠다고 해보자. 그러면 이미 자원은 없어진 상황인데, b는 a밑의 자원을 여전히 가리킨다. 이를 "dangling pointer"현상이라고 한다. 우리가 c언어에서 배웠던 그 "dangling pointer"와 의미적으로 거의 유사해보인다.

dangling pointer를 해결할 수 있는 방법은 총 2가지다.

그냥 가만히 두기.
- 바로가기 링크가 살아있어도, 클릭하면 "해당 파일이 없습니다"라는 에러문구가 주는 형식이다.
Entry-count solution
- 해당 자원을 가리키는 링크의 갯수를 FCB안에 저장해 놓는 방법이다.
- 예를 들어, a와 b가 모두 같은 파일을 가리킨다면 이 파일의 count값은 2이다.
- 이렇게 Entry-count값이 0이면 지워도 되지만, 0이 아니면 지우면 안된다.

그외 쓰지는 않는 해결방법 2가지

1. 직접 파일 시스템을 뒤져가며 링크를 지운다.
이는 시간이 너무 오래 걸리기 때문에 사용하지 않는다.

2. BackPointers
reference list라는 파일의 링크들을 모아놓은 리스트를 활용한다.
하지만, 구현 방법이 너무 복잡하여 잘 사용하지 않는다.

File Sharing

사용자가 여러 명일 때 같은 파일을 다룬다면 여러 문제가 발생할 수 있다.

하나는 접근 권한과 관련된 것이고, 다른 하나는 동시 접근과 관련된 것이다.

기본적으로 동시 접근에 있어서는 다음과 같은 방안을 취한다.

그대로 둔다.
파일이 사용 중이라면 lock한다.
파일의 일부인 record에 대해서만 lock한다.

이러한 동시 접근을 제대로 보장하기 위해서는 Mutual Exclusion을 지켜주어야 하며 DeadLock이 발생하지 않도록 해야한다.

Access Rights

개인과 그룹, 모든 사용자에 대한 파일 접근 권한을 관리하는 것은 매우 중요하다.

개인만 건드려야 하는 파일에 대해 내가 모르는 다른 사람들이 변경하는 상황이 발생하면 안되기 때문이다.

따라서 개인이 특정 유저, 그룹, 혹은 모든 유저들에게 컴퓨터 파일에 대한 접근 권한을 부여할 수 있다.

여기에는 읽기(read), 쓰기(write), 실행(execute)의 3가지 모드가 존재한다.

여기서 숫자 1은 가능하다는 것을 의미하고, 0은 가능하지 않음을 의미한다.

[데이터통신] Physical Layer 알아보기

TIlearn — Sun, 21 Apr 2024 14:05:25 +0900

아날로그 데이터 vs. 디지털 데이터

데이터는 아날로그 혹은 디지털의 형태일 수 있다. 아날로그 데이터는 "연속적인 정보"를 나타내는 데이터이고, 디지털 데이터는 "이산적인 상태"를 가지는 정보를 나타낸다. 예를 들어, 시곗바늘이 연속적으로 움직여 시/분/초의 정보를 알려주는 아날로그시계는 아날로그 데이터의 형태이고, 12:30분에서 12:31분으로 한 번에 시간이 변하는 디지털시계는 디지털 데이터의 형태이다.

경우에 따라 이러한 디지털 형태의 데이터를 아날로그 형태로 변환하거나 아날로그 형태를 디지털 형태로 바꾸어야 하는 상황이 발생한다. 하지만, 데이터는 일관적이지 않을 수 있다. 아날로그에서 의도한 값이 디지털로 변환했을 때 그러한 값이 아닐 수도 있으며 그 반대의 경우도 마찬가지이다.

위와 같은 상황은 주로 시간에 따라 반복되는 패턴이나 사이클이 나타나지 않는 비주기적 신호에서 나타난다. 반대로 주기적 신호는 측정 가능한 시간 프레임 내에서 패턴을 완료하고 이후 동일한 주기에 해당 패턴을 반복한다.

Sine Wave

사인파는 주기적인 아날로그 신호의 대표적인 형태이다.

특히 사인파는 세 가지 요소에 의해서 구분되어 질 수 있는데, 하나는 Amplitude, 다른 하나는 Frequency, 마지막은 Phase이다.

Amplitude가 다른 경우는 아래와 같다.

Frequency가 다른 경우는 아래와 같다.

이때 알 수 있는 것은 Hz가 크면 더 많은 패턴을 반복하고, 작으면 더 작은 패턴을 반복한다. 즉, Frequency는 시간에 따른 변화율이다. 따라서 Frequency가 크다는 것은 짧은 시간 동안 변화함을 의미한다.

만약 Frequency가 0이라면 신호가 전혀 바뀌지 않는 것이고, 무한대라면 신호가 순간적으로 변하는 것이다.

Phase는 다음과 같다.

Phase(위상)은 시간 0에 따른 파형의 위치를 의미한다. 이는 첫 번째 주기의 상태를 말하기도 한다.

Composite Signal

실제로 간단한 Sine Line가지고는 간단한 일밖에 하지 못한다. 전기 에너지 운반 혹은 간단한 부저음이 그러한 예시가 된다. 그렇기 때문에 복잡한 데이터 통신에서는 _Composite Signal_을 사용한다.

복합 신호(Composite Signal)는 다른 진폭, 주파수 및 위상을 갖는 간단한 사인파의 조합이다. 이러한 복합 신호는 주기적일 수도 있고, 비주기적일 수도 있다.

Bandwith(대역폭)

_Bandwith_란 복합 신호에 포함된 주파수의 범위이다. 이는 일반적으로 두 숫자의 차이로 구할 수 있다. 예를 들어, 복합 신호의 주파수가 1000과 5000 사이라면 _Bandwith_는 4000이다.

와이파이 대역폭을 생각해보자.

5 GHz는 대역폭도 넓기 때문에 좋긴 하나, 주파수가 크다는 것은 회절성이 안 좋다. 따라서 주변에 장애물이 있다면 별로 안 좋다. 반대로 2.4 GHZ는 주파수는 작지만, 회절성이 좋기 때문에 장애물이 있어도 멀리 뻗어나갈 수 있다.

Digital Signals

디지털 신호는 2개 이상의 신호를 가질 수 있다. 디지털 신호는 아날로그 신호와 달리 구별할 수 있는 단위가 amplitude밖에 없다.

비주기적인 데이터 신호를 구분할 수 있는 단위가 주기와 주파수로 표현하기에는 무리가 있다. 따라서 "비트 속도(Bits Rate)"라는 단위를 통해 디지털 신호를 구분한다. 이는 1초 동안 전송된 비트의 수, 즉 초당 비트 수(bps)로 표현한다.

데이터 통신에 있어서는 주기적 아날로그 신호와 비주기적 디지털 통신을 주로 사용한다.

Digital as Composite Analog

Fourier 분석에 따르면, 디지털 신호는 복합 아날로그 신호이다. 이때, 대역폭은 무한하다.(신호가 즉시 변경되면 그 주파수는 무한하다.).

디지털 신호의 전송

다음 두 가지 방법을 사용하여 디지털 신호를 전송할 수 있다.

베이스밴드 전송: 디지털 신호를 아날로그 신호로 변환하지 않고 채널을 통해 디지털 신호를 전송하는 것이다. (대역폭이 제로에서 시작하는 채널. 이는 대역폭이 하나의 채널로만 구성된 전용 매체인 경우의 경우이다.)
브로드밴드 전송 (변조): 전송을 위해 디지털 신호를 아날로그 신호로 변환하는 것이다. 변조를 통해 대역폭 채널 (제로에서 시작하지 않는 대역폭을 갖는 채널)을 사용할 수 있다.
- 변조는 대역폭이 제로에서 시작하지 않는 밴드패스 채널을 사용할 수 있도록 해준다.

신호 손상

손상 없이 모든 신호들을 보내는 것이 가능할까? 이는 불가능하다. 즉, 완벽하지 않은 전송매체를 통해서 전달되기 때문이며, 보낸 쪽과 받는 쪽의 데이터가 완벽하게 일치하지 않는다.

이렇게 신호가 손상되는 원인은 다음 세 가지로 구분될 수 있다.

감쇠(Attenuatoin)
- 감쇠는 에너지의 손실을 의미한다.
- 신호에 있는 일부의 전기 에너지가 열 에너지로 전환된다.
- 손상을 보충하기 위해 증폭기가 사용된다.

왜곡(Distortion)
- 신호의 형태나 모양을 바꾸는 것을 의미한다.
- 서로 다른 주파수를 가진 복합 신호에서 나타난다.
- 각 신호는 고유의 전파속도를 가지기 때문에 신호가 도착해도 고유의 지연이 발생한다.
- 이러한 지연의 차이가 주기 기간과 일치하지 않는다면 위상의 차이가 발생한다.

잡음(Noise)
- thermal noise, induced noise, crosstalk, impulse noise과 같은 여러 종류의 잡음이 신호를 손상시킨다.
- thermal noise는 전자의 무작위 운동으로 발생하는 추가 신호이다. 이는 전송 측에서는 없는 신호다.
- induced noise는 모터와 같은 원본에서 발생한다.
- crosstalk는 한 전선이 다른 전선에 미치는 영향이다.

SNR(Signal-to-Noise Ratio)

SNR은 Noise당 Signal을 의미하는데, 그래서 SNR이 크면 상대적으로 Noise가 적고, SNR이 작으면 상대적으로 Noise가 크다.

Data Rate Limit

채널을 통해 데이터를 얼마나 빠른 속도로 보내는 가를 계산하는 방법에는 두 가지가 있다. 하나는 노이즈가 없는 채널에 대한 니클리스트 공식이고, 다른 하나는 노이스가 있는 채널에 대한 샤넌의 공식이다.

니클리스트 공식
- BitRate = 2 * bandwith * log2 L
샤넌 공식
- 실제로는 채널은 항상 소음이 있다.
- Capacity = bandwith * log2(1+SNR)

L은 신호레벨

네트워크 성능 평가

네트워크 성능을 측정하는 한 가지 특성은 대역폭(Bandwith)이다.

두 가지 다른 맥락에서 사용되며 두 가지 다른 측정값을 갖는다
- 이는 헤르츠 단위의 대역폭과 초당 비트 단위의 대역폭이다.
헤르츠 단위의 대역폭
- 복합 신호에 포함된 주파수 범위 또는 채널이 전달할 수 있는 주파수 범위이다.
- 예를 들어, 가입자 전화 회선의 대역폭은 4 kHz라고 할 수 있다.
초당 비트 단위의 대역폭
- 채널, 링크 또는 심지어 네트워크가 전송할 수 있는 초당 비트 수이다.
- 예를 들어, 패스트 이더넷 네트워크 (또는 이 네트워크의 링크)의 대역폭이 최대 100 Mbps라고 할 수 있다.
- 이것은 이 네트워크가 100 Mbps를 보낼 수 있다는 것을 의미합니다.
기본적으로, 헤르츠 단위의 대역폭이 증가하면 초당 비트 단위의 대역폭도 증가한다.

성능을 평가하는 지표 중 다른 하나인 처리량(Throuput)은 네트워크를 통해 실제로 데이터를 전송할 수 있는 속도의 측정값이다.

초당 비트 단위의 대역폭과 처리량은 처음에는 같아 보이지만 실제로는 다르다.
한 링크의 대역폭이 B bps일 수 있지만, 실제로는 이 링크를 통해 항상 B보다 작은 T bps만 전송할 수 있다.
대역폭은 링크의 잠재적인 측정값이며, 처리량(Throuput)은 실제로 데이터를 얼마나 빠르게 전송할 수 있는지의 실제 측정값이다.
예를 들어, 대역폭이 1 Mbps인 링크가 있을 수 있지만, 링크 끝에 연결된 장치는 200 kbps만 처리할 수 있을 수 있다. 이는 이 링크를 통해 200 kbps보다 많은 데이터를 전송할 수 없다는 것을 의미한다.

Latency(지연)

지연 또는 지연 시간은 첫 번째 비트가 출발지에서 전송된 시점부터 전체 메시지가 목적지에 완전히 도착하는 데 걸리는 시간을 정의한다.

지연은 전파 시간(propagation time), 전송 시간(transmission time), 대기 시간(queuing time) 및 처리 지연(processing delay)의 네 가지 구성 요소로 이루어져 있다. 꽤 중요하므로 공식까지 제대로 알아야 한다.

전파 시간(Propagation time)
- 데이터가 출발지에서 목적지까지 도달하는데 걸리는 시간
- 계산 방법은 거리 / 전파속도
- $d$: 물리적 링크의 길이
- $s$: 매체 내 전파 속도 (약 2x10^8 m/sec)
- $d_{\text {prop}} = \frac {d}{s}$

만약 두 지점 사이의 거리가 12,000km이고, 케이블 내에서의 전파 속도가 초당 2.4 × 10^8미터라면, 전파 시간은 50ms(밀리초)가 된다. 이는 대서양을 건너는 데이터가 50ms만에 전달될 수 있음을 의미한다.

(12000 * 1000) / (2.4 * 10^8) = 50ms

전송 시간(Transmission Time)
- 실제로 데이터를 전송할 때는, 단 하나의 비트만 보내는 것이 아니라, 여러 비트로 이루어진 메시지를 보낸다. 첫 번째 비트는 전파 시간만큼의 시간이 걸려 도착하지만, 메시지의 크기와 채널의 대역폭에 따라 마지막 비트가 도착하는 데까지 걸리는 시간이 달라지기 때문이다.
- 계산 방법은 메세지 크기 / 대역폭이다.
- $L$: 패킷 길이 (비트)
- $R$: 링크 대역폭 (bps)
- $d_{\text {trans}} = \frac {L}{R}$

※ 전파 시간 vs. 전송 시간

어느 것이 더 중요한가는 상황에 따라 다르다.

2.5KB 메시지의 경우, 대역폭이 1Gbps이고 거리가 12,000km일 때, 전파 시간이 전송 시간보다 주요한 요소가 된다. 즉, 메시지가 짧고 대역폭이 높아서 전송 시간보다는 데이터가 목적지까지 도달하는 데 걸리는 시간이 더 중요하다.

반대로 5MB 메시지의 경우, 대역폭이 1Mbps일 때는 메시지 길이가 길고 대역폭이 낮으므로 전송 시간이 더 중요한 요소가 됩니다. 여기서는 전파 시간보다는 메시지를 전송하는 데 걸리는 시간이 더 중요하게 작용한다.

처리 지연(Processing Delay)
- 오류 비트 확인
- 출력 링크 결정
- 일반적으로 밀리 초 단위로 수행된다.
대기 시간(Queuing Time)
- 메시지가 중간 장치나 최종 장치에서 처리될 때까지 기다려야 하는 시간을 말한다. 이 시간은 네트워크의 부하에 따라 달라질 수 있다.
- 네트워크에 트래픽이 많을 때, 대기 시간은 증가한다. 라우터 같은 중간 장치는 도착한 메시지를 순차적으로 처리하기 때문에, 메시지가 많으면 각 메시지는 기다려야 한다.
- 라우터의 혼잡 수준에 따라 다르다.

[데이터통신] 데이터 통신에서 에러 감지하기

TIlearn — Sun, 21 Apr 2024 13:42:28 +0900

데이터 통신에서의 오류

정보를 주고받을 때 보낸 데이터가 반드시 받는 데이터와 일치한다는 보장은 없다.

어떠한 방식이 되었든, 데이터에 변조가 일어날 가능성이 있다. 데이터 통신에서는 이렇게 데이터가 변경되는 오류에도 얼마만큼 변경되냐에 따라 부르는 이름을 다르게 한다.

먼저 Single Bit Error는 데이터 중 하나의 비트만이 변경된 것을 말한다.

그리고 여기서 변조된 비트를 Corrupted Bit라고 부른다.

두 번째로 Burst Error는 이러한 Corrupted Bit가 두 개이상인 에러를 의미한다.

여기서 처음 변조가 일어난 Corrupted Bit와 마지막 Corrupted Bit까지 총 8비트를 에러가 난 부분이라고 판단한다.

Error Detection

이전에 Block Coding은 추가적인 Redundancy(여분의)를 통해 오류를 탐지하는데 도움을 준다고 했다.

이제 이 여분의 정보를 통해 어떻게 에러 감지가 가능한 지 알아볼 것이다.

오류를 감지하거나 수정하는 핵심 개념은 중복성이다. 오류를 감지하거나 수정할 수 있으려면, 우리는 데이터와 함께 몇 개의 추가 비트인 여분의 를 보내야 한다. 이러한 중복 비트는 송신자에 의해 추가되고 수신자에 의해 제거되는데, 이 비트들의 존재가 수신자의 손상된 비트를 감지하거나 수정할 수 있도록 도와주는 것이다.

블록 코딩에서는 메시지를 k비트짜리 블록으로 나누고, 이를 Dataword라고 부른다. 이때, 각 블록에 r개의 중복 비트를 추가하여 전체 길이가 n = k + r이 되게 한다.

이렇게 생성된 n비트 블록을 Codeword라고 한다.

만약 위와 같은 표로 Dataword에 대한 Codewords를 정해놓았다고 하자.

그러면, 송신자 측에서는 보내는 비트들에 대해 해당 표를 보고 여분의 비트를 추가할 것이다.

수신자 측에서는 이제 Codewords 비트들을 받게 될 것인데, 마찬가지로 위 표를 보고 해석하여 Datawords를 추출한다. 만약, 들어오는 Codewords가 표에서 존재하지 않는다면, 정보가 변조되었다는 뜻이므로 에러를 감지할 수 있다.

전혀 문제가 없어 보인다.

하지만, 만약 하나의 비트가 아니라 두 개 이상의 비트가 변조된다면 어떨까? 예를 들어, 000이 전달되는 와중에 변조가 되어 011이 되었다고 하자. 그래도 수신자 측에서 해당 Codewords는 표에 존재하는 비트이므로 에러로 판단하지 않을 것이다. 즉, 에러가 감지되어야 할 상황에 정상적인 비트라고 오판해버리고 만다.

Simple Parity Bit

문제가 발생한다는 사실은 알고 있지만, 어떤 방식으로 Codewords가 만들어지고 검사 되는지 Simple Parity Bit를 통해 알아보자.

사실 만드는 방법은 매우 간단하다. 방법도 두 가지로 나뉘는데, Datawords를 모두 더했을 때 짝수가 나오도록 Codewords를 작성한다면, 짝수 패리티 비트이고, 홀수가 나오도록 한다면 홀수 패리티비트이다.

실제로는 2와 모듈 연산을 통해 비트를 추가하도록 하는데, 의미적으로 본다면 그냥 짝수로 만들기, 홀수로 만들기에 대한 방법이다.

_Generator_는 앞서 말한 짝/홀수 패리티 비트를 만드는 도구이다.

그리고 수신자 측에서 받은 Codeword를 _Checker_가 Syndrome으로 만드는데, 이 Syndrome은 Codeword의 값을 2와 모듈 연산한 것이다.

즉, 홀수 패리티 비트를 만들었다면 1이라는 값이 Syndrome이 되고, 짝수 패리티 비트를 만들었다면 0이라는 값이 Syndrome이 될 것이다. Decision Logic은 해당 Syndrome에 저장된 값을 보고 에러가 났는지 나지 않았는지 감지한다.

※ 문제가 되는 상황

이제부터 짝수 패리티를 통해 오류 검출 하는 상황을 가정해 보자.

_1011_이라는 Dataword를 Codeword로 나타내기 위해 _10111_으로 바꾸어주었다.

1. 오류가 없는 경우

_10111_이 아무런 변조 없이 그대로 수신자에게 도착했다면 문제가 없을 것이다.

2. Dataword의 비트 중 하나가 corrupted bit가 된 경우

이 경우는 Dataword 비트 중 하나가 변조가 일어난 경우이다.

_10111_에서 _10011_과 같이 변했다고 하면, Syndrome은 1이 되므로 에러를 정상적으로 검출한다.

3. Parity 비트가 corrupted bit가 된 경우

Dataword는 정상적이지만, Parity 비트가 비정상적으로 도착했다. 송신자가 보내는 데이터 자체는 정상적인데, 추가적으로 붙은 Parity 비트 때문에 수신자 측에서는 에러가 난 것으로 감지한다.

예를 들어, _10110_으로 잘못 도착했지만, Dataword는 정상이다. 하지만, Parity 비트로 인해 해당 신호를 에러가 난 것으로 판단한다.

4. Parity 비트와 Dataword 중 하나의 비트가 corrupted bit가 된 경우

_00110_이 그와 같은 상황이 될 수 있는데, Dataword는 잘못된 값이 도착했으나, Syndrome은 0으로 나와 에러를 감지하지 못한다.

5. Dataword의 비트 중 3개가 corrupted bit인 경우

_01011_과 같은 상황으로 제대로 에러를 감지한다.

이를 통해 이 Parity Check 코드는 홀수 개의 오류만 감지 가능하다는 것을 알 수 있다.

Two-dimensional Parity-check Code

Two-dimensional Parity-check Code는 Single Parity Check Code에서 홀수 개의 오류만을 감지한다는 한계점을 개선한 오류 검출 방식이다.

짝수 개의 오류를 감지하기 위해 2차원 배열을 사용하고, 각각 패리티 비트를 추가한다.

위 그림과 같이 행과 열에 따라 각각 패리티 비트를 생성한다.

만약 하나의 비트만 에러가 난다면, 두 개의 패리티 비트에 영향을 주므로 어떻게든 오류를 감지할 수 있다.

만약 아래와 같이 두 개의 비트가 에러가 난다면, 한 행에서는 영향을 주지 않더라도 각 열에서 패리티 비트에 영향이 간다.

따라서 오류를 검출할 수 있다.

아래와 같이 구성된 경우 3가지 에러가 난다면, 4개의 패리티 비트에서 검출 가능하다.

단, 아래와 같이 같은 행과 같은 열에 2개씩 오류가 난다면, 에러를 감지할 수 없다. 따라서 이 Two-dimensional Parity Check도 완전하다고는 할 수 없다.