Real-time Processing Method for Windows OS Using MSR_FSB_FREQ Control

MSR_FSB_FREQ 제어를 이용한 윈도우 운영체제에 실시간 처리 방법

Abstract

In the case of laptops and tablet PC's that replace desktop, it uses the Windows operating system to provide various functions depending on operating system dependency, the Windows operating system does not support real-time processing because it uses multi-level feedback queue scheduling that extends round-robin scheduling. Also, since the initial value of Local APIC Counter can not be obtained from the Windows 8, the real-time processing function provided through the existing RTiK does not work. In this paper, we calculate Local APIC Counter value by using MSR_FSB_FREQ register to support real-time processing function on tablet PC's. We designed and implemented RTiK+, which provides real-time processing function to guarantee the periodicity by calculating the operation time of accurate timer. In order to verify and evaluate the performance of the implemented the RTiK+, the period was measured by using the Read Time-Stamp Counter(RDTSC) instruction and it was confirmed that it operates normally at 1ms and 0.1ms period.

1. 서론

최근 하드웨어가 발달하면서, 특수 목적을 위한 전용 장비가 아닌 일반 생활에서 사용하는 다양한 모바일 장비가 사용되며 태블릿 PC를 포함한 모바일 단말에 실시간 처리 기능이 요구되고 있으며, 이를 위한 다양한 연구가 진행되고 있다. 또한 모바일 단말의 성능 증가로 PC와 근접한 컴퓨팅 성능과 높은 휴대성을 제공한다. 이러한 목적을 위한 모바일 단말에서는 대상 기기를 위한 실시간 점검 및 명령 데이터 전송의 정확한 수행을 위해 높은 정확도의 실시간 처리 기능의 제공을 요구하고 있다[1]. 이와 같은 실시간 처리 기능으로 높은 정확도를 요구하는 무인 항공기 쳬게의 제어와 관찰, 유도무기의 기능 점검 및 의료기기 등에 적용을 위한 연구가 진행되고 있다 [2, 3, 4, 5, 6]. 대표적인 예로 군사 강국인 미국의 경우 이미 무인항공기에서 촬영한 동영상을 태블릿 PC에 실시간으로 전송하는 감지 기술을 개발하는 등 태블릿 PC를 이용하여 다양한 기술 개발 및 성능평가를 진행하고 있다.

그러나 PC를 대체하는 노트북 및 태블릿 PC의 경우 기존에 개발된 라이브러리와의 호환성과 운용 환경에서의 운영체제에 대한 종속성 및 다양한 확장 기능 제공을 위해 윈도우 운영체제를 사용하는데, 이러한 윈도우 운영체제의 경우에 프로세스 스케줄링 알고리즘의 특성인 다양한 프로세스의 균등 처리로 인해 항상 높은 우선순위를 가지기 위한 실시간 처리 기능을 제공하지 못한다는 문제점이 있다.

따라서 태블릿 PC에서 이러한 실시간 처리 기능을 제공하기 위해서는 상용 솔루션을 사용해야 한다. 현재 가장 많이 사용되고 있는 상용 솔루션으로는 Ten Asys사의 INtime과 IntervalZero사의 RTX(Rea l-Time Extension)가 있고, INtime은 이미 많은 연구가 진행되어 Windows 8에 실시간 처리가 가능하며, 64 bit용 윈도우 운영체제와 Windows 8 환경에 실시간 처리 기능을 제공하지만, 구매 비용이 고가이고 또한 경상 사용료로 인해 개발비용 및 유지보수 비용의 증가한다. 그리고 RTX를 대체하기 위해 개발된 RTiK-MP(Real-Time implanted Kernel for Multi Processor) 및 RTiK(Real-Time implanted Kernel) 은 윈도우와 독립적인 타이머를 보장하기 위해 사용한 Local APIC Timer의 초기 값을 Windows 8부터 운영체제 시작 시, 내부 보호를 위해 ‘0’으로 재설정하기 때문에 기존 방식인 Local APIC Counter값을 통해 주기 시간을 계산하는 방법을 사용할 수 없는 문제가 있다[7,8].

