Именно такие претензии я услышал от наших девелоперов. Самое интересное, что это оказалось правдой, дав начало длительному расследованию. Речь пойдет про SQL servers, которые крутятся у нас на VMware.
Собственно, добиться того, чтобы production server безнадежно отстал от лаптопа легко. Выполните (не на tempdb и не на базе с включенной Delayed Durability) код:
На моем десктопе он выполняется 5 секунд, а на production server — 28 секунд. Потому что SQL должен ожидать физического окончания записи в transaction log, а мы тут делаем очень короткие транзакции. Грубо говоря, мы загнали большой мощный грузовик в городской траффик, и наблюдаем, как его лихо обгоняют доставщики пиццы на скутерах — тут не важен throughput, важна лишь latency. А ни один network storage, сколько бы нулей ни было в его цене, не сможет выиграть по latency у локального SSD.
Однако в данном случае мы имеем дело стривиальными нулями зэта функции Римана с тривиальным примером. В том примере, который мне принесли девелоперы, было другое. Я убедился, что они правы, и стал вычищать из примера всю их специфику, связанную с бизнес логикой. В какой-то момент я понял, что могу полностью выбросить их код, и написать свой — который демонстрирует ту же проблему — на production он выполняется в 3-4 раза медленнее:
Если у вас все хорошо, то проверка простоты числа будет выполняться 6-7-8 секунд. Так и было на ряде серверов. Но вот на некоторых проверка занимала 25-40 секунд. Что интересно, не было серверов, где выполнение занимало бы, скажем, 14 секунд — код работал либо очень быстро, либо совсем медленно, то есть проблема была, скажем так, черно белой.
Что я сделал? Полез в метрики VMware. Там было все хорошо — реcурсов было в избытке, Ready time = 0, всего хватает, во время теста и на быстрых, и на медленных серверах CPU=100 на одном vCPU. Я взял тест по расчету числа Pi — тест показывал одинаковые результаты на любых серверах. Все сильнее пахло черной магией.
Выбравшись на DEV ферму, я стал играться серверами. Выяснилось, что vMotion с хоста на хост может «вылечить» сервер, но может и наоборот, «быстрый» сервер превратить в «медленный». Кажется вот оно — какие то хосты имеют проблему… но… нет. Какая-то виртуалка тормозила на хосте, допустим, A но работала быстро на хосте B. А другая виртуалка наоборот, работала быстро на A и тормозила на B! На хосте часто крутились и «быстрые» и «медленные» машинки!
С этого момента в воздухе отчетливо запахло серой. Ведь проблема не могла быть приписана ни виртуалке (windows patches, например) — ведь она превращалась в «быструю» при vMotion. Но проблема также не могла быть приписана хосту — ведь на нем могли быть как «быстрые», так и «медленные» машинки. Также это не было связано с нагрузкой — мне удалось получить «медленную» машинку на хосте, где кроме нее вообще не было ничего.
От отчаяния я запустил Process Explorer от Sysinternals и посмотрел стек SQL. На медленных машинках мне сразу бросилась в глаза строка:
ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 < — !!!
ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
ntoskrnl.exe!KeSynchronizeExecution+0x2de2
sqllang.dll!CDiagThreadSafe::PxlvlReplace+0x1a20
… skipped
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Это было уже что-то. Была написана программа:
Эта программа демонстрировала еще более яркое замедление — на «быстрых» машинах она показывает 16-18 миллионов циклов в секунду, тогда как на медленных — полтора миллиона, а то и 700 тысяч. То есть разница составляет 10-20 раз (!!!). Это было уже маленькой победой: во всяком случае, не было угрозы застрять между Microsoft и VMware support так, чтобы они переводили стрелки друг на друга.
Далее прогресс остановился — отпуск, важные дела, вирусная истерия и резкое возрастание нагрузки. Я часто упоминал магическую проблему коллегам, но временами казалось, что они даже не всегда мне верят — слишком уж чудовищным было заявление от том, что VMware замедляет код в 10-20 раз.
Я пытался сам раскопать, что же тормозит. Временами мне казалось, что я нашел решение — включение и выключение Hot plugs, изменение объема памяти или числа процессоров часто превращало машинку в «быструю». Но не навсегда. А вот что оказалось правдой — так это то, что достаточно выйти и постучать по колесу — то есть изменить любой параметр виртуалки
Наконец, мои американские коллеги вдруг нашли root cause.
Хосты отличались частотой!
Но есть случаи, когда эти грабли больно бьют. И таки да, постучав по колесу (поменяв что-то в настройках VM) я заставлял VMware 'пересчитать' конфигурацию, и частота текущего хоста становилась 'родной' частотой машинки.
www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
Короче говоря, надо добавить параметр
monitor_control.virtual_rdtsc = FALSE
У вас наверняка возник вопрос: а нафига SQL вызывать GetTimePrecise так часто?
У меня нет исходников SQL server, но логика говорит вот что. SQL это почти операционка с cooperative concurrency, где каждый thread должен время от времени «уступать». А где это лучше сделать? Там, где есть естественное ожидание — lock или IO. Хорошо, а что, если мы крутим вычислительные циклы? Тогда очевидное и почти единственное место — в интерпертаторе (это не совсем интерпретатор), после выполнения очередного оператора.
Как правило, SQL server не используется длязабивания гвоздей чистых вычислений и это не является проблемой. Но циклы с работой со всякими временными табличками (которые тут же кешируются) превращают код в последовательность очень быстро выполняемых операторов.
Кстати, если функцию обернуть в NATIVELY COMPILED, то она перестает запрашивать время, и ее скорость увеличивается раз в 10. А как же cooperative multitasking? А вот для natively compiled code и пришлось в SQL сделать PREEMPTIVE MULTITASKING.
Собственно, добиться того, чтобы production server безнадежно отстал от лаптопа легко. Выполните (не на tempdb и не на базе с включенной Delayed Durability) код:
set nocount on
create table _t (v varchar(100))
declare @n int=300000
while @n>0 begin
insert into _t select 'What a slowpoke!'
delete from _t
set @n=@n-1
end
GO
drop table _t
На моем десктопе он выполняется 5 секунд, а на production server — 28 секунд. Потому что SQL должен ожидать физического окончания записи в transaction log, а мы тут делаем очень короткие транзакции. Грубо говоря, мы загнали большой мощный грузовик в городской траффик, и наблюдаем, как его лихо обгоняют доставщики пиццы на скутерах — тут не важен throughput, важна лишь latency. А ни один network storage, сколько бы нулей ни было в его цене, не сможет выиграть по latency у локального SSD.
(в комментах выяснилось что я соврал — у меня в обоих местах затесался delayed durability. Без delayed durability получается:
Desktop — 39 секунд, 15K tr/sec, 0.065ms /io roundtrip
PROD — 360 секунд, 1600 tr/sec, 0.6ms
Я должен был обратить внимание, что уж слишком быстро)
Однако в данном случае мы имеем дело с
create function dbo.isPrime (@n bigint)
returns int
as
begin
if @n = 1 return 0
if @n = 2 return 1
if @n = 3 return 1
if @n % 2 = 0 return 0
declare @sq int
set @sq = sqrt(@n)+1 -- check odds up to sqrt
declare @dv int = 1
while @dv < @sq
begin
set @dv=@dv+2
if @n % @dv = 0 return 0
end
return 1
end
GO
declare @dt datetime set @dt=getdate()
select dbo.isPrime(1000000000000037)
select datediff(ms,@dt,getdate()) as ms
GO
Если у вас все хорошо, то проверка простоты числа будет выполняться 6-7-8 секунд. Так и было на ряде серверов. Но вот на некоторых проверка занимала 25-40 секунд. Что интересно, не было серверов, где выполнение занимало бы, скажем, 14 секунд — код работал либо очень быстро, либо совсем медленно, то есть проблема была, скажем так, черно белой.
Что я сделал? Полез в метрики VMware. Там было все хорошо — реcурсов было в избытке, Ready time = 0, всего хватает, во время теста и на быстрых, и на медленных серверах CPU=100 на одном vCPU. Я взял тест по расчету числа Pi — тест показывал одинаковые результаты на любых серверах. Все сильнее пахло черной магией.
Выбравшись на DEV ферму, я стал играться серверами. Выяснилось, что vMotion с хоста на хост может «вылечить» сервер, но может и наоборот, «быстрый» сервер превратить в «медленный». Кажется вот оно — какие то хосты имеют проблему… но… нет. Какая-то виртуалка тормозила на хосте, допустим, A но работала быстро на хосте B. А другая виртуалка наоборот, работала быстро на A и тормозила на B! На хосте часто крутились и «быстрые» и «медленные» машинки!
С этого момента в воздухе отчетливо запахло серой. Ведь проблема не могла быть приписана ни виртуалке (windows patches, например) — ведь она превращалась в «быструю» при vMotion. Но проблема также не могла быть приписана хосту — ведь на нем могли быть как «быстрые», так и «медленные» машинки. Также это не было связано с нагрузкой — мне удалось получить «медленную» машинку на хосте, где кроме нее вообще не было ничего.
От отчаяния я запустил Process Explorer от Sysinternals и посмотрел стек SQL. На медленных машинках мне сразу бросилась в глаза строка:
ntoskrnl.exe!KeSynchronizeExecution+0x5bf6
ntoskrnl.exe!KeWaitForMultipleObjects+0x109d
ntoskrnl.exe!KeWaitForMultipleObjects+0xb3f
ntoskrnl.exe!KeWaitForSingleObject+0x377
ntoskrnl.exe!KeQuerySystemTimePrecise+0x881 < — !!!
ntoskrnl.exe!ObDereferenceObjectDeferDelete+0x28a
ntoskrnl.exe!KeSynchronizeExecution+0x2de2
sqllang.dll!CDiagThreadSafe::PxlvlReplace+0x1a20
… skipped
sqldk.dll!SystemThread::MakeMiniSOSThread+0xa54
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21
Это было уже что-то. Была написана программа:
class Program
{
[DllImport("kernel32.dll")]
static extern void GetSystemTimePreciseAsFileTime(out FILE_TIME lpSystemTimeAsFileTime);
[StructLayout(LayoutKind.Sequential)]
struct FILE_TIME
{
public int ftTimeLow;
public int ftTimeHigh;
}
static void Main(string[] args)
{
for (int i = 0; i < 16; i++)
{
int counter = 0;
var stopwatch = Stopwatch.StartNew();
while (stopwatch.ElapsedMilliseconds < 1000)
{
GetSystemTimePreciseAsFileTime(out var fileTime);
counter++;
}
if (i > 0)
{
Console.WriteLine("{0}", counter);
}
}
}
}
Эта программа демонстрировала еще более яркое замедление — на «быстрых» машинах она показывает 16-18 миллионов циклов в секунду, тогда как на медленных — полтора миллиона, а то и 700 тысяч. То есть разница составляет 10-20 раз (!!!). Это было уже маленькой победой: во всяком случае, не было угрозы застрять между Microsoft и VMware support так, чтобы они переводили стрелки друг на друга.
Далее прогресс остановился — отпуск, важные дела, вирусная истерия и резкое возрастание нагрузки. Я часто упоминал магическую проблему коллегам, но временами казалось, что они даже не всегда мне верят — слишком уж чудовищным было заявление от том, что VMware замедляет код в 10-20 раз.
Я пытался сам раскопать, что же тормозит. Временами мне казалось, что я нашел решение — включение и выключение Hot plugs, изменение объема памяти или числа процессоров часто превращало машинку в «быструю». Но не навсегда. А вот что оказалось правдой — так это то, что достаточно выйти и постучать по колесу — то есть изменить любой параметр виртуалки
Наконец, мои американские коллеги вдруг нашли root cause.
Хосты отличались частотой!
- Как правило, это не страшно. Но: при переезде с 'родного' хоста на хост с 'другой' частотой VMware должна корректировать результат GetTimePrecise.
- Как правило это не страшно, если только не оказывается аппликации, которая запрашивает точное время миллионы раз в секунду, как SQL server.
- Но и это не страшно, так как SQL server делает это далеко не всегда (см. Заключение)
Но есть случаи, когда эти грабли больно бьют. И таки да, постучав по колесу (поменяв что-то в настройках VM) я заставлял VMware 'пересчитать' конфигурацию, и частота текущего хоста становилась 'родной' частотой машинки.
Решение
www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
When you disable virtualization of the TSC, reading the TSC from within the virtual machine returns the physical machine’s TSC value, and writing the TSC from within the virtual machine has no effect. Migrating the virtual machine to another host, resuming it from suspended state, or reverting to a snapshot causes the TSC to jump discontinuously. Some guest operating systems fail to boot, or exhibit other timekeeping problems, when TSC virtualization is disabled. In the past, this feature has sometimes been recommended to improve performance of applications that read the TSC frequently, but performance of the virtual TSC has been improved substantially in current products. The feature has also been recommended for use when performing measurements that require a precise source of real time in the virtual machine.
Короче говоря, надо добавить параметр
monitor_control.virtual_rdtsc = FALSE
Заключение
У вас наверняка возник вопрос: а нафига SQL вызывать GetTimePrecise так часто?
У меня нет исходников SQL server, но логика говорит вот что. SQL это почти операционка с cooperative concurrency, где каждый thread должен время от времени «уступать». А где это лучше сделать? Там, где есть естественное ожидание — lock или IO. Хорошо, а что, если мы крутим вычислительные циклы? Тогда очевидное и почти единственное место — в интерпертаторе (это не совсем интерпретатор), после выполнения очередного оператора.
Как правило, SQL server не используется для
Кстати, если функцию обернуть в NATIVELY COMPILED, то она перестает запрашивать время, и ее скорость увеличивается раз в 10. А как же cooperative multitasking? А вот для natively compiled code и пришлось в SQL сделать PREEMPTIVE MULTITASKING.
maxitop
Может использовать в серверах одинаковые CPU? Если не ошибаюсь VMware рекомендует что бы при организации кластера на серверах были одинаковые CPU, да и все остальное лучше одинаковое иметь.
Tzimie Автор
В идеальном мире да
Но у нас постепенно апгрейдили хосты, добавляли новые, списывали старые
MykolaPetiukh
C VMWare не знаком, но в Hyper-V для кластера нужны процы одного производителя — либо только Интелы, либо только АМД. Это не рекомендация, а требование
Tzimie Автор
Так у нас везде Intel
Но частота разная
А как Hyper-V относится к машинам с разной частотой?
DaemonGloom
Но рекомендация — использовать одинаковые есть и в Hyper-V. Даже близкие разные поколения (26xx v2 и 26xx v1) уже требуют дополнительный флаг совместимости CPU в свойствах VM, что на некоторый процент понижает производительность.
edo1h
понижает производительность или не даёт виртуальной машине использовать некоторые инструкции SIMD и т.п.?
DaemonGloom
Не даёт использовать часть аппаратно-ускоряемых функций, что приводит к использованию программной реализации их. Например — AES.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn859550(v%3Dws.11)
edo1h
ну то есть большинству приложений, не задействующих эти самые инструкции (или задействующих в гомеопатических дозах), пофиг.
DaemonGloom
Если не нужны SSE4/AVX/AVX2/AES, то пофиг. Если нужны — печаль. Что-то не запустится (если инструкции необходимы, а программной реализации при их отсутствии нет), что-то станет медленнее.
Tarakanator
А этого требования точно достаточно для решения проблемы? Не получится ли так, что одинаковые ЦП в разных условиях будут бустить по разному?
weirded
Полагаю, в требованиях есть или когда-нибудь появится пункт про отключение бустов и энергосберегающих режимов.
dmitry_dvm
Люблю такие детективы.
edo1h
так-то у нас локальные nvme используются, но ЕМНИП от СХД тоже можно получить задержки менее 1мс. если, конечно, речь не про iSCSI и не про СХД в соседнем городе.
Tzimie Автор
Да, но в самом первом примере (insert 'What a slowpoke!') делается 600K транзакций за 5 сек у меня на декстопе с локальным SSD, то есть 120K транзакций в секунду… То есть меньше 10 микросекунд на disk roundtrip…
Tzimie Автор
Опаньки, я соврал… У меня там столяло delayed durability, рукалицо.
Desktop — 39 секунд, 15K tr/sec, 0.065ms /io roundtrip
PROD — 360 секунд, 1600 tr/sec, 0.6ms
Я должен был обратить внимание, что уж слишком быстро
edo1h
всё равно быстро. обычно десктопные накопители выдают сотни iops на синхронной записи.
а что за ssd? может быть он просто их тех, что молча игнорируют fsync? )
Tzimie Автор
Вот этот стоит:
ssd.userbenchmark.com/SpeedTest/495225/KINGSTON-SA1000M8960G
KINGSTON A1000 NVMe PCIe M.2 960GB
Как проферить вашу гипотезу?
edo1h
ну я бы fio тестировал. забить рандомом файл на несколько гигабайт и запустить что-то вроде
ну и без sync=1 и сравнить результат. ещё может быть стоит
write
вместоrandwrite
, запись в лог же линейная.edo1h
а почему так медленно?
мне кажется, что с вашей СХД что-то не в порядке.
gotch
NetApp AFF220 (то есть full flash),FC-8 = 254 секунды.
edo1h
получается примерно 40мкс на операцию ввода-вывода, как-то грустно.
я думал, что СХД с FC (и агрессивным кэшированием) гораздо быстрее.
Tzimie Автор
Как я понимаю все это в основном network roundtrip.
Сам storage отдает «готово» мгновенно (write-behind, с гарантией с помощью небольшого аккумулятора)
edo1h
вот и странно, я получал RTT меньше 20мкс по обычному ethernet, FC должен быть быстрее.
Tzimie Автор
Это напрямую?
Думаю в нашем случае есть еще хопы
Ведь любой из многих хостов может работать с любым из многих стораджей…
edo1h
многие свитчи обещают задержку менее 1мкс. есть, правда, ещё задержки в трансиверах, но в любом случае задержка, вносимая физической сетью, укладывается в единицы микросекунд (если у вас не многокилометровая оптика, конечно).
тут больше вклад обработки сетевых драйверов, обработки прерываний, стека tcp/ip и всего такого. шина pci-e небезгрешна, кстати, похоже (почему pci-e optane имеет latency порядка 10мкс? те же микросхемы в виде модулей памяти горадо быстрее).
так вот, в случае подключения к схд по fc мы отказываемся от tcp/ip, драйверы (да и сами адаптеры) должны быть оптимизованы под низкие задержки — поэтому я ожидал результатов получше.
qbz
Браво, хорошее, я бы даже сказал крутое расследование! Таким и должен быть айтишник.
alexhott
Таких случаев море, докапаится до сути это почти как крутую теорему решить, но решение чаще всего только костыыл
softaria
По типу проблемы напомнило классический 500 мильный email — web.mit.edu/jemorris/humor/500-miles
Taciturn
Tzimie Автор
С работы EXE не утащить, только copy/paste.
А студии дома нет, можете через консоль скомпилировать)
Taciturn
Так у меня тоже нет, не могу скомпилировать.
Tzimie Автор
Компилятор дот нет (консольный) есть ВСЕГДА. Загуглите как скомпилить. Я просто с телефона сейчас
Taciturn
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe Program.cs (это же С#?):
Если добавить первой строчкой «using System.Runtime.InteropServices;», то на выходе:
zabr
FILE_TIME fileTime;
GetSystemTimePreciseAsFileTime(out fileTime);
zabr
out var это 4.8 дотнет.
Taciturn
Ok, заменил «GetSystemTimePreciseAsFileTime(out var fileTime);» на то, что вы предложили, в начало добавил
Заменил .Net на 4.8:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe Program.cs
Файл скомпилилровался и даже работает, начиная с Server 2012, спасибо.
vmspike
Можно в base64 конвертировать и копипастить куда хочется.
Wesha
Moral of the story: писать "if-then-else"-style на SQL — зло. Ибо заколачивание гвоздей микроскопом.
Tzimie Автор
Да. Но (в статье я это не писал) при использовании CLR, если CLR делает короткие обращения к базе, то это подвержено подобным же тормозам. Так что бизнес лочику лучше все таки выносить в отдельный слой…
Wesha
Rador
наконец-то хорошая статья
awsswa59
Мда?
Сферическому коню в вакууме пнуть по * и все заработало
Не версия vmware, не патчи что что стоят, не hw версия виртуалки, не версии tools
а к тому что волшебный параметр гугл вспоминает за 2010 год… вы думаете что это не разу не поправили?
amarao
Чисто формально, ближайший PCI-Express свитч с соответствующими nvme утрёт нос десктопу (но не vmware, которая слоупок своего рода).
Naves
Когда-то специально для виртуалок в MS SQL предлагали специально включать trace flag -T8038
techcommunity.microsoft.com/t5/sql-server-support/how-it-works-sql-server-timings-and-timer-output-gettickcount/ba-p/315782
randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted
Tzimie Автор
Спасибо, обязательно проэкспериментирую и отпишусь
Tzimie Автор
На «медленном» сервере это ускорило c 31.5s до 30.0
То есть почти без разницы…
ntkj666
нетривиальных нулей дзета-функции
somurzakov
браво, вот это интересное расследование
ddemidov
Напомнило историю с Windows 95 который как мне казалось в детстве быстрее работал если шевелить мышкой, а потом оказалось что не казалось, а так и было )
Спасибо за статью!
Wesha
"Оказалось, что не казалось" ©
А что там за история (я не про "казалось", а про технические детали), ссылочка есть?
MaximChistov
tjournal.ru/tech/105088-polzovateli-stack-exchange-rasskazali-kak-dergane-myshyu-na-samom-dele-uskoryalo-rabotu-v-windows-95
ddemidov
Да, точно. Оно.
tangro
А оно и сейчас так. Например, частота обновления страницы при отрисовки в Хроме зависит от скорости движения мышкой (ну, вернее, от самого факта наличия движения).
Wyrd
И не только в Хроме. Windows динамически повышает базовый приоритет процессов который получают активный input. Пруф: https://docs.microsoft.com/en-us/windows/win32/procthread/priority-boosts
В «обычной» обстановке вы это вряд ли заметите, но вот если в результате такой динамической приоретизации какие-то потоки станут time critical (приоритет 31), тогда вы уже можете (теоретически) увидеть разницу на глаз. Потому что time critical это не просто «высокий» приоритет, это наивысший приоритет — потокам time critical отдаётся всё процессорное время, которое есть; отправляя остальные потоки отдыхать «за свой счёт».
Посмотрите на ютубе доклады CLRium если хочется больше подробностей, там хотя и про .NET, но многое справедливо для Windows в целом.
Wyrd
Ах да, это десктопная штука, которую придумали чтоб пользователи могли ускорять инсталляторы рисуя на экране бесконечные восьмерки :)
На серверах эта магия обычно выключена. Помните настройку «отдавать приоритет фоновым процессам»? — она вот как раз про это (кроме всего прочего)
sumanai
Не станут, Windows управляет приоритетами потоков только в диапазоне 1-15. Все важные системные потоки имеют фиксированные приоритеты от 16 до 31, и никак не могут быть вытесненными пользовательскими потоками.
edo1h
у меня есть два совершенно одинаковых сервера, на одном стоит vmware, на другом нет виртуализации.
версии windows, ms sql одинаковые.
так вот, второй скрипт (арифметика) выполняется примерно одинаково (потери на виртуализацию менее 10%), первый же скрипт (много мелких транзакций) на "железной" машине выполняется за 26-27с, на виртуальной лучшее время 80с, среднее по 6 запускам — 91с.
WTF?
Tzimie Автор
а какой у вас диск на железной машине?
somurzakov
а если использовать in-memory таблицы, то баг пропадет или все еще будет?
Tzimie Автор
Если использовать natively compiled, тогда пропадет
Из обычных работа с in memory не ускорится
edo1h
intel p4500
mor_afadon_dagor
Хо-хо, неплохо.
Спасибо за статью.
Maxtremum
Мощнее? Зимой сможет обогреть квартиру?
Varim
Релиз-программа x32 bit с выключенным в BIOS HPET выдает 7.6 миллионов циклов в секунду.
Дебаг-версия x32 bit с выключенным HPET выдает 3.2 м/сек.
У меня 32 бита не зависит от вкл/выкл HPET.
Релиз x64 bit с включенным HPET выдает 17 м/сек.
Релиз x64 bit с выключенным HPET выдает 15.5 м/сек.
Tzimie Автор
7.6 немного медленновато
Интересно, неужели 32/64 bit transition так замедляет?
taurusbusy
ИМХО HPET не всегда самый «крутой» event timer.
# sysctl kern.eventtimer
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: LAPIC(600) HPET(550) HPET1(440) HPET2(440) HPET3(440) HPET4(440) HPET5(440) HPET6(440) i8254(100) RTC(0)
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.HPET6.quality: 440
kern.eventtimer.et.HPET6.frequency: 14318180
kern.eventtimer.et.HPET6.flags: 3
kern.eventtimer.et.HPET5.quality: 440
kern.eventtimer.et.HPET5.frequency: 14318180
kern.eventtimer.et.HPET5.flags: 3
kern.eventtimer.et.HPET4.quality: 440
kern.eventtimer.et.HPET4.frequency: 14318180
kern.eventtimer.et.HPET4.flags: 3
kern.eventtimer.et.HPET3.quality: 440
kern.eventtimer.et.HPET3.frequency: 14318180
kern.eventtimer.et.HPET3.flags: 3
kern.eventtimer.et.HPET2.quality: 440
kern.eventtimer.et.HPET2.frequency: 14318180
kern.eventtimer.et.HPET2.flags: 3
kern.eventtimer.et.HPET1.quality: 440
kern.eventtimer.et.HPET1.frequency: 14318180
kern.eventtimer.et.HPET1.flags: 3
kern.eventtimer.et.HPET.quality: 550
kern.eventtimer.et.HPET.frequency: 14318180
kern.eventtimer.et.HPET.flags: 7
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 2893493164
kern.eventtimer.et.LAPIC.flags: 7
Tzimie Автор
del