Interpretação dos resultados

Bons resultados mostram que a maioria (>90%) das chamadas de tempo individuais levam menos de um microssegundo (µs). A sobrecarga média por laço será ainda menor, abaixo de 100 nanossegundos (ns). Este exemplo de um sistema Intel i7-860 usando um temporizador TSC (Time Stamp Counter) mostra um desempenho excelente:

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

Note serem usadas unidades diferentes para o tempo por laço (ns), e no histograma (µs). O laço pode ter resolução dentro de uns poucos nanossegundos (ns), enquanto as chamadas de cronometragem individuais podem resolver apenas até um microssegundo (µs).

Medição da sobrecarga de tempo do executor

Quando o executor da consulta está executando a instrução usando EXPLAIN ANALYZE, as operações individuais são cronometradas, além de mostrar um resumo. A sobrecarga do sistema pode ser verificada contando as linhas com o programa psql:

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

O sistema i7-860 medido executa a consulta de contagem em 9,8 ms, enquanto a versão EXPLAIN ANALYZE leva 16,6 ms, cada uma processando pouco mais de 100.000 linhas. Esta diferença de 6,8 ms significa que a sobrecarga de cronometragem por linha é de 68 ns, aproximadamente o dobro do que o pg_test_timing estimou que seria. Mesmo esta quantidade relativamente pequena de sobrecarga faz com que a instrução de contagem totalmente cronometrada demore quase 70% mais. Em consultas mais pesadas, a sobrecarga de tempo seria menos problemática.

Alteração da origem do tempo

Em alguns sistemas Linux mais recentes, é possível alterar a origem do relógio usada para coletar dados de tempo a qualquer momento. Este segundo exemplo mostra a desaceleração possível ao alternar para a origem de tempo acpi_pm mais lenta, no mesmo sistema usado para os resultados rápidos acima:

# 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:
  < µs   % of total      count
     1     27.84870    1155682
     2     72.05956    2990371
     4      0.07810       3241
     8      0.01357        563
    16      0.00007          3

Nesta configuração, o exemplo EXPLAIN ANALYZE acima leva 115,9 ms. São 1061 ns de sobrecarga de tempo, novamente um pequeno múltiplo do que é medido diretamente por este utilitário. Esta sobrecarga de tempo significa que a consulta real em si está levando apenas uma pequena fração do tempo contabilizado; a maior parte do tempo está sendo consumido pela sobrecarga. Nesta configuração, quaisquer totais em EXPLAIN ANALYZE envolvendo muitas operações cronometradas seriam aumentados significativamente pela sobrecarga de contagem do tempo.

O FreeBSD também permite alterar a origem do tempo em tempo real, e registra informações sobre o cronômetro selecionado durante a inicialização:

# 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

Outros sistemas podem permitir apenas a configuração da origem do tempo na inicialização. Em sistemas Linux mais antigos, a configuração do kernel “clock” é a única maneira de fazer este tipo de alteração. E mesmo em alguns sistemas mais recentes, a única opção que se verá para uma origem de relógio é “jiffies”. Jiffies é a implementação de relógio de software do Linux mais antiga, que pode ter boa resolução quando apoiada por hardware de cronometragem rápido o suficiente, como neste exemplo:

$ 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

Hardware do relógio e precisão do tempo

A coleta de informações precisas de tempo é normalmente feita em computadores usando relógios de hardware com vários níveis de precisão. Em alguns hardwares, os sistemas operacionais podem passar o tempo do relógio do sistema quase diretamente para os programas. O relógio do sistema também pode ser derivado de um chip que simplesmente gera interrupções de tempo, e tiques periódicos em algum intervalo de tempo conhecido. Nos dois casos, os núcleos do sistema operacional fornecem uma origem de relógio que oculta estes detalhes. Mas a precisão dessa origem de relógio, e a rapidez com que pode retornar resultados, varia segundo o hardware subjacente.

A administração do tempo sem exatidão pode resultar em instabilidade do sistema. Deve-se testar qualquer alteração na origem do relógio com muito cuidado. Os padrões do sistema operacional às vezes são feitos para favorecer a confiabilidade em detrimento da melhor precisão. E se estiver sendo usada uma máquina virtual, deve-se consultar as origens de tempo recomendadas compatíveis com ela. O hardware virtual enfrenta dificuldades adicionais ao emular temporizadores, e muitas vezes há configurações por sistema operacional sugeridas pelos fornecedores.

A origem de relógio Time Stamp Counter (TSC) é a mais precisa disponível nas CPUs da geração atual. É a maneira preferida de acompanhar o tempo do sistema quando este é suportada pelo sistema operacional, e o relógio do TSC é confiável. Existem várias maneiras pelas quais o TSC pode falhar em fornecer uma origem de tempo precisa, tornando-o não confiável. Sistemas mais antigos podem ter um relógio TSC que varia segundo a temperatura da CPU, tornando-o não utilizável para medir o tempo. Tentar usar o TSC em algumas CPUs mais antigas com vários núcleos pode informar um tempo que não é consistente entre os vários núcleos. Isto pode resultar no retrocesso do tempo, um problema que este utilitário verifica. E mesmo os sistemas mais novos podem falhar em fornecer temporizações TSC precisas com configurações de economia de energia muito agressivas.

Os sistemas operacionais mais recentes podem verificar os problemas conhecidos do TSC, e alternar para uma origem de relógio mais lenta e estável quando os problemas são vistos. Se o sistema oferece suporte ao tempo TSC, mas não o usa por padrão, ele poderá estar desativado por um bom motivo. E alguns sistemas operacionais podem não detectar corretamente todos os problemas possíveis, ou permitirão o uso do TSC mesmo em situações em que sabidamente ele não é confiável.

O High Precision Event Timer (HPET) é o temporizador preferido em sistemas onde está disponível, e o TSC não é confiável. O próprio chip do temporizador é programável para permitir resolução de até 100 nanossegundos, mas pode não ser vista tanta precisão no relógio do sistema.

A Advanced Configuration and Power Interface (ACPI) fornece o Power Management (PM) Timer o qual o Linux se refere como acpi_pm. O relógio derivado do acpi_pm fornecerá, na melhor das hipóteses, uma resolução de 300 nanossegundos.

Os temporizadores usados em hardware de PC mais antigos incluem o Intel 8254 Programmable Interval Timer (PIT), o relógio de tempo real (RTC), o controlador de interrupções Advanced Programmable Interrupt Controller (APIC), e o temporizador Cyclone. Estes temporizadores visam a resolução de milissegundos.