본 논문에서는 이와 같은 문제점을 해결하기 위해 윈도우 운영체제가 적용된 태블릿 PC에 실시간 처리 기능을 효율적으로 제공하기 위한 연구를 진행하였다. Local APIC Counter를 바탕으로 주기를 계산하는 부분을 개선하여 CPU의 동작 주파수를 결정짓는 MSR_FSB_FREQ 레지스터를 제어하고, 각 CPU마 다 다르게 동작하는 타이머 카운트 값을 결정하여, Intel 사에서 제공하는 CPU 전력 관리 기술인 C- State를 동적으로 제어하여 효과적인 전력 관리를 통해 윈도우 운영체제에 실시간 처리 기능을 제공하는 RTiK+를 설계 및 구현하였다. 구현된 RTiK을 태블릿 PC에 이식하여 1ms 주기 단위의 성능과 0.1ms의 단위 주기에 정확한 시간을 보장하는 것을 증명함으로써 실시간 처리 기능의 제공이 됨을 확인하였다. 본 논문은 2장에서는 관련 연구로써 윈도우에 실시간 처리 기능을 제공하는 RTiK-MP와 저전력 기법에 대해 기술하고, 3장에서는 Windows 8 환경의 태블릿 PC에 실시간 처리 기능을 제공하기 위한 RTiK+의 설계 및 구현에 대해 설명한다.4장에서는 실험환경 및 결과를 기술하고, 마지막 5장에서 결론 및 향후 연구에 대해 기술한다.

2. 관련 연구

현재 널리 사용 중인 서드 파티(Third Party) 운영 체제인 RTX와 INtime에 대해 기술하며, 윈도우 운영체제에 실시간 처리 기능을 제공하기 위해 개발된 RTiK-MP에 대해 기술한다.

Table 1. Third Party Operation Systems of Windows.

2.1 RTX

IntervalZero사의 RTX는 Windows 8에 고성능 실시간 제어가 가능한 실시간 운영체제의 기능을 부가해주는 확장 소프트웨어로서, 대부분의 개발자들이 사용하고 편리한 윈도우 환경에서 RTX를 이용하여 기존의 실시간 운영체제의 장점을 최대한 사용할 수 있도록 실시간성을 제공해준다. 즉, RTX는 순수 실시간 운영체제가 아니라 윈도우의 대중성과 풍부한 GUI 라이브러리의 장점을 최대한 이용하여 실시 간성 등의 제약 사항들을 보완해주는 소프트웨어이다. 현재 국방, 항공, 계측기, 시뮬레이션, 의료 및 로보틱스 등의 많은 분야에서 사용되고 있다[9].

2.2 INtime

인텔사가 개발한 iRMX커널을 사용하고 있는 인텔의 x86/CPU에 특화된 리얼타임(real-time) 시스템 소프트웨어이다. INtime은 WindowsXP/2000 및 Windows 8을 플랫폼으로 하는 제어, 계측 시스템에서 INtime소프트웨어를 추가해서 시스템상의 주요한 처리를 INtime응용프로그램에서 처리하는 것으로, 윈도우가 가진 장점을 그대로 유지하고 보다 높은 신뢰성과 정밀한 리얼타임(real-time) 성능을 보충할 수 있다. INtime은 산업용 컴퓨터(IPC)나, x86 보드 컴퓨터, 범용 PC로, Windows2000/XP/8과 협조 동작하는 실시간 운영체제이며, 동일한 하드웨어에서 윈도우와 동시에 동작하는 실시간 운영체제이다. 또한 INtime이 설치된 윈도우는 2개의 커널이 동시에 동작하는 멀티 커널 시스템이 된다. 즉, 2개의 가상 CPU를 사용하는 형태로 동작하게 된다[10].

2.3 RTiK-MP

x86 기반 멀티코어(Multi-core) 환경의 윈도우에서 실시간 처리 기능을 제공하는 RTiK-MP의 경우 Fig.1과 같이 디바이스 드라이버(device driver)형 태로 이식되어 윈도우의 커널 자원(kernel resource) 및 하드웨어 자원을 이용할 수 있다.

Fig. 1. Configuration of Multi-core based on real-time Windows operating system.

RTiK-MP는 Real-Time HAL Extension에서 x86 멀티코어 하드웨어를 접근 및 제어하고, 윈도우 커널에 RTiK-MP에서 제공하는 API를 이용하여 실시간 쓰레드(thread)를 생성하고 관리한다. 개발된 RTiK-MP의 경우 현재 유도무기체계를 위한 점검 장비(testequipment)에 이식되어 사용되고 있으며, 그 외에서 다양한 분야에서 실시간 처리 기능을 제공하기 위해 통신 미들웨어(communication middle- ware)를 개발하는 등 연구가 활발히 진행되고 있다 [11, 12, 13, 14, 15].

