Вы же сами предложили вариант “данные не поступили”. Еще можно добавить “ответ еще не получен”.
Да. И они все как раз свыше того одного, который по-вашему добавляется к двум.
А теперь обратим внимание, что такая ситуация возникает всегда, везде, на каждом этапе обработки данных до момента прихода синхро или управляющего сигнала
Если вы про X-состояние на проводах… ну ок, если вообще есть смысл его учитывать, то это ещё один вариант в дополнение к перечисленным.
И тогда обратите внимание, что, например, Verilog знает 0, 1, x,… и z! “z” это выходной “сигнал” типа “выход отключен”, и логика Verilog содержит таблицы истинности на 4 варианта каждого входа. Например, при физическом соединении выходных проводов (обозначил тут плюсом): 0+0 == 0, 0+z == 0, но 0+x == x.
Только в искусственно упрощённой интерпретации входных данных для такой статистики. Например, если стоит вопрос, на который надо ответить “да”, “нет”, или что-то третье, то это третье может быть одним из вариантов: “я сам не могу знать”; “никто не знает”; “данные не поступили” (может ещё быть различие, почему именно не поступили); наконец, “вопрос некорректен” (как классическое “Вы перестали пить коньяк по утрам?”) – и различия между ними принципиальны не меньше, чем это само да/нет.
Ну а если настаиваете – начните с рассказа, с каких источников и какими методами вы будете собирать эту статистику. Вот там и посмотрим на адекватность ваших методов.
ведь это стрим прежде всего, соответственно буферизация, и вот мы получаем ios_base, basic_streambuf, затем надо не забыть про темплейты ostream, ну и до кучи locale, ctype, форматирование и разбор num_put/num_get; опять же исключения нельзя сбрасывать со счетов, каждый раз когда мы там try…catch нам в соответствующую секцию ложится структура с адресом возврата из обработчика (и их там сотни если не тысячи) и так далее.
Буферизация и пр. – копейки, а вот хитрое форматирование и особенно локализация в основном и съедают этот объём.
Можно было бы их завязать на слабые ссылки линковки, подставляя стабы, если, например, не вызван ни один setlocale(). Но не сделали.
Я в более чем одном месте был таким Ваней, но запредельная запутанность, пожалуй, не присутствовала. Решением был отдельный договор, что я ещё несколько лет доступен для платных консультаций. Плотность вначале была существенной, потом снизилась почти до нуля, но связи не рву. Вы почему-то такой вариант не описали.
Начало 2012 – около 5$/ГБ. Была такая страничка https://jcmit.net/memoryprice.htm (сейчас на archive.org остались копии), там сводка с 1957 до середины 2024.
До 2024 произошло падение до 1.5$/ГБ. Такое снижение за 12 лет (2012÷2024) это уже кризис сам по себе, потому что раньше скорость падения относительной цены была даже больше, чем ожидалось по закону Мура. Развитие технологий типа DDR3→DDR4→DDR5 ситуацию не исправляло.
Середина 2024 – 1.5$/ГБ – возьмём за точку отсчёта кризиса. Далее: смотрим на https://pcpartpicker.com/trends/price/memory/ – уже декабрь 2024 это около 3-4$/ГБ, против 1.5$/ГБ летом 2024, когда последняя цифра у первой ссылки. 4-6$/ГБ посредине 2025. Осенью, когда начало рости и до 10$/ГБ, только тогда журналюшки и блохеры проснулись и начали свой хай.
поскольку в нём плавают номера syscall-ов от версии к версии.
и я именно про это и говорю: с номерами syscall-ов такого не происходит, они не плавают. Для конкретной платформы они постоянны, и могут только добавляться новые; старые поддерживаются. Это правило зафиксировано жёстко при его разработке, как и все прочие детали syscalls ABI (местами к сожалению – например, диверсия с автоназначением управляющего терминала, если для этого сложились условия).
Это позволяет держать в контейнерах программы, которые будут гарантированно работать независимо от дистрибутива и будущего развития ядра.
А то, о чём вы говорите, это, я предполагаю, ABI уже на уровне libc и прочих библиотек, а также системных демонов вроде systemd, nscd, syslogd и прочих. Этот вопрос в мире Linux принципиально отдан на откуп построителям дистрибутивов, и спрос должен идти именно с них.
А почему вы думаете, что на этот вопрос есть ответ? Для того же gcc таких понятий нет, зато есть 1) общий уровень оптимизации, 2) частные опции оптимизации и 3) включение отладочной информации. Может быть -O3 с отладочной информацией, а может быть -O0 без оной. Или посмотрите, например, у ядра Linux опцию сборки “readable-asm”.
то есть даже не считают нужным продемонстрировать (как-то показать) каким образом код был скомпилирован.
Или вы не понимаете, как именно они описывают режим сборки?
Уже писал: я говорю только про архитектуру Wintel/x86, точно так же, как автор исходной статьи, в его утверждении про эту частоту. Вот в ней (Wintel) эта частота используется только для RTC. Что там в настольных часах, напольных весах, в каком-нибудь контроллере на ARM, в Маке, в Амиге, PlayStation, вообще где угодно – за пределами этого. Дальше в этом же комментарии это подчёркнуто было ещё раз.
Схему по вашей ссылке я копать не буду. Чисто теоретически, конечно, интересно, зачем им такая частота – тоже RTC? Но не настолько, чтобы разбираться, как вытащить эту схему во внятное разрешение и раскопать её.
Во-первых, на подавляющем большинстве материнских плат есть до 4 кварцев:
32768Гц – как тут уже сказано.
25МГц – базовый для всех PLL для процессоров, тактирования шин, и так далее.
14.318182МГц – для старых таймеров (8254, ACPI/PIIX).
24.576МГц – для аудио, как минимум. (Смотрел по состоянию около 2015г., тогда он был почти на всех.)
Во-вторых, нет разницы между тем, что вы (только не надо КРИЧАТЬ капсом) обозначили как “резонатор” и “генератор”. В обоих случаях есть сам кварц как относительно прецизионный физический объект, и некоторая схема вокруг него, которая собственно и генерирует колебания в электрическом виде.
И нет критической разницы в обработке обоих. 25МГц напрямую (без PLL) подаётся на южный мост, где основное управление действиями типа включить-выключить всё остальное, и где есть свой небольшой и очень экономный процессор. 32768Гц подаётся на современный аналог MC146818 (RTC clock), но её функциональность давно переработана как спецификации внутрь южного моста, и та частота делится для хода часов, но не для остальной работы (как CMOS-память). Теоретически, можно и без него, дополнительный делитель из других частот это сейчас очень дёшево.
Размер Резонатора не завист от его частоты.
В-третьих, частота кварцевого генератора как раз зависит от его толщины (у большинства), обратной пропорциональностью. У некоторых видов дизайна – от длины. Всё это тривиально гуглится, вы могли легко сами найти.
Таймер 8254 – физически не пропал, угу. Но поскольку блок с ним это меньше чем копейки для современного железа, несколько тысяч вентилей (сравните с современными миллиардами на кэши), никто его и не будет удалять просто так. Особенно с учётом того, что на аналогичной легаси построено достаточно много чего. В ACPI управление типа “выключить питание” делается, по стандарту, записью заданного значения в заданный байтовый порт (причём в большинстве современных материнок эта запись перехватывается в SMM handler, который уже делает реальные действия). Значит, в принципе вообще блок работы с портами 0÷0xff должен быть, и с него нет смысла удалять тот древний таймер;) как и некоторые другие элементы.
(Ранее писал 8259 вместо 8254, глюк биологической памяти. Исправляюсь.)
Ну а легаси попытались снести всё целиком в разработке так называемого X86S. У процессора только 64-битный режим для ядра и 32 или 64 для юзерленда, нет сдохших по факту “ring 1” и “ring 2”, страничная адресация не выключается, и так далее. BIOS, соответственно, совсем другой. Но после пары лет анонсов и даже спецификаций идею почему-то отменили (декабрь 2024). Видимо, тяжесть того легаси на уровне около BIOS оказалась неподъёмной, и это меня удивляет – что именно там такого, что нельзя было перевести на современные подходы?
А вот использование 8254 в современных ОС реально свелось к нулю: Точность и цена доступа к порту старого диапазона (может быть и сотни тактов). Тут даже два аспекта: 1) Тяжёлый путь через шины. 2) Каждое обращение к пространству ввода-вывода на x86, по спеке, это полный барьер памяти. Системный вызов, и ещё сотни тактов на конкретную команду – тысячи тактов наберутся на ровном месте. А теперь сравните с такими вариантами: 1) TSC: просто вызов команды процессора. Да, надо вычесть базовое смещение, разделить на частоту процессора в данный момент и всё такое, но делается без перехода в ядро, если процессу подставлены 2-3 странички кода и данных. 2) HPET, ACPI timer: могут быть замаплены в каждый процесс в R/O режиме, с теми же последствиями, что для TSC.
Ну вот и получается, что как только ядро запустилось и нашло что-то посовременнее, оно этот 8254 просто деактивирует.
Практики – возможно (не все), но при чём тут практики, когда практически каждая тема, описанная у Кнута, кем-то позже переописана с новыми данными, подходами, алгоритмами? Например, по алгоритмам в целом и структурам данных есть Кормен, Скиена, Дасгупта. В темах появились чёрно-красные деревья, LSM tree, skiplists. По плавающей точке есть талмуды вроде Handbook of… от Мюллера с компанией. Огромная новая тема – параллельное и конкурентное программирование, вплоть до хитрых задач типа “византийских генералов”. И это только то, что из памяти за пять минут берётся. То же самое, например, с Ахо-Ульманом и “Книгой дракона”: даже издание 2008 года у них не включило PEG, на котором сейчас очень много чего делается, зато сохраняет множество рассуждений, которые имели смысл в лучшем случае для 1970-х. Прогресс тут идёт, и, отдавая свою дань старому, надо не забывать, насколько всё меняется… (да, комментарий через полгода, ну так получается)
Про поддержку железом как раз упомянуто в статье – вариант использования PTP протокола (не единственный, оно может работать и без такой поддержки, но хуже).
Синхронизация до микросекунд и точнее может быть важна много где, но одно из самых важных это HAC и HPC кластеры – причины разные, но запрос одинаковый. В некоторых кластерах прокладывают отдельную сеть сигналов в стиле PPS от GPS приёмника.
То есть, нам всё равно потребуется от сервера-поставщика точного времени передавать высокочастотный сигнал с его атомного генератора на генераторы остальных компьютеров.
Локальные генераторы никто не трогает, их только измеряют. Давно есть методы софтовой коррекции на основании измеренного расхождения темпа, надёжные и аккуратные. Искать ссылки на внутренние механизмы ядра не буду, но можете почитать ман по adjtimex() с управлением этим всем.
Только подключать его придётся несколько кустарно - одним USB не обойтись, в генератор BIOS‑часов в любом случае придётся вмешиваться.
Да, для PPS применяют, крайне желательно, отдельный порт непосредственно на материнке, обычно это нога компорта или параллельного порта (оба можно настроить на немедленное прерывание).
Вы с прямым углом перепутали;) Если залить в настройки канала в 8259 константу делителя 65536 (это максимум, что он позволял), то собственно прерывание от канала генерировалось с частотой 1193182/65536 ≈ 18.2Гц, а обратное к этому значению было 55 мс. Вот эту цифру 55 вы и вспомнили;)
Подобный режим использовался в MS-DOS по умолчанию. Но: 1) Отдельные программы могли менять этот делитель и тем самым вызывать прерывания на другой частоте, главное, что надо было вызывать основное прерывание только с прежним темпом. 2) Читать счётчик можно было независимо от прерываний и получать время с точностью чуть лучше микросекунды.
Ну а в современной ОС такой тик это слишком долго для нормального шедулинга, делают другие значения - 100Гц, 1000Гц и так далее… и считывание таймера делают современными подходами и максимально его удешевляют.
Я, было очевидно, ограничился контекстом компьютеров, причём достаточно серьёзного уровня (минимум лаптопа), согласно тому, о чём статья в целом. Разнообразные энергонезависимые (на батарейке, имеется в виду?) и нет часы – совсем другой домен. А в RTC в Wintel/x86 с этой частотой ещё сложнее: читать по каждому такому чиху или просить прерывания с такой частотой – сильно дорого. BSD системы использовали 128Гц как профилирующее таймерное прерывание, и это был максимум, что можно было себе позволить при создании этого механизма без явного ущерба для самих измерений. Сейчас, наверно, 1024 и даже 2048 вытянет любое современное железо, но 32768 – ещё нет.
Даже на IBM PC XT системные часы работали от генератора на 1.193182 MHz
Кварц там 14.318182МГц, и его можно и сейчас увидеть на большинстве материнок. Изначально он вообще из телевизора, где задавал частоту для цветовой поднесущей NTSC.
Та частота, что вы написали, и которая подавалась на 8259 – уже результат деления на 12.
1/3 от той частоты подавалась на процессор – потому 8088, 8086 вначале работали на странной 4.77МГц (округлённо). 1/4 – 3.579545МГц – на таймер ACPI/PIIX. Ну и неделённой, на половине или чуть больше материнок, на HPET.
И текущие обрабатываемые данные. Которых обычно в разы больше, чем кода.
Цельного смысла у неё нет, тут полностью согласен.
В не совсем стандартном виде он есть внутри PostScript и в фонтах TTF.
В близком к стандарту – OpenBoot. Про загрузчик FreeBSD (где он был лет 20) уже говорили.
Этого мало, конечно, но не ноль.
Да. И они все как раз свыше того одного, который по-вашему добавляется к двум.
Если вы про X-состояние на проводах… ну ок, если вообще есть смысл его учитывать, то это ещё один вариант в дополнение к перечисленным.
И тогда обратите внимание, что, например, Verilog знает 0, 1, x,… и z! “z” это выходной “сигнал” типа “выход отключен”, и логика Verilog содержит таблицы истинности на 4 варианта каждого входа. Например, при физическом соединении выходных проводов (обозначил тут плюсом): 0+0 == 0, 0+z == 0, но 0+x == x.
Только в искусственно упрощённой интерпретации входных данных для такой статистики. Например, если стоит вопрос, на который надо ответить “да”, “нет”, или что-то третье, то это третье может быть одним из вариантов: “я сам не могу знать”; “никто не знает”; “данные не поступили” (может ещё быть различие, почему именно не поступили); наконец, “вопрос некорректен” (как классическое “Вы перестали пить коньяк по утрам?”) – и различия между ними принципиальны не меньше, чем это само да/нет.
Ну а если настаиваете – начните с рассказа, с каких источников и какими методами вы будете собирать эту статистику. Вот там и посмотрим на адекватность ваших методов.
Буферизация и пр. – копейки, а вот хитрое форматирование и особенно локализация в основном и съедают этот объём.
Можно было бы их завязать на слабые ссылки линковки, подставляя стабы, если, например, не вызван ни один setlocale(). Но не сделали.
Я в более чем одном месте был таким Ваней, но запредельная запутанность, пожалуй, не присутствовала. Решением был отдельный договор, что я ещё несколько лет доступен для платных консультаций. Плотность вначале была существенной, потом снизилась почти до нуля, но связи не рву. Вы почему-то такой вариант не описали.
Нет.
Сравним:
Начало 2012 – около 5$/ГБ. Была такая страничка https://jcmit.net/memoryprice.htm (сейчас на archive.org остались копии), там сводка с 1957 до середины 2024.
До 2024 произошло падение до 1.5$/ГБ. Такое снижение за 12 лет (2012÷2024) это уже кризис сам по себе, потому что раньше скорость падения относительной цены была даже больше, чем ожидалось по закону Мура. Развитие технологий типа DDR3→DDR4→DDR5 ситуацию не исправляло.
Середина 2024 – 1.5$/ГБ – возьмём за точку отсчёта кризиса. Далее: смотрим на https://pcpartpicker.com/trends/price/memory/ – уже декабрь 2024 это около 3-4$/ГБ, против 1.5$/ГБ летом 2024, когда последняя цифра у первой ссылки. 4-6$/ГБ посредине 2025. Осенью, когда начало рости и до 10$/ГБ, только тогда журналюшки и блохеры проснулись и начали свой хай.
Вы ответили именно на
и я именно про это и говорю: с номерами syscall-ов такого не происходит, они не плавают. Для конкретной платформы они постоянны, и могут только добавляться новые; старые поддерживаются. Это правило зафиксировано жёстко при его разработке, как и все прочие детали syscalls ABI (местами к сожалению – например, диверсия с автоназначением управляющего терминала, если для этого сложились условия).
Это позволяет держать в контейнерах программы, которые будут гарантированно работать независимо от дистрибутива и будущего развития ядра.
А то, о чём вы говорите, это, я предполагаю, ABI уже на уровне libc и прочих библиотек, а также системных демонов вроде systemd, nscd, syslogd и прочих. Этот вопрос в мире Linux принципиально отдан на откуп построителям дистрибутивов, и спрос должен идти именно с них.
Нет, однажды добавленное уже остаётся навеки. Вы, наверно, с разными платформами путаете, вот тут номера между даже x86-32 и x86-64 несовместимы.
А почему вы думаете, что на этот вопрос есть ответ? Для того же gcc таких понятий нет, зато есть 1) общий уровень оптимизации, 2) частные опции оптимизации и 3) включение отладочной информации. Может быть -O3 с отладочной информацией, а может быть -O0 без оной. Или посмотрите, например, у ядра Linux опцию сборки “readable-asm”.
Или вы не понимаете, как именно они описывают режим сборки?
Уже писал: я говорю только про архитектуру Wintel/x86, точно так же, как автор исходной статьи, в его утверждении про эту частоту. Вот в ней (Wintel) эта частота используется только для RTC. Что там в настольных часах, напольных весах, в каком-нибудь контроллере на ARM, в Маке, в Амиге, PlayStation, вообще где угодно – за пределами этого. Дальше в этом же комментарии это подчёркнуто было ещё раз.
Схему по вашей ссылке я копать не буду. Чисто теоретически, конечно, интересно, зачем им такая частота – тоже RTC? Но не настолько, чтобы разбираться, как вытащить эту схему во внятное разрешение и раскопать её.
Во-первых, на подавляющем большинстве материнских плат есть до 4 кварцев:
32768Гц – как тут уже сказано.
25МГц – базовый для всех PLL для процессоров, тактирования шин, и так далее.
14.318182МГц – для старых таймеров (8254, ACPI/PIIX).
24.576МГц – для аудио, как минимум. (Смотрел по состоянию около 2015г., тогда он был почти на всех.)
Во-вторых, нет разницы между тем, что вы (только не надо КРИЧАТЬ капсом) обозначили как “резонатор” и “генератор”. В обоих случаях есть сам кварц как относительно прецизионный физический объект, и некоторая схема вокруг него, которая собственно и генерирует колебания в электрическом виде.
И нет критической разницы в обработке обоих. 25МГц напрямую (без PLL) подаётся на южный мост, где основное управление действиями типа включить-выключить всё остальное, и где есть свой небольшой и очень экономный процессор. 32768Гц подаётся на современный аналог MC146818 (RTC clock), но её функциональность давно переработана как спецификации внутрь южного моста, и та частота делится для хода часов, но не для остальной работы (как CMOS-память). Теоретически, можно и без него, дополнительный делитель из других частот это сейчас очень дёшево.
В-третьих, частота кварцевого генератора как раз зависит от его толщины (у большинства), обратной пропорциональностью. У некоторых видов дизайна – от длины. Всё это тривиально гуглится, вы могли легко сами найти.
Извините за некоторое занудство.
Таймер 8254 – физически не пропал, угу. Но поскольку блок с ним это меньше чем копейки для современного железа, несколько тысяч вентилей (сравните с современными миллиардами на кэши), никто его и не будет удалять просто так. Особенно с учётом того, что на аналогичной легаси построено достаточно много чего. В ACPI управление типа “выключить питание” делается, по стандарту, записью заданного значения в заданный байтовый порт (причём в большинстве современных материнок эта запись перехватывается в SMM handler, который уже делает реальные действия). Значит, в принципе вообще блок работы с портами 0÷0xff должен быть, и с него нет смысла удалять тот древний таймер;) как и некоторые другие элементы.
(Ранее писал 8259 вместо 8254, глюк биологической памяти. Исправляюсь.)
Ну а легаси попытались снести всё целиком в разработке так называемого X86S. У процессора только 64-битный режим для ядра и 32 или 64 для юзерленда, нет сдохших по факту “ring 1” и “ring 2”, страничная адресация не выключается, и так далее. BIOS, соответственно, совсем другой. Но после пары лет анонсов и даже спецификаций идею почему-то отменили (декабрь 2024). Видимо, тяжесть того легаси на уровне около BIOS оказалась неподъёмной, и это меня удивляет – что именно там такого, что нельзя было перевести на современные подходы?
А вот использование 8254 в современных ОС реально свелось к нулю: Точность и цена доступа к порту старого диапазона (может быть и сотни тактов). Тут даже два аспекта: 1) Тяжёлый путь через шины. 2) Каждое обращение к пространству ввода-вывода на x86, по спеке, это полный барьер памяти. Системный вызов, и ещё сотни тактов на конкретную команду – тысячи тактов наберутся на ровном месте. А теперь сравните с такими вариантами: 1) TSC: просто вызов команды процессора. Да, надо вычесть базовое смещение, разделить на частоту процессора в данный момент и всё такое, но делается без перехода в ядро, если процессу подставлены 2-3 странички кода и данных. 2) HPET, ACPI timer: могут быть замаплены в каждый процесс в R/O режиме, с теми же последствиями, что для TSC.
Ну вот и получается, что как только ядро запустилось и нашло что-то посовременнее, оно этот 8254 просто деактивирует.
text.replace(“8259”, “8254”), память заглючила.
text.replace(“8259”, “8254”), память заглючила.
Практики – возможно (не все), но при чём тут практики, когда практически каждая тема, описанная у Кнута, кем-то позже переописана с новыми данными, подходами, алгоритмами? Например, по алгоритмам в целом и структурам данных есть Кормен, Скиена, Дасгупта. В темах появились чёрно-красные деревья, LSM tree, skiplists. По плавающей точке есть талмуды вроде Handbook of… от Мюллера с компанией. Огромная новая тема – параллельное и конкурентное программирование, вплоть до хитрых задач типа “византийских генералов”. И это только то, что из памяти за пять минут берётся. То же самое, например, с Ахо-Ульманом и “Книгой дракона”: даже издание 2008 года у них не включило PEG, на котором сейчас очень много чего делается, зато сохраняет множество рассуждений, которые имели смысл в лучшем случае для 1970-х. Прогресс тут идёт, и, отдавая свою дань старому, надо не забывать, насколько всё меняется… (да, комментарий через полгода, ну так получается)
Про поддержку железом как раз упомянуто в статье – вариант использования PTP протокола (не единственный, оно может работать и без такой поддержки, но хуже).
Синхронизация до микросекунд и точнее может быть важна много где, но одно из самых важных это HAC и HPC кластеры – причины разные, но запрос одинаковый. В некоторых кластерах прокладывают отдельную сеть сигналов в стиле PPS от GPS приёмника.
Локальные генераторы никто не трогает, их только измеряют. Давно есть методы софтовой коррекции на основании измеренного расхождения темпа, надёжные и аккуратные. Искать ссылки на внутренние механизмы ядра не буду, но можете почитать ман по adjtimex() с управлением этим всем.
Да, для PPS применяют, крайне желательно, отдельный порт непосредственно на материнке, обычно это нога компорта или параллельного порта (оба можно настроить на немедленное прерывание).
Вы с прямым углом перепутали;) Если залить в настройки канала в 8259 константу делителя 65536 (это максимум, что он позволял), то собственно прерывание от канала генерировалось с частотой 1193182/65536 ≈ 18.2Гц, а обратное к этому значению было 55 мс. Вот эту цифру 55 вы и вспомнили;)
Подобный режим использовался в MS-DOS по умолчанию. Но: 1) Отдельные программы могли менять этот делитель и тем самым вызывать прерывания на другой частоте, главное, что надо было вызывать основное прерывание только с прежним темпом. 2) Читать счётчик можно было независимо от прерываний и получать время с точностью чуть лучше микросекунды.
Ну а в современной ОС такой тик это слишком долго для нормального шедулинга, делают другие значения - 100Гц, 1000Гц и так далее… и считывание таймера делают современными подходами и максимально его удешевляют.
Я, было очевидно, ограничился контекстом компьютеров, причём достаточно серьёзного уровня (минимум лаптопа), согласно тому, о чём статья в целом. Разнообразные энергонезависимые (на батарейке, имеется в виду?) и нет часы – совсем другой домен. А в RTC в Wintel/x86 с этой частотой ещё сложнее: читать по каждому такому чиху или просить прерывания с такой частотой – сильно дорого. BSD системы использовали 128Гц как профилирующее таймерное прерывание, и это был максимум, что можно было себе позволить при создании этого механизма без явного ущерба для самих измерений. Сейчас, наверно, 1024 и даже 2048 вытянет любое современное железо, но 32768 – ещё нет.
Кварц там 14.318182МГц, и его можно и сейчас увидеть на большинстве материнок. Изначально он вообще из телевизора, где задавал частоту для цветовой поднесущей NTSC.
Та частота, что вы написали, и которая подавалась на 8259 – уже результат деления на 12.
1/3 от той частоты подавалась на процессор – потому 8088, 8086 вначале работали на странной 4.77МГц (округлённо). 1/4 – 3.579545МГц – на таймер ACPI/PIIX. Ну и неделённой, на половине или чуть больше материнок, на HPET.