|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Slawa Olhovchenkov 2:5030/500 12 Jan 2006 21:29:16
To : Valentin Nechayev
Subject : А в это время в замке шефа...
--------------------------------------------------------------------------------
12 Jan 06, Valentin Nechayev writes to Slawa Olhovchenkov:
VN>>> Этого я не совсем понял. По сути есть такие часы: по каждому
VN>>> таймерному прерыванию делается обновление счётчика. Загвоздка в
VN>>> другом: можно так считать, но если можно между прерываниями получить
VN>>> более точное значение чтением текущего счётчика и пересчётом по нему
VN>>> (а это позволяют все существующие счётчики) - это делается. Для
VN>>> иллюстрации, посмотри по манам чем microuptime() отличается от
VN>>> getmicrouptime(). gettimeofday() всегда действует аналогично
VN>>> microuptime(), то есть уточняет по текущему значению; а вызов типа
VN>>> getmicrouptime(), который просто возвращает последнее известное ядру
VN>>> значение - был бы на порядок экономнее.
SO>> Достаточно часов i8254, у которых i8254_get_timecount не будет лазать
SO>> по портам.
VN> Hу так если дёрнуть getmicrouptime() или аналог, то так и будет. А
VN> какой из таймеров там - дело уже десятое, они сами аккуратно
VN> разберутся.
Hе надо плодить непонятных сущностей. У нас есть прогрмно переключаемые таймеры
-- аот их и надо развивать. Что бы автоматом всякие бенчмарки и прочая мерзость
начинали работать как надо.
VN> nanouptime() уже доступен из userland как
VN> clock_gettime(CLOCK_MONOTONIC). Теперь осталось добавить то же но
VN> без пересчёта...
Hу только несовместимойстей на уровне исходников нехватало.
VN>>>>> Кстати ты наверно видел как я наехал на HPET. Кроме этого оно ещё
VN>>>>> и
VN>>>>> гарантированно медленнее ACPI-fast...
SO>>>> Что intel, что ibm -- оба умею делать только криво или еще кривее.
VN>>> Hу IBM категория особая - они достигают высоких результатов крайне
VN>>> нестандартными путями.:)
SO>> Hе надо нам этой политкоректности. Кривыми.
VN> Дело не в политкорректности, а в иной точке зрения.;)) Я считаю, что
VN> их пути во многом ничуть не более (а часто менее) кривы чем у более
VN> известного нам мира. Hо собственная традиция слишком сильно
VN> отличается от "нашей"...
Ой, да не надо. Все у них криво, начиная с EBCDIC. Вот DEC прямо делала.
... и пpодал он Хpиста за тpидцать у.е. ...
--- GoldED+/BSD 1.1.5
* Origin: (2:5030/500)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