3. MSR_FSB_FREQ 제어를 통한 윈도우 운영체제에 실시간 처리 방법

윈도우 운영체제에 실시간 처리 기능을 제공하기 위해 개발된 기존 RTiK-MP의 경우 IntelCPU에서 제공하는 Local APIC Base Counter Register를 이용한다. 이때 Local APIC Base Counter를 이용하여 기준이 되는 시간을 계산할 수 있었으나, Windows 8 이후 Local APIC Base Counter Register의 값이 운영체제 부팅 이후 '0'로 초기화되어 시스템 클럭(clock)에 맞는 실시간 처리 기능을 제공하는데 문제점이 있다. 그리고 태블릿 PC와 같은 모바일 단말에서 전력 소모 감소를 위해 C-State Mode를 사용한다. 또한 해당 기능은 CPU의 부하(Load)에 따라 자동으로 5개의 상태 간의 변화를 통해 클럭을 조절하여 전력 소모를 감소시킨다. 그러나 해당 기능은 시스템 클럭이 동적으로 변화하여 정확한 주기 계산이 적용되지 않는 문제점이 발생한다.

이런 문제점을 해결하기 위해 본 장에서는 x86기 반의 윈도우 운영체제에 실시간 처리 기능을 제공하는 RTiK을 개선한 RTiK+를 설계하였다. 디바이스 드라이버 형태로 구현하여 하드웨어 제어를 위한 HAL (Hardware Abstract Layer)을 가짐으로써, MSR_ FSB_FREQ Register를 통해 실시간 타이머 값을 제어하고, C-State를 제어하는 역할을 수행한다. 이렇게 동작하는 HAL를 통해 정확한 주기의 타이머에서 발생하는 주기를 통하여 실시간 태스크(task) 관리를 수행한다.

Fig.2는 RTiK+가 커널 자원의 접근을 통해 윈도우와는 독립적인 타이머 인터럽트를 발생시키고, 처리하기 위한 과정을 도식으로 나타낸 그림이다. 그림에서와 같이 RTiK+는 윈도우 환경에서 실시간 처리 기능을 제공하기 위하여 로컬 APIC와 커널 자원을 이용한다.

Fig. 2. Diagram for method to provide a real-time by RTiK+.

윈도우와 독립적인 타이머 인터럽트를 구현을 위해 MSR_FSB_FREQ 레지스터의 값을 통해 AP의 로컬 APIC초기 카운트 값을 설정한다. IDT에 인터럽트 오브젝트를 등록하여 실시간 태스크 생성이 가능하도록 구현하였다. 태스크의 주기성을 보장하기 위해 위해 MSR_PKG_CST_CONFIG_CONTROL 레지스터를 수정하여 RTiK+가 동작하는 CPU의 모드를 제어하였다[16, 17, 18].

3.1 타이머 인터럽트 발생을 위한 FSB 제어 방법

FSB(Front-Side-Bus)는 CPU와 메모리 컨트롤러 허브 간의 데이터 전달을 위해 작동하며, 데이터 처리를 위해 주변 장치와 통신을 수행하는 외부 버스이다. 더불어 FSB는 Multiplier를 이용하여 CPU의 동작 속도를 결정하고, 메모리 클럭 속도와 동기화된다. Fig.3은 인텔의 x86 아키텍처의 칩셋 블록 다이어그램을 나타낸 그림이고 CPU에 제공된 클럭 발생기에서 생성된 주파수는 FSB를 통하여 로컬 APIC 타이머 레지스터의 초기 카운트 값으로 사용되어 인터럽트 발생 주기를 결정한다.

Fig. 3. Block diagram of x86 chipset interface.

모바일 환경에서도 사용 가능한 Windows 8은 MSR_FSB_FREQ 레지스터의 하위 3bits를 사용하여 현재 시스템의 CPU 종류에 맞는 FSB 동작 주파수를 구분할 수 있다. 따라서 RTiK+의 로컬 APIC타이머 발생 주기는 MSR_FSB_FREQ 레지스터의 값을 사용하여 동작 주파수를 구분하고, 이를 로컬 APIC타이머 활성하기 전에 초기 카운트 값으로 사용하여 윈도우 운영체제와는 독립적인 타이머 인터럽트를 발생시키는 것으로 작성한다. 이는 CPU에서 발생되는 로컬 APIC타이머가 FSB의 동작 주파수를 통해 제어되고 있음을 의미한다.

