تفسیر نتایج

نتایج مناسب نشان می‌دهند که اکثر (>۹۰٪) فراخوانی‌های مجزای زمان‌سنجی کمتر از یک میکروثانیه طول می‌کشند. میانگین سربار در هر حلقه حتی کمتر و زیر ۱۰۰ نانوثانیه خواهد بود. این مثال از یک سیستم Intel i7-860 با استفاده از منبع ساعت TSC، کارایی فوق‌العاده‌ای را نشان می‌دهد:

Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 ns
Histogram of timing durations:
  < us   % of total      count
     1     96.40465   80435604
     2      3.59518    2999652
     4      0.00015        126
     8      0.00002         13
    16      0.00000          2

توجه داشته باشید که واحدهای متفاوتی برای زمان هر حلقه نسبت به هیستوگرام استفاده می‌شود. حلقه می‌تواند تفکیک‌پذیری در حد چند نانوثانیه (ns) داشته باشد، در حالی که فراخوانی‌های زمان‌سنجی مجزا تنها تا یک میکروثانیه (us) تفکیک‌پذیر هستند.

سنجش سربار زمان‌سنجی مجری

هنگامی که مجری پرس‌وجو دستوری را با استفاده از EXPLAIN ANALYZE اجرا می‌کند، علاوه بر نمایش خلاصه، زمان عملیات مجزا نیز سنجیده می‌شود. سربار سیستم شما را می‌توان با شمارش ردیف‌ها توسط برنامهٔ psql بررسی کرد:

CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
\timing
SELECT COUNT(*) FROM t;
EXPLAIN ANALYZE SELECT COUNT(*) FROM t;

سیستم مورد سنجش i7-860 پرس‌وجوی شمارش را در ۹.۸ میلی‌ثانیه اجرا می‌کند، در حالی که نسخهٔ دارای EXPLAIN ANALYZE ۱۶.۶ میلی‌ثانیه زمان می‌برد که هر کدام کمی بیش از ۱۰۰,۰۰۰ ردیف را پردازش می‌کنند. این اختلاف ۶.۸ میلی‌ثانیه‌ای به این معنی است که سربار زمان‌سنجی برای هر ردیف ۶۸ نانوثانیه است، یعنی تقریباً دو برابر چیزی که pg_test_timing تخمین زده بود. حتی این مقدار نسبتاً کم از سربار باعث می‌شود که دستور شمارش کاملاً زمان‌سنجی‌شده تقریباً ۷۰٪ بیشتر طول بکشد. در پرس‌وجوهای سنگین‌تر، این سربار زمان‌سنجی کمتر مشکل‌ساز خواهد بود.

تغییر منابع ساعت

در برخی سیستم‌های جدیدتر لینوکس، تغییر منبع ساعت مورد استفاده برای جمع‌آوری داده‌های زمان‌سنجی در هر لحظه امکان‌پذیر است. مثال دوم، افت سرعت احتمالی ناشی از جابجایی به منبع ساعت کندتر acpi_pm را در همان سیستم مورد استفاده در نتایج سریع بالا نشان می‌دهد:

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Per loop time including overhead: 722.92 ns
Histogram of timing durations:
  < us   % of total      count
     1     27.84870    1155682
     2     72.05956    2990371
     4      0.07810       3241
     8      0.01357        563
    16      0.00007          3

در این پیکربندی، نمونهٔ EXPLAIN ANALYZE بالا ۱۱۵.۹ میلی‌ثانیه طول می‌کشد. این یعنی ۱۰۶۱ نانوثانیه سربار زمان‌سنجی، که باز هم چند برابر مقداری است که مستقیماً توسط این ابزار اندازه‌گیری شده است. این مقدار سربار زمان‌سنجی نشان می‌دهد که خود پرس‌وجوی واقعی تنها بخش ناچیزی از کل زمان محاسبه‌شده را مصرف می‌کند و بخش اعظم آن صرف سربار می‌شود. در این پیکربندی، مجموع مقادیر EXPLAIN ANALYZE که شامل عملیات زمان‌سنجی‌شدهٔ متعدد باشند، به دلیل سربار زمان‌سنجی به میزان چشمگیری افزایش کاذب خواهند داشت.

سیستم‌عامل FreeBSD نیز امکان تغییر در لحظهٔ منبع ساعت را فراهم می‌کند، و اطلاعات مربوط به تایمر انتخاب‌شده در زمان بوت را ثبت می‌کند:

# dmesg | grep "Timecounter"
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "TSC" frequency 2531787134 Hz quality 800
# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-fast -> TSC

سایر سیستم‌ها ممکن است تنها در زمان بوت اجازهٔ تنظیم منبع ساعت را بدهند. در سیستم‌های لینوکسی قدیمی‌تر، تنظیم کرنل "clock" تنها راه اعمال چنین تغییری است. و حتی در برخی از نسخه‌های جدیدتر، تنها گزینه‌ای که برای منبع ساعت مشاهده خواهید کرد "jiffies" است. جِیفی‌ها پیاده‌سازی قدیمی‌تر ساعت نرم‌افزاری در لینوکس هستند، که در صورت پشتیبانی توسط سخت‌افزار زمان‌سنجی به قدر کافی سریع، می‌توانند تفکیک‌پذیری خوبی داشته باشند، مانند این مثال:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
$ dmesg | grep time.c
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.153 MHz processor.
$ pg_test_timing
Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 97.75 ns
Histogram of timing durations:
  < us   % of total      count
     1     90.23734   27694571
     2      9.75277    2993204
     4      0.00981       3010
     8      0.00007         22
    16      0.00000          1
    32      0.00000          1

