[Embedded] Performance Measures (1)

 제품 개발에 있어서 가장 크게 고려되는 사항중 하나가 바로 성능 측정(Performance Measure)이다. 성능 측정을 통해서 사용하고 있는 시스템의 좋고 나쁜 정도를 정량적 수치로 얻어낼 수 있다.

 보통 성능 측정이라고 하면 크게 다뤄지는 키워드가 Latency이다. Latency란 I/O 장치가 그에 맞는 동작을 할때, 아무것도 안하고 있는 시점에서 명령이 들어와 동작을 수행한 시점간의 시간 차이를 말한다. 궅이 쉬운말로 표현하면 "반응 시간"정도가 될텐데, 보통 이런 Embedded 환경에서는 하드웨어적으로 발생할 수 있는 delay(hardware delay)와 소프트웨어적으로 발생할 수 있는 delay(software delay)를 합쳐서 Latency라고 표현한다. 

 그런데 Latency라고 하는 것은 동작하는 시스템의 종류에 따라서 측정하는 시점이 다르다. 입력장치의 관점에서 보면 software delay는 입력 장치가 데이터를 받을 준비가 되서 소프트웨어가 데이터를 읽기 시작한 시점을 말하고, 출력장치 관점에서는 idle(아무것도 동작하는 상태)상태에서 소프트웨어로부터 외부로 출력할 데이터를 받을 때까지 시점을 delay라고 언급한다. 또 DAC(Digital-to-Analog Converter)를 사용할 때 Latency를 측정하라면 원래 우리가 ADC 변환이 발생할 것으로 예상된 시점과 실제 동작하기 시작하는 시점 간을 측정하면 된다. 당연히 사용자나 개발자한테는 이 Latency가 작으면 작을수록 시스템이 제 성능을 내고 있다고 평가할 수 있다. 특히 실시간 시스템(Real Time System)같은 경우에는 이 latency를 기반으로 시스템이 설계된다. Deadline이라는 개념이 있어 정해진 시간안에 시스템에서 필수적으로 수행되어야 할 동작은 무슨 일이 있더라도 항상 수행되어야 하는데, 이 때 이 deadline을 잡는 기준이 가장 긴 Latency, 다르게 말해 Worst Case Latency를 보는 것이다. 필수적으로 수행될 동작은 다 수행하면서 성능도 좋아야 되니, 이 Latency는 매우 작고, 한계가 있어야 한다. 

 Latency의 반대 개념이 Throughput, 혹은 bandwidth인데, 이건 시스템에서 처리되는 최대 데이터 전달 속도를 bit/s 또는 byte/s으로 표현한 것이다. 물론 이 throughput이 무작정 나올 수 있는게 아니다. I/O 장치에 의해서 제한이 걸릴 수도 있고, 혹은 소프트웨어에 의해서도 제한이 걸릴 수 있다. 다르게 표현하면 시스템내에 data가 이동하는 bus가 있을텐데, 이 bus의 throughput이 아무리 높다고 할지라도 실제로 data의 read/write가 이뤄지는 HDD나 Memory같은 I/O 장치의 throughput이 낮으면 우리가 얻는 throughput은 bus의 throughput이 아닌 I/O 장치의 throughput이 된다. 반대로 하드웨어의 throughput이 특정 값을 지원할지라도 System의 instruction을 처리하는 core의 speed가 어떠냐, 결국 소프트웨어의 실행 시간에 따라서 그 성능을 지원하지 못하는 경우도 발생한다.

 또 나올 수 있는 키워드가 우선 순위(Priority)가 있다. 우선순위란 현재 동작하고 있는 시스템에 대해서 두개 이상의 동작 요청이 들어올 경우, 이를 구별하기 위한 수단 정도가 된다. 이 우선순위란 개념을 시스템에 반영할 경우, 만약 낮은 순위의 동작이 수행되고 있을 때, 높은 순위의 동작이 요청될 경우 바로 우선권을 높은 순위에 맞춰 전달되어야 한다. 반대로 동등한 우선순위를 기반으로 시스템이 수행될 경우에는 한 동작이 시스템의 자원을 독점해서 쓰는 케이스가 발생하지 말아야 한다.

 우선 외부 I/O장치와 통신을 하기위해서는 두 장치간에 동기화(Synchronization)이라는 과정을 거쳐야 한다. 이런 동기화 과정은 크게 다섯 가지 유형으로 구분지을 수 있다.

 - Blind Cycle : 소프트웨어 내에 정해진 시간을 기다리는 방식
 - Polling : 장치 내의 특정 status를 나타내는 flag를 읽으면서 기다리는 방식
 - Interrupt : 하드웨어가 준비되었을 때, 소프트웨어에게 triggering 시키는 방식
 - Periodic Polling : 정해진 시점에 flag를 읽는 특정 interrupt를 주기적으로 발생시키는 방식
 - Direct Memory Access(DMA) : 하드웨어가 준비되었을때 자동으로 하드웨어가 데이터를 전송하는 방식

 Blind Cycle 방식이란 소프트웨어 내에 특정 시점을 정의해놓고 단순히 기다리는 간단한 방식이며, 사전에 I/O 동작이 정해진 시점내에 모두 끝난다는 사실을 전제로 두고 수행한다. 이 방식을 blind라고 부르는 이유는 I/O 장치가 외부의 상태에서 얻을 수 있는 정보가 없기 때문이다. 그렇기 때문에 사용자 입장에서는 특정 timing에서 해당 장치가 동작하는지 안 하는지의 여부를 알 수가 없다. 그래서 적어도 입출력 시간이 짧고, 예측가능한 케이스에 대해서만 사용된다. 이런 기법을 많이 사용하는 장치가 stepper motor이다. 해당 모터가 특정 속도를 유지하면서 회전하기 위해서는 보통 값 입력 - 대기 - 값 입력 - 대기 - .... 이런식의 과정을 거친다. 이처럼 적어도 어느 시점에 값을 입력해도 되는지 예측이 될때 많이 쓰는 기법이 되겠다.

 Polling 또는 Busy-wait 방식은 소프트웨어적으로 loop를 돌면서 장치로부터 동작 수행완료에 대한 알림을 받을 때까지 계속 대기하는 유형을 말한다. 입력장치를 놓고 봤을때, 사용자가 I/O 장치를 통해 입력을 줄 때까지 계속 대기하게 된다. 출력 장치 입장에서 보면 출력장치로 들어온 데이터가 완전히 출력되기까지 I/O 장치는 계속 수행하는 케이스가 된다. 일반적으로 이런식으로 많이 처리하는 장치가 UART(Universal Asynchronous Receiver-Transmitter) 인데, 해당 I/O의 Datasheet을 살펴보면 항상 status register가 있고, 그안에는 항상 Tx Done과 Rx Done을 표현하는 필드가 존재한다.(datasheet마다 표현이 다를 수 있는데, 내부적으로 FIFO를 통해 데이터를 처리하는 경우 FIFO Full/Empty 라는 것으로 위를 대체하기도 한다) 그런데 아마 동작원리를 보면서 이상하게 느낄 수도 있는게 사용자 입력 데이터가 없거나 출력 데이터가 없는 경우 I/O장치는 한없이 해당 알림을 받을 때까지 대기 하기 때문에 복잡한 시스템이나 Real time system에서는 사용이 조금 어렵다. 참고로 Busy라고 표현한 의미는 계속 시스템이 loop를 돌면서 해당 상태만 확인하기 때문에, 그 loop를 도는 task나 process 입장에서는 그 일만 바쁘게 처리하고 있게 되는 것이다.

 Interrupt 방식이 사실 위와 같은 Busy-wait 방식의 단점을 극복하기 위한 방안이 될 수 있다. Interrupt는 진짜 단어가 가진 뜻 그대로 하드웨어가 시스템에게 특정 동작을 요청하기 위해 중간에 급하게 알려주는 방식이다. 시스템상으로 이 알림을 받게 되면, 특수한 케이스가 아니면 반드시 해당 요청을 수행해줘야 한다. 앞에서 소개한 의미를 가져오면 다른 소프트웨어 처리보다 우선순위가 높은 것이 되겠다. 물론 이런 알림은 받은 즉시 처리할 수 있기 때문에 앞에서 언급한 Busy-wait처럼 loop를 돌면서 바쁘게 해당 알림을 볼 필요가 없어지고, 그만큼 task나 process를 활용할 수 있는 범위가 넓어진다. 다만 이렇게 Interrupt를 적용할 수 있는 갯수나 범위가 한정적이고, 해당 알림을 받았을 때, 시스템의 처리 동작도 정의를 해줘야 한다.(보통 이런 처리 과정을 ISR(Interrupt Service Routine)이라고 말한다)

 Periodic Polling과 DMA 방식에 대해서는 다른 포스트에서 소개해보고자 한다.

(edX에서 진행되는 Embedded Systems 강의에 제 생각을 덧붙였습니다.)