이러한 설정 과정 이후에 타이머 인터럽트가 발생하게 되면 IDT에 등록한 인터럽트 오브젝트에 등록된 핸들러로 분기하고, 지연처리 함수를 통해서 핸들러의 지연시간을 최소화하도록 하였다[19].

3.2 C-State 제어를 통한 시간 결정성 보장

저전력 제어를 위해 C-State 방식을 사용하여 CPU의 클럭을 조절하거나 전원제어를 통해, 전력 소비량을 감소시켜주는 동적 절전 기능을 제공한다. 이러한 CPU의 클럭은 FSB의 주파수를 기본 속도로 정하고, Multiplier 값을 CPU 동작 성능의 목적이 맞도록 제어하는 것으로 절전 기능의 동작을 수행한다. 아래의 수식 (1)은 이를 나타낸 것으로 CPU클럭이 결정되는 것을 볼 수 있다.

\(\text { CPU Clock }=\text { FSB Frequency } \times \text { Multiplier }\)       (1)

그러나 Multiplier 조절을 통해 전력 소모를 제어하는 방식은 로컬 APIC타이머 사용을 통한 시간 결정성을 보장하기 어려운 문제가 있다. Multiplier 값의 빈번한 변동은 이전에 설정된 초기 카운트 값에 설정된 최적의 주기의 값과 다르게 되어, CPU의 로컬 APIC타이머에 대한 처리속도를 변화시키고, 이는 CPU클럭 변화로 인한 타이머 인터럽트와의 시간적 오차를 발생시킬 수 있다. 또한 CPU 모드의 빈번한 변화는 Idle 상태나 Sleep 상태에서의 CPU 활성화되는 시간을 통한 지연 시간이 발생함으로 인해 시간 결정성을 보장하지 못하는 문제가 있다. 따라서 본 논문에서는 시간 결정성 보장을 위해 x86 C-State 제어가 가능하도록 하는 기능을 구성하기 위해 MSR_PKG_CST_CONFIG_CONTROL 레지스터에 접근하였다.

Fig.4는 RTiK+를 이식한 다음 HWM BlackBox 프로그램을 이용하여 C-State의 설정에 따라 변경된 CPU클럭을 나타내는 그림이다.Fig.4의 (a)는 C-State가 활성화 상태에서 CPU의 사용률에 비례하여 클럭이 동적으로 조절됨을 알 수 있고, (b)는 C-State가 비활성화 상태에서 CPU의 사용률에 무관하게 항상 최대의 클럭 값이 유지되는 것을 볼 수 있다.

Fig. 4. Frequency state of CPU clock depending on the setting of the C-State.

이를 위해 RTiK+에서 타이머 인터럽트를 제어하기 전에 MmMapIoSpace()라는 윈도우 운영체제의 커널 API를 통해 MSR_PKG_CST_CONFIG_CON TROL 레지스터에 접근하여, 하위 3Bits의 값을 C0 모드의 값인(000b)로 적용하여 CPU의 모드가 변경되는 것을 방지함으로써 RTiK+에 설정된 타이머 주기로 인한 시간 결정성 보장이 가능하도록 하였다. 또한, 윈도우 운영체제에 영향을 최소화하도록 RTiK+가 윈도우 운영체제에서 제거되거나 비활성화될 때 이전상태로 복구될 수 있도록 구현하였다.

3.3 RTiK+의 사용자 영역의 실시간 처리 기능

앞에서 기술된 바와 같이 기존 개발된 RTiK계열은 CPU의 동작 변경을 위한 다양한 레지스터 수정을 위한 커널 자원에 접근하기 위해 디바이스 드라이버 형태로 구현되어있다.

이와 같은 구조를 바탕으로 RTiK-MP는 커널 영역의 자원 접근이 쉬운 편이지만, 이를 활용하여 실시간 태스크를 이용하려는 개발자나 사용자가 커널 자원 접근을 통해 시스템의 문제가 발생할 수 있는 단점을 가지고 있다. 또한 기존 연구되었던 사용자 영역의 실시간 처리 기능은 멀티코어 환경의 이벤트 시그널 손실이 발생하여 데이터의 정확성을 해치고, 주기성을 보장하지 못할 수도 있는 문제점이 있다.