سخت‌افزار ساعت و دقت زمان‌سنجی

جمع‌آوری اطلاعات دقیق زمان‌سنجی بر روی رایانه‌ها معمولاً با استفاده از ساعت‌های سخت‌افزاری با سطوح مختلف دقت انجام می‌شود. در برخی سخت‌افزارها، سیستم‌عامل‌ها می‌توانند زمان ساعت سیستم را تقریباً به طور مستقیم به برنامه‌ها منتقل کنند. همچنین ساعت سیستم می‌تواند از تراشه‌ای مشتق شود که به سادگی وقفه‌های زمانی (تیک‌های دوره‌ای در فواصل زمانی مشخص) را فراهم می‌کند. در هر دو حالت، هسته‌های سیستم‌عامل یک منبع ساعت (clock source) فراهم می‌کنند که این جزئیات را پنهان می‌سازد. اما دقت آن منبع ساعت و سرعت بازگرداندن نتایج بر اساس سخت‌افزار زیرین متفاوت است.

نگه‌داری نادرست زمان می‌تواند منجر به ناپایداری سیستم شود. هر تغییری در منبع ساعت را با دقت بسیار بیازمایید. پیش‌فرض‌های سیستم‌عامل گاهی اوقات به گونه‌ای تنظیم شده‌اند که پایداری و قابلیت اطمینان را بر بیشترین دقت ترجیح دهند. و اگر از یک ماشین مجازی استفاده می‌کنید، منابع ساعت توصیه‌شده و سازگار با آن را بررسی کنید. سخت‌افزارهای مجازی هنگام شبیه‌سازی تایمرها با دشواری‌های بیشتری روبرو هستند، و معمولاً تنظیماتی به ازای هر سیستم‌عامل توسط ارائه‌دهندگان پیشنهاد می‌شود.

منبع ساعت شمارندهٔ برچسب زمان یا Time Stamp Counter (TSC) دقیق‌ترین منبع ساعت در پردازنده‌های نسل کنونی است. این منبع، روش ارجح برای رهگیری زمان سیستم در صورت پشتیبانی سیستم‌عامل و قابل اعتماد بودن ساعت TSC است. چندین دلیل وجود دارد که ممکن است مانع از ارائه یک منبع زمان‌سنجی دقیق توسط TSC شده و آن را غیرقابل اعتماد کند. سیستم‌های قدیمی‌تر ممکن است دارای ساعت TSC باشند که با دمای پردازنده تغییر می‌کند، که آن را برای زمان‌سنجی غیرقابل استفاده می‌سازد. تلاش برای استفاده از TSC بر روی برخی پردازنده‌های چندهسته‌ای قدیمی‌تر ممکن است زمانی ناهمخوان در بین هسته‌های متعدد گزارش کند. این وضعیت می‌تواند باعث عقب رفتن زمان شود، مشکلی که این برنامه آن را بررسی می‌کند. و حتی جدیدترین سیستم‌ها با تنظیمات مدیریت مصرف توان بسیار تهاجمی ممکن است در ارائه زمان‌سنجی دقیق TSC ناموفق باشند.

سیستم‌عامل‌های جدیدتر ممکن است مشکلات شناخته‌شدهٔ TSC را بررسی کرده و در صورت مشاهدهٔ آن‌ها، به یک منبع ساعت کندتر و پایدارتر تغییر وضعیت دهند. اگر سیستم شما از زمان TSC پشتیبانی می‌کند اما آن را به عنوان پیش‌فرض قرار نداده است، ممکن است به دلایل موجهی غیرفعال شده باشد. همچنین برخی از سیستم‌عامل‌ها ممکن است همهٔ مشکلات احتمالی را به درستی تشخیص ندهند یا حتی در شرایطی که عدم دقت TSC محرز است، اجازهٔ استفاده از آن را بدهند.

تایمر رویداد با دقت بالا یا High Precision Event Timer (HPET) در سیستم‌هایی که در دسترس است و TSC در آن‌ها دقیق نیست، تایمر ارجح محسوب می‌شود. خود تراشهٔ تایمر قابل برنامه‌ریزی است تا تفکیک‌پذیری تا ۱۰۰ نانوثانیه را ارائه دهد، اما ممکن است این میزان دقت را در ساعت سیستم خود مشاهده نکنید.

رابط پیشرفتهٔ پیکربندی و مدیریت توان (ACPI) یک تایمر مدیریت توان (PM) ارائه می‌دهد که لینوکس از آن با عنوان acpi_pm یاد می‌کند. ساعت مشتق‌شده از acpi_pm در بهترین حالت تفکیک‌پذیری ۳۰۰ نانوثانیه‌ای را ارائه می‌دهد.

تایمرهای مورد استفاده در سخت‌افزارهای رایانه شخصی (PC) قدیمی‌تر عبارتند از: تایمر فاصله‌ای قابل برنامه‌ریزی ۸۲۵۴ (PIT)، ساعت زمان‌واقعی (RTC)، تایمر کنترلر وقفهٔ پیشرفتهٔ قابل برنامه‌ریزی (APIC)، و تایمر Cyclone. هدف این تایمرها دقت تفکیک در حد میلی‌ثانیه است.