SUBJECT: Sun Server Configuration Planning Guide (Bench Mark)
DESCRIPTION: Appendix A. Standard Benchmarks - What they measure
오늘날 시장은 많은 Benchmarks의 결과를 인용하는데 Benchmarks란
상시적인 정확도(ever-increasing accuracy ?)로 system의 성능을 예견하는 것을 말한다.
유감스럽게도 일반에서 사용하는 Benchmarks는 모두 synthetic이다.
어떤 것들(특히 SPEC offering의 많은것)은 user application에서 유래된 코드를 포함함에도
불구하고 고객에게 적절한 기준을 전혀 제공하지 못하고 있다.
사실,측정하고자하는 성능의 한 측면 이상을 반영하기에 충분한 Benchmarks는 극히 적다
고로 이 부록에서는,몇개의 가장 일반적인 Benchmarks를 다루고 Benchmarks를 통해 측정 할 것과
측정하지 말아야 할 것이 무엇인가와 그것으로 부터 얻을 수 있는것에 대하여 몇가지를 통찰해
보고자 한다.
A.1. Dhrystone MIPS (also VUPs)
대부분의 vendors가 사용하는 "MIPS"는 Dhrystone으로 알려진 프로그램에 의해 측정된다.
Dhrystone은 1.1과 2.1 버젼이 있는데 대부분의 vendors들은 1.1의 결과를 이용한다.
Sun도마찬가지!
Dhrystone Benchmark은 작은 integer performance 측정용 synthetic code이고 이와 비교하여
whestone은 float performance측정에 좀 더 oriented 되어 있다.
Dhrystone의 결점은 synthetic code이므로 system's cashe에 완전히 들어맞는다는는 것이다.
이런 이유로 Dhrystone은 user application의 성능을 과잉 판단하게 되는데 최신의
applications은 cashe size의 수백배이이기 때문이다.
작은 cashe를 가진 system은 이때문에 이득을 얻는다.
(systems은MC88000을 기본으로 하는데 MC88000은 종종 16K 혹은 32K의 cashe를 갖고있고
이것이 제일 이익이 크다).
덧붙여 두 버젼사이의 결과와 관련하여 혼동이 있는데 2.1은 1.1의 결과보다 숫자가 항상 작다.
보고된 숫자는 코드에 의해서 얻어진 것이고 VAX-11/780에 탑재된 Ultrix의
(Ultrix compiler 를 가진)
속도로 나누어 진다. 780은 초당 100만개의 명령어를 처리하는 것으로 고려되고 reference의
평균점이므로 baseline으로 정해졌다.
780's dhrystone speed는 dhrystone 1.1에 의하여 측정된 바에 의하면 1767까지 가능하다.
DEC은 Micro VAX-II와 VUPs(VAX Unit of Performance)라 불리우는 multiples에서의
new processers의 integer 속도를 인용하는 Micro VAX-II를 기본으로 사용한다.
(시대에 뒤떨어짐)
Micro VAX-II는 보통 0.9MIPS로 accept한다.(dhrystone1.1의 경우)
설계상으로는 dhrystone test는 integer 실행속도와 C compiler의 효능을 측정한다.
이것은 전적으로 cashe에 꼭 맞으므로 단지 register-to-register의 속도를 측정하는 것이다.
A.2. Linpack MFLOPS
Linpack 측정은 일차식 100x100 solution으로 computing하면서 얻어진 초당
floating-point의 숫자를 보여준다.
Linpack은 순환적이며 변형의 다양성이 폭넓다.몇몇은 single-precision용으로 나머지는
double-precision용으로 code되어있다.
또 (주 메모리로의)비 복귀 loops와 나머지복귀 loops 버젼이 있다.
마지막으로 "coded BLAS"로 알려진 몇가지가 있다.
BLAS는 Basic Linear Algebra System의 약어로 "coded"수식은 특별한 구조/수행 결합에서의
최대활용 속도를 위해 "code되고 tune된 내부 loop에 매우 부하를 가하는 것을 의미한다.
보통 이것은 "hand-coded in assembly language"로 번역되어질 수 있다.
현재 역할은 non-coded Linpack형태로 Fortran에 대한 floating-point performance를
하는 것이다.
loop unrolled는 compiler나 processer가 unrolling loops를 사용하기에는 너무 복잡하므로
덜 중요시 되어진다. Sun에서는 loops를 복귀 시킨다.
하지만 KAI는 request되면 비 복귀 시킨다. KAI processer가 없을때 Sun은 비 복귀 loops로
DROLL compiler flag를 선별 사용한다. sun을 위해 code된 BLAS 버젼은 없으며
이는 능동적인 고객의 사용에잘 대응하지 못하는 것이다: 어떤 고객이 application에
assembly language나 SPARC에 고수준으로 사용중인 IMSL이나 NAG와 같은 시판용
math subroutine library 를 사용하는 것은 매우 어렵다.
100x100 Linpack은 80KB의 data만을 사용한다; 이는 보통 64KB cashe에 적합하다.
하지만 전형적인 Fortran coding방식은 실제론로는 더큰 array의 집합들을 실행 시켜야만
하는 필요성을 야기 시킨다
-Linpack이라면 200x200. 이는 array를 좀 더 크게 쪼개야만 하는 원인이 된다.
200x200 matrix는 320KB이고 이는 64KB cashe에는 알맞지 않아 많은 cashe misses를 불러온다.
Linpack은 floating-point 연산 unit에 부하를 가하여 많은 cashe misses를 가져와
작은 cashe(64KB 혹은 그미만)의 System에서 memory subsystem을 test하기 좋다.
1991(HP)과 1992년(Sun을 포함한 대부분)에 나오기 시작한 제품들은 Linpack이 cashe에
잘 들어맞아 cpu-ony test가 될 것이다.
(dhrystone처럼)
A.3. SPECmarks
오늘날 가장 일반적으로 사용되는 benchmark는 SPECmark이다.
SPEC 1.0 suite는 Fotran과 C codes로 구성되어 있고 이 codes는 system의 integer와
floating point수행 능력을 test하고자 하는 것이다.
codes는 하루동안 cashe와 memory subsystem에타격을 가하여 test에 충분히
효과적일 만큼 큰 크기여서 선택되었다. 보고된 숫자는열가지 tests의 geometric 평균이다.
이 열가지 tests중 넷은 integer oriented된 것이고 여섯은
floating-point oriented된 것이다. 이러한 이유로 SPEC1.0 suite는 다루고자 하는
목적에 충실하다. 주목한 만한 점은 그것의 결과가 scientic codes의
platform 성능에서 실제로 얻어지는 것에 가까운 것이다.
예외적인 floating point code로는 matrix 300이 있는데 이것은 몇가지 큰
array계산을 수행한다.
이 test의 요점은 크기가 커서 cashe에 맞지 않는 array에 matrix의 조작을 포함하고
있으므로 운영중인 memory의 floating point 계산능력을 test한다는 것이다.
유감스럽게도 matrix 300은 특별한 matrix operation에서 효과가 있는 일련의 활용에
민감히 반응하는 것으로 나타났다. Sun을 포함한 주 vendor들은 그들의 compiler에 적용하여
실행시키거나 KAI로 부터 source-level optimizer를 가진 fortan code를 processing해서
얻어진 결과를 사용한다. 덧붙여 IBM은 a joint-multiply-add instruction을
이런 종류의 실행에 알맞도록 고안된 RIOS architecturre에 추가하는데 어려움이 있었다!
( the multifly-add instruntion은 KAI preprocessor를 사용하는 것보다 다양한 class의
application에 응용할 수 있지만 상대적으로 작은 matrix manupulation class에 대해서는
특별히 주목해야 한다.)
이러한 활용의 결과는 matrix 300에서 황당한 결과를 불러온다.
- 크기가 너무 커서 열가지 결과의 gemetric 평균을 모두 왜곡한다!
SPARC-2에서 KAI preprocessor의 application은 비율을
SPECmark 21.0에서 25.0으로 혹은 전체의 19%로 올렸다.
좀 더 큰 cashe를 가진 machine들은 더 큰 영역을 "가속화"한다.
활용이 알맞다 하더라도 (code의 모든 class에 적합하게 수용되어진) user application의
대다수를 정확히 반영할 수는 없다. 목표 application이 matrix manupulation을 심하게
사용하지 않는다면 matrix 300의 결점은 모든 SPEC 결과를 조사하고 matrix 300을 제거한후
초당 geometric 평균을 다시 computing하면 극복할 수 있다.
nasa 7과 tomcatv 두 codes는 이러한 활용에 작은 영역을 제외하고는매우 민감 하다.
SPEC 2.0 suite(1992년 초 소개 예정)에는 matrix 300을 삭제 하였다.
(제안된 matrix 1000도 포함되지 않음) 고로 SPEC 2.0의 결과보고가 폭넓지는 않다.
SPEC 2.0은 SPEC1.0과 같은 비율로 (70%-floating-point oriented, 30%-integer oriented)
20가지 codes를갖고 있다.
현재의 SPECmarks는 compiler의 다중수행없이 단지 single-processor의 성능만을 측정한다.
SPEC 1.0 suite는 I/O을 가상으로 처리하지 않고 극소수의 system calls을 만들어 준다.
결과적으로 SPEC 1.0은 main processor, memory complex, C & Fortran compiler를
초벌 측정한다.
이는 1992년 하반기와 1993년 초에 SPEC 3.0이 나오면 변화를 기대해 볼만하다.
A.4. SPECthoughput
SPECthoughput 측정법은 multiprocessor processor에서 성능을 문자화하는데 사용된다.
Test는 각각의 processor에 대해 SPEC 1.0 suite의 복사본들을 실행한다;
결과의 합은 SPECthoughput
숫자로 얻어진다. SPECthoughput에서 processor는 OS나 (전체적으로 균형잡힌 system이어야 함)
여러 H/W 자원을 분할하기 때문에항상 개개의 processor SPECmark process
시간의 숫자보다 적다.
SPARCServer 600MP에서 제한된 자원들은 Mbus와 memory subsystem이므로 작은크기의 cashes는
각 processor로 합친다. SPECmarks에 의존하기 때문에 SPECthoughput은 기본적으로
같은 강약도를 가지고 있다. 물론 다수의 복사본을 실행하므로 scheduler의 효과도 test된다.
작은 memory를 가진경우 이는 memory 관리에 치명타가 될 수도 있다.
A.5. IOBench
IOBench test는 Sun 내부의 test로 다양한 회사의 disk( & virtual disk)subsystems을 비교하는
것이다. disk device에 대해 가능한한 많은 I/O운영을 실험해보고 속도와
요구되는 processor 시간의 양을 측정한다. raw와 file system 둘다 Test된다;
다양한 block size의 random & sequencial access도
측정해 볼 수있다. multi process들은 쉽게 조절된다.
I/O 용량의 대부분은 (Online을 포함하여:Disk suite) IOBench 방식을 사용한다.
IOBench는 유용성이 제한되어 있다: I/O subsystem을 test하는데 이는 매우 좋은 역할이지만
아주 미미한 것이고, 일반적으로 application사용에 반영하지 못한다.
A.6. Nhfstone
Nhfstone benchmark는 NFS 성능을 측정하기 위한 Legato System에 의해 개발되었다.
다른 benchmark program 들과는 달리 test시 System에서 실행시키지 않고 한 그룹의
client machines에서 실행하며 NFS Server에 대한 synthetic load를 산출한다.
2.0.3과 2.0.4 두 버젼은 보통 순환하여 이용한다.
2.0.4 버젼은 약간의bug가 발생하므로 2.0.3이 많이 사용된다.
(Sun의 모든 보고결과들을 포함하여)
nhfstone code는 Legato Mix라 불리우는 것으로부터 인용된 숫자를 포함한 어떤
NFS operation mix 종류와도 호환가능하다. Legato Mix는 1987년 SUNOS 3.5를 포함한
일반적인 Sun server 설치에서의 분산운영과 작은 memory를 가진 diskless clients의
부하를 표현한다. 다른 system과 직접 비교하는데 유리한 반면 Sun install에서 diskfull이
일어나고,dataless client가 제대로이며,Server의 특이한 운영을 읽는등의 현재 발생하는
일을 정확하게 읽어낼 수없다. Sun's engineering groups은
SunOS에서 실행되는 Brown mix를 포함한 다른 mixes의 dataless환경과 밀접히 관련되어 있는
다양성에 대해 연구한다.
nhfstone code는 client에서 file checking의 효과를 피하기 위해 RPC calls 을 직접
server에게 만들어 준다. 그렇지만 client-file cashing을 거부하므로 특별히 인위적으로
operation mix를 변경해 주어야 한다. 특히 reads는 종종 client에 존재하는 것을
cashe하므로 (server의 것을 cashe하는것도 가능) nhfstone는 client의 application에
의해 산출된 request 각각의 특별한 mix와 관련하여 reads의 요점을 과잉 판단하고
writes의 요지를 이하 판단하는 경향이 있다.
이는 writes를 최적화 하기가 매우 어렵기 때문에 중요한 문제이다.
client-side cashe효과를 bypass 하는 또 다른 효과는 nhfstone이 network media의
성능을 미달 평가하는 것이다.
server에게 큰 덩어리의 data를 요구하는 것과 관련하여 많은 network bandwidth는
주어진 NFS mix를 support할 것이 요청된다.
client biod의 bypassing에 관련하여 nhfstone code의 설계는 고강도의 tests를 수행해내지는
못한다. client에서의 모든 request들은 운여되고 있는 process에 대한 reference의 지역성이
simulating되지 않는것을 의미하는 균형 분배 기본원리(uniform distribution basis)에 의해
산출된다. nhfstone의 결과는 는 server가 높은 load를 갖고 있다 하더라도 실제로
server's disk의 매우 작은 위치를 점하고 있다는 것이다. test동안 실제 data는 export된
file system당 (client process가 아님) 약 2GB이다. 이것은 매우 작은 memory(16MB)를 가진
server라도 가상으로 모든 server가 virtual memory cashe를 벗어나서도 안전하게
운영을 읽어낼 수 있다는 것을 의미한다.
이는 1000NFSops 이상의 load를 simulating 하는등의 어떠한 load level의 test도
할 수 있다는 것을 말한다. server에 cashe된 모든 것을 읽고자 할때,disk는
그들의 그들의 syncronous writes를 수행하는 모든시간을 가상으로 처리한다.
물론, presto NFS같은 특별한 배열이 없이는 cashe할 수 없다.
write된 data량은 매우 작다. (test된 file system당 5MB) 결과적으로,nhfstone은
실제에 있어서는 느린 disk access와 관련하여 select time이 매우 짧으므로
server의 성능을 과잉 판단할 수 있다.(1.3GB disk에서 Cylinder는 대략 700KB이다,
고로 단지 1520Cylinder만이 사용된다:424MB라면 30Cylinder).
application이 load되었을때, writes data영역은 훨씬 더 늘어나고 결과적으로 전형적인
seek times 은 더 길어질 것이다.
마지막 결과는 nhfstone benchmark는 완벽하게 여러 subsystem을 test한다:
network protocol layer, disk write mechanisms,몇개의 scheduler등등.
다른 한편으로 default mix는 현재 network의 성능을 정확히 나타내지는 못한다;
결국 이 test는 특히 크고 high-throuth network에서는 부적당하다.
nhfstone 결과보고에서 결점은 많은 vendor들이NFS의 성능을 더욱 완벽한 도표로
제공할 수 있는 다른 정보가 더 적당하더라도 NFSops에서 얻을 수 있는
최대의 숫자를 보고한다는 것이다.
각 request와 부분적으로 성능곡선에 대한 평균 대기시간은 매우 중요하다. NFSops의 raw만큼
중요한데도 대기시간은 이상 관찰된다. 대부분의 vendor들은 nhfstone 속도를 70ms 대기
시간으로 보고한다. ( 특히 Auspex는 초기 대기곡선과 slow end of the rate-vs-latency curve
에서 많은 영역을 갖고 있기 때문에 이를 사용함.) 그러나 70ms는 매우 느리므로 이는
고객의 요구에 적절하지 않다 - 할인된 PC라도 seek times이 좀처럼 40ms이하가 되지는 않는다
대부분의 운영은 대기시간의 최고점으로 명기 되어야 한다. 대기시간 비율이 35~40ms라면
배제되어야 한다! diskless client가 있는 환경이라면 가상 memory반응이 client성능에
매우 민감하기 때문에, 아마도 25~30ms는 되어야, latency requirement는 엄격해야 한다.
성능곡선의 형태 또한 중요한데 그 이유는 조화된 system은 전 영역에 걸쳐 빠른 응답을
제공하고자 하기 때문이다.
A.7. Laddis
Laddis benchmarks는 다음과 같은 nhfstone의 결점을 알아내기 위한 것이다. codes는 nhfstone
을 수정하여 설계한 것이다. 특히 Laddis는 client system당 (file system이 아니라)15MB 가량의
큰 data를 이용한다. 이는 더욱 더 많은 reads들이 server system에 address되어져야 하고
결과적으로 disk subsystem에 부하를 주게되는 결과에서 기인한다. 그러므로 큰 memory구성을
가진 Test에서만이 access된 data의 모두를 cashe하는 것이 가능하다. Laddis test 특히
긴 seek times(Auspex같은 system은 저성능의 disk에 비하여 고가임)이나 오랜 대기시간
(disk array의 몇 가지를 실행할때)와 관련하여 disk system의 약점을 정확히 가려야 할 것이다
바람직한 대기시간의 수는 동일한 system에서 nhfstone의 수의 30-50%이다.
nhfstone와 같이 Laddis는 test의 일부분으로 정의된 뚜렷한 점검 mechanism이 없다.
큰덩이리 data는 큰 network에서 합리적인 정밀도를 보장하도록 돕는다. 이런점에서 Laddis가
적어도 하루동안 network에 대해 영향을 주기에는 너무 미약하다.
multimedia application이 폭넓게 형성되어 있고 실행중이라 하더라도 client당 NFS sets가평균
15MB가 되는 경우는 거의 없다. Laddis의 결점은 nhfstone과 거의 동일하다 주의가 요망됨.
Laddis SPEC에 통합될 것이 제의되어져 왔고 오는 1992년에 SPEC 3.0에 그렇게 될 것이다.
A.8. TP1
TP1은 transaction processing benchmark의 원조이다. 이것은 자동응답기계(Automated Teller
Machine)의 큰 network을 simulate한다. TP1 benchmark는 매우 적은 code로 이루어져 있다;
합의된 표준이 없고,저작권,법칙도 없다. 결국 TP1는 해석에 있어 innocent variation이나
의문나는 benchmarking 기법 둘다로부터 엉뚱한 변화를 가져오기 쉽다. 폭 넓은 적용의 다양성은
TP1 code에 사용되어 왔다.
TP1이 TPC-A/B와 구조적으로 매우 유사하다 하더라도 그들의 결과는 비교할 수없다! 인용된
TP1 수를 인용한 새로운 보고서는 면밀히 고려되어야 한다.
A.9. TPC-A
SPEC consortium과 유사하게 Transaction Processing Council(TPC)는 Online에 대한 정보를
제공할 수 있도록 설계된 benchmark의 다양성에 대하여 언급한다. TPC-A는 유명한 TP1 test
에서 파생된 것이다. 이것은 ATM의 큰 network 관리에서의 transaction을 simulate한다.
TPC's benchmarks와 preprocessor TP1의 가장 다른점은 실제적인 benchmark definitions
사이에 형성된 엄밀한 framework이다. 사실 공식적인 "TPC"의 결과로 고려되어질 benchmark라면
완전한 benchmark process는 TPC-approved auditor에 의해 검증되어야만 한다! 그러나
어떤 TP1은 "preliminary"나 "audit"라는 표식이 없는 results가 있는 경우도 있다.
Sun에서는 client-server computing에 있어 회사의 전략상 TPC-A의 결과를 Sysbase,Informix와
Oracle등은 1991의 하반기나 1992의 상반기에 내놓는다 하더라도 전통적으로 제공하지 않았다.
TPC-A test는 기본적으로 database management system, DBMS-operating system interface,
disk write mechanism에 부하를 주는 것이다. TPC-A는 nhfstone과 달리 예상된 요구에 대한
관찰이다. 흥미롭게도 TPC-A는 요구받은 read성능(select)없이 write성능을 test하기 위해
심하게 부하를 가해 보는 것은 nhfstone과 흡사하다.
ATM network load는 정확하게 simulate된다.
하지만 ATM은 상대적으로 많은 write와 극소량의 read를 수행한다.
이는 검색이나 sort에 의해 지배되는 online application의 대다수에 밀접한 것이다.
TPC-A와 관련된 또 다른 내용은 납득할 만한 성능을 요구하는 application을 만족하지 못한다.
TPC-A의 결과가 1991년 하반기 즈음에 초당 50-150 transaction이었는데 이는 large(real)
network에 의해 생기는 요구의 초과와는 거리가 있다: 일년의 가장 바쁜날 Bay Bank를 기준으로
한 Massachusetts의 ATM network에는 초당 평균 7 transaction이 일어나는 것으로 나타났다.
평균적으로 폭넓게 사용된 American Airlines Sabre system은 초당 1000-15000 transaction을
처리한다(최대의 경우 2650). Sabre's load는 대략 70% selects이다.
TPC-A는 DBMS의 subset, OS에서의 가상 memory관리 등 특히 large test를 말끔하게 test한다.
한 system에서 TPC-A와 TPC-B를 둘다 적용하는 vendor는 거의 없다; 하지만 둘의 결과를
모두 제공한다, TPC-A의 숫자는 TPC-B숫자의 50-55% 이다. 물론 공식적인 결과와 관련이
있지는 않지만(동시에 수행하지 않기 때문에 독립적으로 검증된!) 적당한 숫자 없이 system의
성능을 측정하기 위한 mechanism을 제공한다.
A.10. TPC-B
TPC-B는 TPC-A의 모형이다. TPC-A는 server configuration의 최대 처리량을 알아내는 것에
관심을 두는 것으로 teminal과 직접 연결되는 반면 TPC-B는 client W/S으로부터 network
connection을 사용한다. 덧붙여 wait time은 0까지 줄어든다! 결국 TPC-B는 TPC-A보다
훨씬 더 집중적인 test이다.
TPC-B는 TPC-A가 가진 결점과 같은 결점을 지니고 있다. 물론 TPC-A TPC-B사이에 반대인
경우로 TPC-A의 결과가 1.9로 계산된 것이 TPC-B 숫자에는 맞게 접근한 것 처럼 보이기도
한다.(10-15%이내에서)
A.11. TPC-C, TPC-D
TPC-C/D benchmark는 이글(1991)에서 정식으로 다루지는 않았다. TPC-C/D는 manufulating
system이나 executive information system의 online application의 다른 종류의 모델을
좀 더 정확하게 다루고자 하는 것이다.manufulating system은 executive information
system이 과중한 selects가 이루어 지는데 반해서 selects와 update가 매우 균형있게
일어난다. 이들은 TPC-A/B보다 실제적이고 유용하다. TPC-A/B와 같이 database management
system, DBMS-operating system interface,disk write mechanism을 실험한다. 적어도
executive information system은 또한 network interface에 매우 중요한 위치를 부여하고
있다. 더불어 모든 suite(A-D)들은 system 성능과 tuning에서 DBMS vendor와 OS group
vendor들에게는 차세대 주자이다.
A.12. SPEC SDM Release 1.0
SPEC System Development Multitasking(SDM)은 multiuser와 S/W개발 load를 가진 server
system의 성능을 예측하고자하는 benchmark suite이다. 다른 SPEC과 TPC benchmark와 달리
SDM은 code를 어떻게 실행시키고 어떤 결과를 어떻게 얻어 내는가에 대한 특이성을 포함
하고 있다. SDM의 현재 Release는 두개의 코드를 형성하고 있는데 SDET와 Kenbus이다.
둘다 S/W개발자들에 의해 만들어진 load를 simulate하는 많은 수의scripts를 실행한다.
Kenbus는 널리 사용되고 있는 Musbus multiuser benchmark로 부터 유래한 것이다.
둘의 결과는 "특정한 user수에 대한 시간당 scripts"라는 말로 설명 되어진다.
예를들면 160user수에 대한 시간당 1097 scripts". 많은 수의 user는 test시 system이
multiprogram의 high level에 적당한가의 문제이고 시간당 scripts의 수는 각 job에 대한
보다 빠른 처리량을 포함하는 것의 문제이다. 고로 3user가 시간당 3000 scripts의 수행을
하는 system은 120명이 시간당 3000 scripts 수행하는 것보다 훨씬 빠르게 느껴질 것이다.
주목할만한 것은 성능곡선의 형태이다. 다음의 관찰내용은 SDM 곡선 형태에 고려될 것이다.
. 이상적인 곡선은 상승국면에서는 급경사였다가 그점으로부터 완곡한 것이다;
. 완곡상승곡선은 수행이 느리거나 subsystem tuning이 시원치 않은것을 표시;
. 가벼운 부하에 곡선이 갑자기 비 선형이 될때는 tuning이 시원치 않은것을 표시;
. 최고점이 날카롭다면 memory의 문제점(paing and/or swaping)이거나 좋지않은 disk I/O;
. 마지막으로 곡선의 완만한 부분의 넓이는 overloads를 견디어 내는 system의 적응성을
나타낸다.
SDM은 OS,compiler의 속도,특히 I/O subsystem의 성능을 test한다. 특히 commands와
scripts의 대부분이 /tmp에 대해 언급한다./tmp를 잡고 있는 disk drive가 되기위한
경쟁은 병목 현상을 초래할 수 있다; /tmp의 사용을 축소하기 위하여 여러 drive에
걸쳐 stripe /tmp방식으로 MetaDisk를 사용하면 이를 방지하는데 도움이 된다.
SDM은 SPEC suite 3.0(2.0이 아니라)에 통합될 것이다.
A.13. AIM-III
AIM-III는 유일하게 source code가 독점되어 이용되는 benchmark이다. AIM-III benchmark
suite(5종류 임)는 AIM Technology Corporation의 상품이다. Vendor들은 benchmark suite를
구입하고 option으로 다양한 AIM 출판 결과를 구할 수있다.
AIM-III는 많은 S/W user에 의한 load 부하를 simulate해보려는 synthetic benchmark다.
이점에서 SPEC SDM의 Kenbus와 매우 유사하다.
Kenbus처럼 AIM-III는 multiuser들의 실행들을 simulate하는 shell scripts 묶음들을
실행시킨다. AIM-III에서 실행시키는 서로 다른 scripts가 많은데 그것들은 서로 다른
네가지 방식으로 알려져 있다. 이것들은 AIM-III성능 측정, 최대 user load, MPH (miles
per hour)와 최고 처리량 등이다. AIMs 숫자는 최고 load가 걸리는 시간에 같은 scripts
set을 VAX-11/780에서 얼마나 빨리 실행시키는가 하는 것이다. 최대 user load는 얼마나
많은 simulate된 user가 "성능의 저하없이" 처리할 수 있느나는 것이다. 바라지 않는
처리량은 각 user load마다 시간당 한개의 job보다 덜한것으로 취급된다. AIMs 숫자는
보통 최대 user load로 표시되어 지지 않는다. MPH은 system이 어떤 UNIX utility를
빨리 실행하는가의 측정이다. 그리고 같은 UNIX utility를 VAX780에서 얼마나 빨리 다중으로
실행하는가를 나타낸다. 최고 처리량 방식은 많은 simultaneous multitasking process가
운영될 수 있는가를 최고점으로 표시한 것이다.
AIM-III는 독점된 benchmark suite를 사용하는 SDM Kenbus와 같이 동종의 item을 test하기
위한 시도이다.
Revision History
작성일자 : 96.12.2
작성자 : 심민선