RTiK+는 이와 같은 문제를 해결하기 위해 사용자 영역에서 사용되는 쓰레드의 실시간 처리를 보장할 수 있도록 설계 및 구현되었다.

Fig.5는 RTiK+을 통해서 사용자 영역에 실시간 처리 기능을 제공하기 위한 동작 과정을 나타낸 그림이다. 사용자는 RTiK+가 제공하는 API를 통해 커널 영역으로부터 전달되는 주기적인 시그널을 받아서 실시간 성능이 보장되는 쓰레드를 생성하고, 이를 통해서 실시간 처리를 보장하도록 한다[7].

Fig. 5. Operation Process in the User area (Ring 3) of the RTiK+.

멀티코어(Multi-core) 환경을 지원하는 윈도우 운영체제의 경우, 해당 코어에서 동작하는 프로세스에게만 이벤트 발생을 알리기 때문에 타이머 인터럽트를 통해 도착하는 이벤트 시그널 손실이 발생한다. 본 논문에서는 이를 해결하기 위해 RTiK+가 이식된 코어에서만 실시간 쓰레드가 동작할 수 있게 제한하는 것으로, 이벤트 시그널의 손실을 방지하였다.

Fig.6은 데이터의 무결성 보장을 위해 RTiK+내 부에서 구현된 코드다. 실시간 쓰레드가 생성될 때, Process_Affinity() 함수를 호출하도록 하고, 해당 함수에서는 SetProcessAffinityMask() 함수를 사용하여 RTiK+가 이식된 코어만 실시간 쓰레드가 동작하도록 설계하였다. 또한 RTiK+의 실시간 쓰레드의 우선순위와 RTiK+를 통해 실시간 성능을 제공받는 프로세스의 우선순위를 가장 높은 단계로 설정하여, 실시간 성능이 요구되지 않은 기존 윈도우 쓰레드들에게 CPU를 선점(preemptive sng)당하지 ng) 당하지 않도록 한다.

Fig. 6. Function for setting the Core to run real-time thread.

Fig.7은 RTiK+의 내부에서 사용자 영역에 실시간 처리를 제공하기 위해 구현된 코드이다. 실시간 쓰레드 생성 시, 윈도우 운영체제에서 가장 높은 쓰레드 우선순위의 값 THREAD_PRIORITY_TIME _CIRITICAL을 설정해주고, REALTIME_PRIORI TY_CLASS 값을 통해서 해당 프로세스를 가장 높은 우선순위로 변경하여, 항상 최우선으로 동작할 수 있도록 구현하였다.

Fig. 7. Function for setting the Priority of real-time thread.

4.실험환경 및 결과

4.1 실험환경 및 실험 방법

RTiK+를 Windows 8 운영체제에서 정상적으로 이식하여 실시간 처리 기능 제공을 검증하기 위해 실험환경은 Fig.8과 Table2와 같이 구성하였다. 태블릿PC인 Target컴퓨터에 RTiK+를 이식하였고, 단독으로 수행될 수 있지만 정확한 성능 검증과 모니터링을 위해 USB-Serial Cable로 연결되는 모니터링 컴퓨터와의 연결을 통해 동작을 관찰하고 측정하였다.

Table 2. Configuration between the Host and the Target Computer.

Fig. 8. Environment of experimentation for proving the RTiK+ operation.

본 논문에서는 RTiK+의 성능 측정을 위해 현재 클럭틱의 수를 반환하는 CPU 명령어인 RDTSC(R ead Time-Stamp Counter)를 사용하여 실시간 태크스의 주기를 측정하였다. Fig.9는 실시간 태스크의 주기 측정을 위해 구현한 코드를 타나낸 그림이다.

Fig. 9. Test code for measuring the period of the RTiK+.

주기 측정 방법은 1ms 주기로 설정된 타이머 인터럽트를 통해 사용자 영역의 실시간 쓰레드가 호출될 때마다 클럭틱 값을 저장하고, RTiK+에서 동작하던 모든 실시간 태스크의 수행이 완료되었을 때, 저장한 클럭틱 값을 각 주기마다 계산하여, 호출된 주기를 측정하였다.

이를 검증하기 위해서 RTiK+에서 시간 결정성 만족 여부를 확인하기 위해, 앞선 주기 측정과 동일한 환경에서 C-State의 상태에 따른 주기를 측정하였다. 또한 실시간 쓰레드가 윈도우 운영체제에서 동작하는 다른 프로세스에 영향을 받지 않고 CPU를 선점할 수 있는 것을 검증하기 위해 무한으로 While 문을 수행하는 워크로드를 동시에 실행한 환경에서 실시간 쓰레드의 주기를 측정하였다.

4.2 실험 결과

4.2.1 RTiK+의 실시간성 제공 성능 측정

(1) 1ms 주기 성능 측정

Fig.10과 Fig.11은 CPU의 C-State를 비활성화 상태로 설정한 후 RTiK+의 실행 주기를 1ms 설정하여 워크로드가 없을 때와 10개의 워크로드가 동시에 실행될 때의 주기를 측정한 결과이다. RTiK+의 동작을 32, 000회 수행시킨 다음 주기를 측정하였으며, x축의 값은 RTiK+의 동작 횟수를 나타내고 y축은 태스크가 동작한 주기 값을 나타낸다.

Fig. 10. The result for period of 1ms using the RTiK+ without workloads.

Fig. 11. The result for period of 1ms using the RTiK+ with 10 workloads.

Table3은 Fig.10과 Fig.11의 태스크 주기의 측정 결과의 최소값과 최대값을 나타낸 표이다. 실시간 쓰레드는 워크로드가 없을 때 최대 약 3% 이내의 오차 범위에서 동작하는 것을 확인하였다. 또한, 10개의 워크로드가 동작하는 환경에서는 최대 약 6%의 이내의 오차 범위에서 주기적으로 동작하는 것을 볼 수 있었고, 이는 다수의 프로세스가 있는 경우에도 영향을 받지 않고 주기를 정확하게 지키는 것을 확인할 수 있었다.

Table 3. The result for 1ms of the RTiK+ with/without workloads.

(2) 0.1ms 주기 성능 측정

Fig.12와 Fig.13은 더 높은 해상도를 가지는 주기 성능을 측정한 결과이다.RTiK+의 주기를 0.1ms로 설정하고, 주기를 측정한 결과이다.Fig.12은 워크로드가 없는 시스템에 0.1ms 주기를 설정한 결과의 그래프이며, Fig.13은 동일한 환경에서 10개의 워크로드가 있는 시스템에 0.1ms 주기를 설정한 결과를 나타내는 그래프이다. x축의 값은 RTiK+의 동작 횟수를 의미하고 y축의 값은 태스크 호출 주기의 시간을 나타낸다.

Fig. 12. The result for period of 0.1ms using the RTiK+ without workloads.

Fig. 13. The result for period of 0.1ms using the RTiK+ with 10 workloads.

Table 4는 Fig.12과 Fig.13의 측정 결과의 최대값과 최소값을 나타낸 것이다. 표에서 볼 수 있듯이 실시간 쓰레드는 워크로드가 없을 경우 약 10% 이내의 오차를 가지며 주기적으로 동작하는 것을 알 수 있다. 또한 10개의 워크로드를 적용했을 경우 최대 20%의 오차가 발생한 것을 확인하였다. 따라서 보다 정밀한 주기인 0.1ms(100us)의 태스크 호출 주기에서 사용자 영역의 프로그램에서 허용 가능한 오차 범위 이내에서 태스크의 호출 주기가 지켜지는 것을 확인하였다.

Table 4. The result for 0.1ms of the RTiK+ with/without workloads.

4.2.2 RTiK+의 다중 주기 태스크 성능 측정

Fig.14는 C-State를 비활성화시킨 후 RTiK+의 다양한 주기를 갖는 태스크를 설정하여 동시에 수행한 결과이다. 실시간성이 요구되는 시스템에서는 다양한 주기를 갖는 태스크의 동작이 요구될 수 있다. 이를 만족시키기 위하여 여러 가지 주기를 가지는 태스크를 동작시켜 실험을 진행하였다. RTiK+의 주기를 3ms, 5ms, 10ms, 25ms로 설정하여 테스트를 진행하였으며, 본 논문에서는 약 30,000개의 실험 데이터를 측정하였다.x축의 값은 동작 횟수를 나타내며, y축의 값은 주기를 나타낸다.

Fig. 14. The result for period of 3ms, 5ms, 10ms and 25ms using the RTiK+.

Fig.14와 같이 동시에 서로 다른 주기를 갖는 태스크가 수행되더라도 설정한 주기 내에서 안정적으로 수행되는 것을 볼 수 있다. 이것은 다양한 주기를 갖는 태스크가 동워크로드가 없는 경우에도 설정된 주기를 크게 벗어나는 것을 확인할 수 있다. 이와 같이 C-State는 운용환경에서 사용자에게 시간 결정성을 보장하지 못함으로 실시간 성능을 제공할 수 없다는 것을 의미한다.

4.2.3 RTX와의 성능 비교

Table7은 RTX+와 이미 개발된 상용 실시간 솔루션인 RTX와의 성능을 비교하기 위해 태스크 수행 주기를 5ms, 10m 시에 실행되는 운용환경에서도 실시간성이 보장됨을 의미한다. Table5는 Fig.14에서 측정한 결과를 나타낸 표이고 각각의 경우 약 2% 이내의 오차 범위 내에서 동작함을 확인하였다.

Table 5. The results for period of 3ms, 5ms, 10ms and 25ms using the RTiK+.

Table 7. Comparison between RTiK+ and RTX.

Fig.15는 C-State를 활성화시키고 RTiK+를 사용하여 1ms 주기를 가지는 실시간 태스크의 주기를 측정한 결과를 나타낸 그래프이다. 또한 Table6은 Fig.15의 주기 측정 결과를 바탕으로 최대값과 최소값을 나타낸 표이다. 표에서와 같이 C-State를 활성화하였을 경우, s로 설정하여 RTiK와 RTiK+시험한 결과이다. 표와 같이 RTiK+와 RTX를 이용한 실시간성 제공 성능은 설정된 주기에 따라 큰 오차 없이 정상 동작하는 것을 확인할 수 있었다. 따라서 상용 솔루션인 RTiK와 동등한 성능을 나타내는 것을 확인할 수 있었다.

Fig. 15. The result of period after C-State's enable.

Table 6. The result of period after C-State enables.

5. 결론 및 향후 연구과제

본 논문에서는 범용 운영체제인 Windows 8 운영 체제에 적용된 태블릿 PC 환경에서 실시간 처리 기능을 제공하기 위해서, MSR_FSB_FREQ Register를 이용하여 Local APIC Timer 동작에 필요한 CPU Tick Value를 계산하여 윈도우 운영체제와는 독립적인 타이머 인터럽트의 동작에 대한 문제점을 개선하였다. 또한 모바일 환경의 전력 소비 문제를 해결하기 위해 C-State로 인한 주기 오차를 줄이기 위해 실시간 타이머가 동작하는 상태에서 MSR_PKG_CS T_CONFIG_CONTROL 레지스터를 통해 CPU의 동작 모드를 제어함으로써 설정된 주기로 동작할 수 있도록 RTiK+를 설계 및 구현하였다. 그리고 사용자 영역에서 데이터의 정확성과 무결성을 보장하기 위해 실시간 쓰레드를 타이머 인터럽트가 발생되는 코어에서만 동작하도록 하는 실시간 처리 기능을 제공하였다.

그리고, 성능 검증을 위해 RDTSC를 사용하여 생성된 실시간 쓰레드의 최소 주기인 1ms를 측정하였다. 워크로드가 없을 때 약 3% 이내의 오차범위에서 동작하며, 워크로드를 적용할 경우에도 약 6% 오차범위 이내에서 동작하는 것을 확인할 수 있었다. 또한 워크로드가 적용된 상황에서도 윈도우의 다른 쓰레드에게 영향을 받지 않고 CPU를 선점하여 동작하는 것을 확인했다. 또한 좀 더 정밀한 주기를 보장하기 위해 0.1ms 실험을 통해 워크로드가 없을 때, 약 10% 이내의 오차로 동작하며, 워크로드를 적용하여 약 20%의 오차로 동작하는 것을 확인하였다.이를 통해서 100us와 같은 보다 빠른 시스템에 태스크의 실시간 주기성을 보장됨을 추가적으로 확인할 수 있었다.

향후 연구로는 보다 손쉬운 사용을 위한 API구현이 필요하다. 이를 바탕으로 RTiK+의 신뢰성 검증을 위해 유도무기와 같은 무기체계에서 사용되는 점검 장비와 같은 환경에서 실시간 성능 검증이 필요하며, 그 외에도 다양한 장비에서 실시간 성능 제공을 검증할 수 있도록 하는 연구가 필요하다.