Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"	+/–
Сообщение от opennews (??), 13-Фев-25, 18:50
Инженер из компании Google предложил повысить частоту генерации прерываний от таймера  в ядре Linux до 1000Hz по умолчанию, что приведёт к увеличению частоты переключения задач и уменьшению кванта времени в планировщике задач. В данный момент по умолчанию используется 250Hz, как некий компромисс между производительностью, задержками и энергопотреблением... Подробнее: https://www.opennet.me/opennews/art.shtml?num=62713
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 13-Фев-25, 18:50	+3 +/–
А что, дистрибутивы уже собирают ядра с defconfig?
Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от opennetuser (ok), 13-Фев-25, 18:51	+22 +/–
Закончится тем, что 1000 это много, а 500 в самый раз. :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #19, #21, #101, #174

3. Сообщение от Аноним (3), 13-Фев-25, 18:51	–16 +/–
Теперь понятно почему люди с высокими герцами у моника топили за то, что оно не хуже и даже лучше обычных 60. Оно работало на тех же 60.)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #16

4. Сообщение от Аноним (4), 13-Фев-25, 18:52	+11 +/–
Что бы инженеры из Гугла делали без этого чувака с Фороникса.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

5. Сообщение от Ося Бендер (?), 13-Фев-25, 18:54	+/–
Вот так переставив кроватки, достигаем увеличения потока клиентов. Ловко!
Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от Совершенно другой аноним (?), 13-Фев-25, 19:02	–2 +/–
Странно, что никто не сказал, что увеличение частоты повысит накладные расходы, т.к. прерывание предполагает переход из режима пользователя в режим ядра, сохранение регистров, вызов обработчика прерывания, восстановление регистров, а затем возвращение в режим пользователя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #18

8. Сообщение от Аноним (8), 13-Фев-25, 19:04	+2 +/–
> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14, #102

9. Сообщение от Шарп (ok), 13-Фев-25, 19:06	+2 +/–
Предлагаю компромисс: динамическое изменение частоты таймера в зависимости от нагрузки и всего такого.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

10. Сообщение от Шарп (ok), 13-Фев-25, 19:08	+8 +/–
Там написано про джиттер. Ты не понял и полез комментировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

11. Сообщение от Аноним (11), 13-Фев-25, 19:17	+4 +/–
А они замеряли потерю производительности на коде, который не спамит потоками потому что по другому никто и не пытался программировать?
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от анон (?), 13-Фев-25, 19:17	+2 +/–
В убунтовском ядре уже стоит HZ_1000. Раньше было только в lowlatency, но теперь и в generic
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #61

13. Сообщение от НяшМяш (ok), 13-Фев-25, 19:19	+/–
Давно уже так работает, гуглить tickless kernel.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #59, #75

14. Сообщение от Совершенно другой аноним (?), 13-Фев-25, 19:20	+1 +/–
>> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления" это немного не то. Вопрос не про увеличение потребления энергии, а про потерю производительности. В то время, пока процессор бегает по прерыванию он, очевидно, не выполняет какую-либо полезную работу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

15. Сообщение от Аноним (15), 13-Фев-25, 19:26	+1 +/–
Юзаю 100Hz уже 7+ лет и комп не парится.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #29

16. Сообщение от Oe (?), 13-Фев-25, 19:26	–8 +/–
Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно почему это до сих пор не сделано, а сейчас уже не нужно ибо freesync. Интересно, сколько еще времени пройдет пока компьютер начнет работать с временем нормально? Видео только на аппаратных плеерах нормально можно смотреть, на компьютерах сплошной джиттер кадров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #26

17. Сообщение от Аноним (17), 13-Фев-25, 19:27	+2 +/–
Глянул специально ядро. Есть варианты: 100, 250, 300, 1000. Но как я понял, можно и пропатчить, если сильно надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #81, #91, #92

18. Сообщение от Аноним (17), 13-Фев-25, 19:28	+1 +/–
Фороникс говорит, что не всё так однозначно!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #51

19. Сообщение от Oe (?), 13-Фев-25, 19:28	+4 +/–
Закончиться динамической частотой таймера. Я её даже на ардуинке делал, пока есть задачи 1000 Гц, когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #25, #76

20. Сообщение от KKK (?), 13-Фев-25, 19:34	–4 +/–
Google уже давно мог бы написать собстенную ОС под свои задачи.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #28, #31, #32, #49, #66, #90, #170

21. Сообщение от Аноним (-), 13-Фев-25, 19:35	+4 +/–
> Закончится тем, что 1000 это много, а 500 в самый раз. :) Смотря для чего. На обычном десктопе - вы точно хотите 1000Гц, для уменьшения латенси и уменьшения всяких нездоровых дергов. Ибо чем быстрее шедулинг задач - тем ниже латенси каждой задачи. Быстрее очередь доходит до энного желающего пожрать ресурсы проца. Это разумеется ведет к некоему оверхеду. Однако в "full dynticks" ядрах эффект не такой уж и большой - ибо если известно что в энный момент делать нечего, то и прерывания от таймера скипаются, что частично аннулирует аргументы второго инженера из гугля. Как видно из бенчей - результат разный и всяко плюс-минус считанные проценты. На десктопе и лаптопе более приятный десктоп от более низкой латенси - явно перевешивает экрномию на спичках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #83, #89

22. Сообщение от Аноним (22), 13-Фев-25, 19:35	+12 +/–
Лоурайдер... Попробуй выставить 50Гц как в розетке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

23. Сообщение от turbo2001 (ok), 13-Фев-25, 19:40	+1 +/–
В божественной федорке тоже 1000
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #114, #144

25. Сообщение от Аноним (25), 13-Фев-25, 19:41	+3 +/–
Все уже давно придумано до вас. В dynticks ядрах (типовые дистровые ядра обычно с ним собраны) - если делать нечего, таймер и не дергают. Как видите это однако не всегда срабатывает, как в том примере когда группировка таймеров не удалась. С другой стороны группировка означает что таймеры были - весьма неточные, и латенси отстойная. > Я её даже на ардуинке делал, пока есть задачи 1000 Гц, > когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто А на STM32 вообще можно DVFS делать, если не лениво. Надоело молотить на всю катушку? Можно закрутить делитель частоты и свалить на мизерную частоту. А у некоторых и вовсе - переключился на допустим часовой кварц, проц на 32 кГц конечно не чемпион производительности, но неспешно смотреть на кнопки или что там - хватит, а кушает на такой частоте - микроамперы. У некоторых есть и понижение вольтажа Vcore, но вот с ним можно откушать все прелести реализатор DVFS сполна. Т.е. неправильное секвенсирование смены вольтажа и частоты - запросто дестабилизирует чип.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

26. Сообщение от Аноним (25), 13-Фев-25, 19:49	+3 +/–
> Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно > почему это до сих пор не сделано Потому что изначально это вообще совсем разные, независимые подсистемы, внезапно. То-есть у видяхи на борту - встроен хардварный блок, типа ультра-продвинутого DMA который гонит кусок VRAM на экран, синтезируя при этом времянки протокола как надо. Этот блок так изначально - достаточно автономная штука, и ничего ни о каких системных таймерах вообще не знает. Более того - как вы себе представляете допустим синхронизацию 250 Гц таймера с 120 Гц монитором? Ничего что сие - не делится нацело? Более того - и у таймеров и у интерфейсов могут быть свои соображения по части точности выдаваемых там частот. А с DVFS у системного таймера частота еще и меняться может вроде. Там есть несколько вариантов что юзается как high-precision таймер. Тогда при попытке это сделать имплементер вероятно сойдет с ума от сложности задачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #34, #84

27. Сообщение от Аноним (27), 13-Фев-25, 19:50	+1 +/–
А можно адаптировать готовую ОС под свои задачи, тогда писать ОС не придётся - вот такой вот поворот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

28. Сообщение от Скрудж (?), 13-Фев-25, 19:53	+1 +/–
ОС да, а все драйвера мира (существующие и будущие) - нет. Но толку с ОС, если она не работает с железом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

29. Сообщение от Аноним (-), 13-Фев-25, 19:54	–2 +/–
> Юзаю 100Hz уже 7+ лет и комп не парится. Комп то не парится. А вот его владельца будет ожидать отстойный и дерганый experience, ибо решение о том какую задачу вообще пускать - принимается раз в 10 мс. Что довольно дофига, учитывая многопотосночть и вообще число программ и результирующее число претендентов на квант времени. Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный. В общем 100Гц ядра - только для махровых вебсерверов, замурованных в стену. Где никто не заметит +/- 100 мс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #62, #180

30. Сообщение от Аноним (32), 13-Фев-25, 20:01	+/–
Кто-то визжал в комментах про 500 герцовые Моники вот. Для них и надо.
Ответить | Правка | Наверх | Cообщить модератору

31. Сообщение от Аноним (-), 13-Фев-25, 20:01	+/–
> Google уже давно мог бы написать собстенную ОС под свои задачи. Уже попробвали! "Man Fucshia". Было полкило воплей о захвате мира, линукскапце, который вот-вот, уже почти совсем, еще немного - и пингвинам амба, на андроиде, десктопе и вообще! Время шло. Куча хипстеров написала... нечто. С драйвером FAT на игого. Оказалось что он почти не тормозит, и почти не жрет память. Но "почти" все портило. Мир все никак не захватывался - недоумевая зачем нужно нечто с тормозным и жручим драйвером FAT и более нифига, "зато от гугли", "зато драйвер на go". Через несколько лет этого воло... ну в общем занятий непотребством - тима начала о чем-то догадываться. Они задекларили идею переписа дрова - на хрусте! "Для улучшения перфоманса". И пошли переписывать свой инновационный драйвер фата, теперь банановый^W на хрусте. Но к этому моменту менеджмент, увы, тоже стал о чем-то догадываться на тему перспектив проекта. Да и провел тиме децимацию. А план по захвату мира - был немного урезан. Теперь оно захватывает мир - на паре фоторамок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

32. Сообщение от Аноним (32), 13-Фев-25, 20:01	+1 +/–
Гугл уже давно не смог написать свою ос Фуксию. Теперь портит ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

34. Сообщение от Аноним (34), 13-Фев-25, 20:17	–1 +/–
> Ничего что сие - не делится нацело? Ничего. Не хочет делиться — будем умножать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

36. Сообщение от Аноним (36), 13-Фев-25, 20:27	+1 +/–
Вопрос на опережение: возможно ли это будет как-то отключить и вернуть назад? (да, кора дуба и квадратный монитор из 2004, но это не ваше дело)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54, #55, #57

37. Сообщение от Аноним (37), 13-Фев-25, 20:28	+/–
> При использовании дисплеев с частотой обновления 120Hz, типичных для современных [...] мобильных устройств Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #43, #44, #71, #73, #97, #163

39. Сообщение от Аноним (39), 13-Фев-25, 20:30	+/–
> Конфигурация с 1000Hz оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart Что? Опенсорс копирка марио карт теперь является тестом?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72

40. Сообщение от Аноним (40), 13-Фев-25, 20:31	+/–
И кто гуглу запрещает у себя в гугле 1000Hz поставить?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

41. Сообщение от Аноним (36), 13-Фев-25, 20:32	+1 +/–
> Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи. Даже на тех где есть стоит динамическая частота обновления. Но в целом да, 60 это стандарт и будет им ещё не один десяток лет. Даже в айфонах не спешат с этим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #53

42. Сообщение от Аноним (42), 13-Фев-25, 20:38	–1 +/–
А че не 1024? Там жеж, насколько я знаю, еще во времена каменного века на PC AT (на XT RTC был не обязательной железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. Все работало. Не тормозило.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

43. Сообщение от Аноним (43), 13-Фев-25, 20:39	+/–
Я покупал свой хонор в 2022. Уже в то время большинство телефонов от 150 денег имели минимум 90 герц
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

44. Сообщение от Аноним (-), 13-Фев-25, 20:41	+3 +/–
> Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже > 90 герц далеко не на всех, да и то оно по > умолчанию выключено, ибо выжирает и без того немощные батареи. Немощные батаереи нынче так то - во всю крышку, если вы не заметили. И емкостью под 6 амперчасов. От этого скоро авто можно будет прикуривать! Выжирает их - таки - блевота на электроне, когда кирпич норовит сварить яйца лежа в кармане. Или просто кач гигазов рекламы этим барахлом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #80

45. Сообщение от Омнонном (?), 13-Фев-25, 20:45	–3 +/–
Очередной хре с горы ниасилив решение своих задач, пытается решить их за счёт всех остальных.
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от Омнонном (?), 13-Фев-25, 20:46	+/–
А предлагатор сборку ядра не осилил пока ещё, только изменение кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

48. Сообщение от Аноним (-), 13-Фев-25, 20:51	–2 +/–
> А че не 1024? Там жеж, насколько я знаю, еще во времена > каменного века на PC AT (на XT RTC был не обязательной > железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. > Все работало. Не тормозило. А сейчас это делается чем-то другим, типа HPET или TSC (на x86-64). Они намного более шустрые и потому точные. У других платформ тоже - как правило скоростные, перепрограммируемые таймеры есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #60, #106

49. Сообщение от Аноним (-), 13-Фев-25, 20:52	+2 +/–
Мог бы. Но зачем? Проще использовать готовый труд сообщества. Главное направлять его, аки пастух стадо баранов, в нужном направлении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

51. Сообщение от Аноним (51), 13-Фев-25, 21:12	+3 +/–
> Фороникс говорит, что не всё так однозначно! Фороникс говрит, судя по опыту, что неоднозначность там спичечная и для адекватных людей очевидно, что движняка такого не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

52. Сообщение от Аноним (52), 13-Фев-25, 21:16	+2 +/–
Передрались. "Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

53. Сообщение от Аноним (53), 13-Фев-25, 21:16	+1 +/–
> 60 это стандарт и будет им ещё не один десяток лет Откройте для себя хотя бы среднебюджетные телефоны. Хотя уже и на самом дешмане часто 90 Гц бывает. > Даже в айфонах не спешат с этим «Даже»… в айфонах много с чем не спешат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #79

54. Сообщение от Аноним (54), 13-Фев-25, 21:21	+2 +/–
Там нечего возвращать, буквально лишь поменяли 1 число в конфиге по-умолчанию. Это ни на ком вообще не отразится, так как дистрибутивы в любом случае свои конфиги используют. И да, многие уже давным-давно 1000 HZ используют. А Core2Duo кстати достаточно современный процессор. Для него таймер этот капля в море, увеличение частоты только приведет к улучшению отзывчивости системы. Разницу в нагрузке цпу между разными значениями таймера могут увидеть разве что владельцы каких-нибудь совсем музейных 386-ых или embedded кофеварок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #56

55. Сообщение от scriptkiddis (?), 13-Фев-25, 21:21	+/–
Как и не наше дело как это отключить и вернуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

56. Сообщение от scriptkiddis (?), 13-Фев-25, 21:23	+1 +/–
Сижу на 300 и никаких жутчайших лагов и проблем о которых тут пишут нету. ЧЯДНТ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #70, #169

57. Сообщение от Аноним (172), 13-Фев-25, 21:54	+/–
Сейчас ты можешь поставить HZ_1000, просто в дефолтном конфиге стоит HZ_250 И в мэйнстримных дистрибах мэйнтейнеры ставят HZ_1000 Если ты не на Генту или ЛФС, то скорее всего у тебя и так стоит уже 1000 Если же ты собираешь ядро сам(судя по вопросу нет), то просто сможешь переключить и все
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #65

58. Сообщение от Ivan_83 (ok), 13-Фев-25, 21:59	+2 +/–
Фиговые инженегры у гугла, всякую чушь пишут. Никто не написал что при частом переключении контекстов повышается отзывчивость всяких десктопов/интерактивов но при этом же увеличивается вымывание кешей из за более меньшего кванта времени работы одной задачи на одном ядре - те жручие задачи начинают медленее работать. Частота влияет на планировщик задач, поэтому per process оно не полуится сделать, по крайней мере без переделок шедуллера и прочих соседних внутренностей ядра.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87, #94

59. Сообщение от Ivan_83 (ok), 13-Фев-25, 22:01	+/–
Это не совсем оно. Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда потоков больше чем ядер (те почти всегда и особенно под нагрузкой).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #100

60. Сообщение от Ivan_83 (ok), 13-Фев-25, 22:04	+/–
HPET как раз не оч любят, типа оно на PCI шине и оверхэд большой, вот TSC типа где то прямо в проце без лишних шин посредине.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #103, #131

61. Сообщение от Ivan_83 (ok), 13-Фев-25, 22:06	+/–
И чо? Во фре сколько себя помню HZ=1000. Помню игрался давно уже на арме с этим и уменьшение до 250 давало хороший буст, ниже уже разницы не было так заметно. Но и терминал начинал немного подлагивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #74

62. Сообщение от Аноним (15), 13-Фев-25, 22:12	+2 +/–
Чем больше ядер - тем менее актуален планировщик. Для игорей можно выделить ядра,  которые будут сидеть на процессе. Если процессу хватает ядер, то таймер не нужен (tickless), а увеличение его частоты даст обратный эффект по производительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #69, #130

63. Сообщение от Аноним (15), 13-Фев-25, 22:28	+/–
Сомневаюсь что патч будет принят. Скорее Линус поржёт и закроет Юсуфу доступ.
Ответить | Правка | Наверх | Cообщить модератору

64. Сообщение от Аноним (64), 13-Фев-25, 22:32	–1 +/–
А ведь это всё из-за Gnome, который лагает как какой нибудь смартфон Lenovo со вторым андроидом, не нужны нам эти "улучшения" на Openbox, тут и так всё работает отлично.
Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от Аноним (65), 13-Фев-25, 22:46	+/–
Посмотрел только что в дебиане CONFIG_HZ_250=y.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #95

66. Сообщение от Шарп (ok), 13-Фев-25, 22:47	+/–
> Google уже давно мог бы написать собстенную ОС под свои задачи. А он не может. С чего ты решил, что гугл всемогущий. Например это гугловские бойцы придумали архитектуру трансформер, на которой сейчас всякие чат-гпт работают, но они не лидеры в нейросетках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

67. Сообщение от th3m3 (ok), 13-Фев-25, 23:20	–2 +/–
Судя по тестам, лучше оставить как есть. Работает - не трогай!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #161

68. Сообщение от Кроносквад128 (?), 13-Фев-25, 23:30	+/–
Всё уже продумано в 5.6.0 эти только на этапе дао пути
Ответить | Правка | Наверх | Cообщить модератору

69. Сообщение от Аноним (69), 13-Фев-25, 23:50	+1 +/–
> Чем больше ядер - тем менее актуален планировщик. Скажи это сейчас интелу)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

70. Сообщение от Аноним (69), 13-Фев-25, 23:54	+/–
Ты не сравниваешь, вот что ты не делаешь. Поставь 1000 и сравни сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #108

71. Сообщение от Аноним (69), 13-Фев-25, 23:56	+1 +/–
С разморозкой. В смартах уже пару лет как 120 есть, даже в мидле. И, ты только не падай!, есть экраны с динамической герцовкой 1-144.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

72. Сообщение от Аноним (69), 13-Фев-25, 23:57	+2 +/–
линукс гейминг во всей красе)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

73. Сообщение от Xo (?), 14-Фев-25, 00:08	+/–
Пользователь ифон детектед)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

74. Сообщение от Аноним (74), 14-Фев-25, 00:54	+1 +/–
Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном ядре. Если не нравится настройка по умолчанию. Не ясно что мешает в Линуксе сделать так же. Если вдруг кому дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только пересборка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #129

75. Сообщение от Аноним (75), 14-Фев-25, 01:48	+1 +/–
>cat /boot/config-6.12.13-amd64 | grep CONFIG_NO_HZ_FULL >CONFIG_NO_HZ_FULL=y В общем - не понятно, о чём буря в стакане.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

76. Сообщение от Аноним (76), 14-Фев-25, 01:56	–4 +/–
в винде так сделано из коробки :) т.е. по дефолту 64 или 100гц, а если софтине нужно больше, то она сама выставляет нужный таймер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #86, #105, #154

77. Сообщение от Балагур (?), 14-Фев-25, 03:06	+/–
Инженеров linux у нас не осталось, судя по комментариям и самому посту. У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает, потому что 1/250 или даже 1/100 процессорного времени какого-нибудь i5 13500 - это слишком много тактов, то скидулер пускает следующий процесс.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #88, #149

79. Сообщение от Русская ядерка (-), 14-Фев-25, 05:14    Скрыто ботом-модератором	–2 +/–
> в айфонах И правильно делают. Премиальный продукт vip класса должен быть надёжным и проверенным. И не спорь. Иначе бы все политики и бизнесмены покупали щаоми, а не айфоны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

80. Сообщение от Русская ядерка (-), 14-Фев-25, 05:16	+1 +/–
> И емкостью под 6 амперчасов. Был смартфон в 2011, кажется самсунг гэлэкси 2. Не знаю какая там батарея была, но явно меньше. И хватало его дня на 3, при том, что я с него сидел часами в приложении в контакте, слушал музыку, сёрфал вэб и играл в казуальные игрульки типа энгри бёрдс. Современные телефоны дай бог чтобы до вечера хватило зарядки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

81. Сообщение от Аноним (-), 14-Фев-25, 06:26	–8 +/–
>можно и пропатчить, если сильно надо. Этот жаргон меня уже достал. Можно сконфигурировать исходники ядра, выставив частоту в 1000 Гц и заново скомпилировать. Наложение патча это другое действие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #99, #122

82. Сообщение от Аноним (82), 14-Фев-25, 06:29	+/–
А если собрать с HZ_10?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #134

83. Сообщение от Аноним (-), 14-Фев-25, 06:35	+1 +/–
Если у тебя нездоровые дёрги, то частота тут не причём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #121

84. Сообщение от Смузихлеб забывший пароль (?), 14-Фев-25, 07:34	+/–
Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде бы, системы тоже разные и не очень-то зависимые В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6 Но переделывать придётся много
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #93

86. Сообщение от n00by (ok), 14-Фев-25, 07:55	+/–
А в каком году документировали такой эффект от вызова timeBeginPeriod()? Я этот момент не застал, в нулевых пришлось расковырять планировщик полностью, начиная с ISR таймера, что бы обосновать "всем известный" хак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

87. Сообщение от n00by (ok), 14-Фев-25, 08:06	+1 +/–
Что бы повысить отзывчивость, достаточно уменьшать квант для "интерактивных потоков". Что делается в Виндос, а потому об этом говорить как бы неприлично. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #98

88. Сообщение от n00by (ok), 14-Фев-25, 08:10	+/–
"Чаще всего делает" это из разряда "но у меня на виртуалке всё работает!" Инженер умеет делить и умножать, а потому считает вероятность "всего лишь 1 из миллиона" неприемлемой, учитывая общее количество систем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #107

89. Сообщение от Андрей (??), 14-Фев-25, 08:16	+2 +/–
Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" не будет сильно заметна глазу, что собственно и по бенчмаркам заметно, где прирост есть, но всего 5-10% и нигде не указан расход энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то тут ещё стоит подумать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #96, #123

90. Сообщение от Аноним (90), 14-Фев-25, 08:19	+/–
Пытался, получилась Фикция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #166

91. Сообщение от Аноним (91), 14-Фев-25, 08:29	–2 +/–
Пользуюсь исключительно 2000HZ - оптимально для виртуализации окон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

92. Сообщение от Аноним (91), 14-Фев-25, 08:31	+/–
Стоит отметить нормальную работу вплоть до 3000HZ. На частоте 4000HZ система уже не загружалась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #112

93. Сообщение от Аноним (-), 14-Фев-25, 09:11	+/–
> Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же > движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без > участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде > бы, системы тоже разные и не очень-то зависимые Ну как бы да, со временем - отрастили фичи информирования софта о таймингах рисовки на экран, чтобы тот мог рисовать без тиринга. А прочий page flipping/double buffer чтобы уж совсем наверняка - при этом есть 2 видеобуфера, один летит в провод, второй рисуется софтом. А когда настало время - указатель переставляется на второй. А софт идет рисовать в первый. Но маневр хоть и избавляет от тиринга, не совсем халявен по латенси, опять же. Ибо теперь вы с гарантией ждете нового кадра, чтобы вывести новый вариант картинки, хоть как. > В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6 А ничего что источник тактовых частот железок - изначально - разный? Поэтому вот так жестко - их тайминги друг на друга не завязаны. Это _асинхронные_ процессы, которые могут разбежаться по времени без специальных мер. То что оно где-то там относительно асинхронно может информировать что вот тут у нас vblank - ну да, однако это несколько иное чем жестко подвязывать на это процессы на основном проце. Так то оно IRQ какой-нибудь сделает, сообщив процу - что - мол, так и так, хочу фрейм. Но если пытаться жестко подвязать к этому шедулинг задач... придется сделать какой-то жуткий изврат, типа софтварного (!!!) PLL - который утрясает расхождение частот железок по ходу пьесы. Без этого дикого изврата тайминги постепенно уедут - и оно будет делать вообще совсем не то что вы представляли, выбивая почву из под ног в максимально неудобный для этого момент. > Но переделывать придётся много Это вообще приведет к очень странным извращениям которые совсем не факт что будут очень хорошо работать. И Linux все же - generic операционка, не только для десктопов. Насколько такой кошмарик оправдан - большой вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #178

94. Сообщение от Аноним (94), 14-Фев-25, 09:33	+/–
весь проц должен отжирать шедуллер, а не ваши процессы! иначе не пойдёте покупать новый девайс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

95. Сообщение от Аноним (95), 14-Фев-25, 09:35	+/–
ArhcLinux: CONFIG_HZ=300
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #109, #147

96. Сообщение от Оно ним (?), 14-Фев-25, 09:36	+1 +/–
Вообще-то прямо здесь в статье указан расход, если вы посмотрите буквально следующий абзац. Видно, что среднее и максимальное энергопотребление не отличаются, только минимальное на 250 Гц ниже. Из чего можно сделать вывод, что на 1000Гц слегка сократится работа в режиме простоя, и то вряд ли значительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

97. Сообщение от Оно ним (?), 14-Фев-25, 09:42	+/–
Пару месяцев назад купил бюджетный самсунг с 90 Гц - и ничего не выжирает. Спокойно держит сутки, а если игры не гонять, то и двое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

98. Сообщение от Ivan_83 (ok), 14-Фев-25, 09:48	+1 +/–
А ты пойди найди на линухе такие процессы :) Это в венде с геум втащенным в ядро есть за что зацепится при поиске интерактивных. И насколько я понимаю там не уменьшение кванта времени а повышение приоритета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #104, #125

99. Сообщение от sotlef (ok), 14-Фев-25, 10:10	+15 +/–
Тут необходимо именно пропатчить, чтобы в списке частот появилась частота 500 Гц
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

100. Сообщение от Аноним (-), 14-Фев-25, 10:43	+/–
> Это не совсем оно. > Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда > потоков больше чем ядер (те почти всегда и особенно под нагрузкой). Tickless - это некая продвинутость для снижения жора энергии от высокого HZ планировщика и уменьшения его негативных эффектов. Идея в том что если кернел видит что делать нечего, оно не дергает систему, не wake up-ит проц - и отвисает в глубоких режимах powersave дальше, до тех пор пока не появится что-то что нужно делать. Суммарно соответственно система может больше отвисать в экономных режимах, даже если частота переключения задач формально и высокая. А реально - лишь когда поводы есть. Да, как видно в примере с таймерами - иногда это все же ведет к деоптимизации, когда группировка пачки таймеров не удалась. Зато таймеры точнее и латенси системы ниже. При сохранении части бенефитов более низких частот шедулинга. Тот случай когда и на елку залезли, и зад не очень ободрали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

101. Сообщение от _kp (ok), 14-Фев-25, 11:00	+1 +/–
Я с 2011 года использую 1000Гц, и всё хорошо, никаких противопоказаний, одни плюсы. Странно что до сих под воду в ступе толкут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #113

102. Сообщение от _kp (ok), 14-Фев-25, 11:04	+1 +/–
Светлая тема на Олед дисплее увеличит энергопотребление на порядкИ больше, чам частота таймера. Напомнило экономию на спичках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

103. Сообщение от Аноним (103), 14-Фев-25, 11:04	+1 +/–
Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как на том же STM8? Или слишком монолитно? Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на eventloop которые внутри других eventloop и при этом всё нативное ПО, написанное с учётом этого подхода летает и не заикается вообще никогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #132, #145

104. Сообщение от Аноним (103), 14-Фев-25, 11:08	+1 +/–
Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших традициях всё упирается в кривизну прикладного ПО. Причём после ухода Балмера даже родные тулзы делаются абы как и без учёта всего этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98 Ответы: #133

105. Сообщение от Аноним (91), 14-Фев-25, 11:18	+1 +/–
Взять хотя бы 2025 Server: точность таймера выставляется на 0.5мс, глобально для всей системы. Windows 11 24H2 - 1ms, но уже для приложений, локально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

106. Сообщение от Аноним (91), 14-Фев-25, 11:30	+/–
HPET - давно превратился в рудименты. И все потому, что достаточно медленный. Проблема усугубляется, когда ядер в процессоре больше двух - тут производительность падает просто катастрофически.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

107. Сообщение от Балагур (?), 14-Фев-25, 12:01	+/–
Чаще всего делает, именно так, даже если ожидает I/O, то тоже делает, но косвенно. А приложения с бесконечным циклом мы в расчет не берём, все тяжёлые вычисления или на GPU, или распараллеливания, и в принципе, тяжёлые вычисления не критичны к тику, они критичны ко времени CPU.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #126, #150

108. Сообщение от scriptkiddis (?), 14-Фев-25, 12:12	+/–
Ставил сравнивал никакой разницы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

109. Сообщение от Аноним (172), 14-Фев-25, 13:18	+/–
Я говорил про мэйнстрим, а ты мне пример из маргинальщины
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

112. Сообщение от Аноним (-), 14-Фев-25, 13:46	+/–
Откуда ты такие таймеры берёшь? Они определённо не ядровские.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #135

113. Сообщение от Аноним (-), 14-Фев-25, 13:51	–1 +/–
Люди уже перестали сами компилировать ядро. Молча жрут обще-дистрибутивное ядро. Смеканешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

114. Сообщение от Аноним (-), 14-Фев-25, 13:57	+/–
Ты прав на вас хорошо тестируют. Попроси разработчиков частоту в 2000 Гц. В 2 раза это же так круто!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #120

120. Сообщение от turbo2001 (ok), 14-Фев-25, 14:31	+/–
Ты так говоришь, как будто принимать участие в разработке опенсорс продуктов (тестировать) - это какой-то зашквар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114

121. Сообщение от Аноним (-), 14-Фев-25, 15:03	+/–
> Если у тебя нездоровые дёрги, то частота тут не причём. Не у меня а у системы. Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #127

122. Сообщение от zog (??), 14-Фев-25, 15:05	+3 +/–
Это не жаргон, а профессиональная лексика. Если у тебя с ней проблемы, то поди вон из профессии!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #128

123. Сообщение от Аноним (-), 14-Фев-25, 15:09	–1 +/–
> Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" > не будет сильно заметна глазу, С full dynticks - мой на 1000Hz работает от батареи более 7 часов. Мне хватает. Это примерно столько же сколько эта модель живет в винде. > что собственно и по бенчмаркам заметно, По бенчмаркам заметно что 1) Вообще зависит от характера задачи. Однозначного победителя нет. 2) Даже если, то разница - несколько процентов. А дергания допустим интерфейса пользователя - это неприятно. Зачем жрать третий сорт, когда можно первый - я не понимаю. > где прирост есть, но всего 5-10% и нигде не указан расход > энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то > тут ещё стоит подумать. Абсолютно no-brainer choice, с full dynticks никаких 20% прироста времени работы явно не будет. На малохольных мобилках, валяющихся в почти-idle большую часть времени, дрями, с мизерным жором в idle - там еще возможны какие-то варианты. Как второй инженер намерял. Но на более обычном компе, даже лаптопе, это неоправданные мучения. На вон том - приблуда на электроне будет лагать так что до проблем таскшедулинга дело просто не дойдет и никто разницу не заметит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

125. Сообщение от n00by (ok), 14-Фев-25, 15:29	+/–
Да, там реализовано временным повышением приоритета. А как иначе? Два таймера - по каждому на свой тип потоков? Если правильно помню, выделялось по три кванта на поток, но повышенный динамический приоритет позволял влезть меж этими квантами вне очереди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

126. Сообщение от n00by (ok), 14-Фев-25, 15:33	+/–
Вспомнил, Минобразования рекламировал новую корочку диплома, там появилось "инженер". Надеюсь, им преподают теорвер и закон больших чисел в частности, а не только "циклы".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

127. Сообщение от Аноним (-), 14-Фев-25, 15:36	+/–
>Не у меня а у системы. Я понял. что не у тебя. >Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience. В глюках твоего компа частота таймер не играет никакого значения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #151

128. Сообщение от Аноним (-), 14-Фев-25, 15:40	–2 +/–
Профессиональная лексика должна озвучиваться по делу. А иначе, это жаргон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

129. Сообщение от Аноним (129), 14-Фев-25, 15:45	–2 +/–
> Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном > ядре. Если не нравится настройка по умолчанию. > Не ясно что мешает в Линуксе сделать так же. Если вдруг кому > дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только > пересборка. Вероятно с статиченым указанием этого - получается более хорощая оптимизация кода. При wakeup проца до 1000 раз в секунду - это некий аргумент. Если вы будете будить проц 1000 раз в секунду, без оптимизаций, батарейка скиснет значительно быстрее чем того могло бы хотеться. Возможно 1 из секретов почему в фри так голимо с управлением питанием. У фряхи с управлением питанием и оптимизацией потребления очень голимо все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #173

130. Сообщение от Аноним (129), 14-Фев-25, 15:48	+/–
> Чем больше ядер - тем менее актуален планировщик. Не, ну если у вас последний EPYC с 192 ядрами, есть шансы что все треды ядра и треды программ конечно найдут свои ядра и будут довольны по уши :). Иначе - это ну вот не факт, их видите ли развелось довольно много. Просто сделайте ps с выводом по тредам - и посмтрите, есть у вас столько ядер или где? Не забудьте ядерные треды, коих нынче дофига. А что, раз ядер более 1 то и ядро совсем не против threaded стать в таком случае.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

131. Сообщение от Аноним (129), 14-Фев-25, 15:53	+/–
> HPET как раз не оч любят, типа оно на PCI шине и > оверхэд большой, вот TSC типа где то прямо в проце без > лишних шин посредине. Так оно вроде TSC и юзает - если это получилось - в порядке приоритета. На некоторых системах однако я встречал ор что мол "clock source unstable" - и тогда fallback на HPET по моему. Но это относительно экзотичный сценарий. Чаще всего и правда TSC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

132. Сообщение от Аноним (-), 14-Фев-25, 15:57	+/–
> Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как > на том же STM8? > Или слишком монолитно? Слишком копролитно, x86-64 - это вам не оно, поэтому все оверинженернутее, навороченнее, и с более 9000 наслоений. А чтоб вы не скучали - DVFS еще и частоту проца меняет постоянно. И вот попробуйте теперь миллисекунду отмерять. Что, не так то просто? Не знаю на счет STM8, а в STM32 при реклоке - приходится и источники времени репрограмить. Но там я обычно не прыгаю как белка туда сюда, и это несколько проще. > Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на > eventloop которые внутри других eventloop и при этом всё нативное ПО, > написанное с учётом этого подхода летает и не заикается вообще никогда. Проблема не в event loop а в том что например сохранение и восстановление контекста - особенно по 1000 раз в секунду - это не совсем халявная операция. У x86 в отличие от STM8 state довольно большой и может включать в себя всякие FPU, SIMD и проч. У этого вашего STM8 такой проблему нету конечно, он может намного бойчее вертеться в IRQ и проч :D. А если вы на x86 такие скорости IRQ попробуете - вам не понравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

133. Сообщение от Аноним (-), 14-Фев-25, 16:00	+/–
> Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших > традициях всё упирается в кривизну прикладного ПО. > Причём после ухода Балмера даже родные тулзы делаются абы как и без > учёта всего этого. Учитывая что там часть от большого ума стала на дотнете - ЭТОМУ блоатваре никакие планировщики не помогут! Обречено умереть тормозным дерганым лаговищем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

134. Сообщение от Аноним (-), 14-Фев-25, 16:02	+/–
> А если собрать с HZ_10? Kernel slowpoke edition - для самых отборных тормозов и слоупоков, чтобы им обидно не было - так и они смогут насладиться тормозами компьютеров наконец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

135. Сообщение от Аноним (91), 14-Фев-25, 16:08	+/–
Достаточно отредактировать один файл и можно добавить любые интересующие вас значения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #136

136. Сообщение от Аноним (136), 14-Фев-25, 16:11	+/–
Неплохо бы было, если бы в рантайме можно было переключать эти герцы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #138

137. Сообщение от Аноним (137), 14-Фев-25, 16:46	+/–
Да сделайте уже частоту таймера динамической, пусть автоматически подстраивается под любую систему и её текущее состояние. Как и всё остальное, но это уже позже и железо поновее будет и технологии.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #142

138. Сообщение от Аноним (-), 14-Фев-25, 16:56	+1 +/–
Блин, как же ядерщики не додумались об этом а? Наверно, работа операционной системы станет не стабильной?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #143

142. Сообщение от Аноним (-), 14-Фев-25, 17:09	+/–
А на сколько стабильно от всех переключений будут работать подсистемы ядра?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #164

143. Сообщение от Аноним (136), 14-Фев-25, 17:16	+/–
А что, всех прям нужно обязать делать это непременно? "Все нормальные" даже и не догадались бы о существовании такой возможности. А те, кому надо поэкспериментировать, воспользовались бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

144. Сообщение от Аноним (136), 14-Фев-25, 17:18	+/–
А в Бжественной сколько?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

145. Сообщение от Аноним (136), 14-Фев-25, 17:21	+/–
А если какой нибудь loop подвесится?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103

146. Сообщение от tim2k (ok), 14-Фев-25, 17:56	–1 +/–
В FreeBSD с 13.1 kern.hz=1000
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #157, #176

147. Сообщение от Аноним (54), 14-Фев-25, 18:31	+/–
Кхм-кхм. https://gitlab.archlinux.org/archlinux/packaging/packages/li... > CONFIG_HZ=1000
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

149. Сообщение от Аноним (-), 14-Фев-25, 19:14	+/–
> Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает Ты сейчас про average случай, но если мы говорим о латенси, то более уместно говорить про худший случай. А худший, это когда процесс задумался на каких-то вычислениях, и не делает shed_yield. > У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Сразу видно "инженера": какое дело кооперативной многозадачности до таймера? Там единственный способ переключения процессов -- это shed_yield или его аналог. Таймер там может хоть с частотой в 100 килогерц генерировать прерывания, активный процесс от этого не перестанет быть активным. Мне кажется, что ты здесь перепутал порядок слов, может ты хотел сказать: "У нас уже тысячу лет в ядре кооперативная многозадачность, а не вытесняющая, да ещё и умная"? Ты ниже примерно так же перепутал циферки: > потому что 1/250 или даже 1/100 процессорного времени [...] это слишком много тактов 1/100 больше чем 1/250, то есть правильнее было бы написать "1/100 или даже 1/250 -- это слишком много. Может ты так же и кооперативную с вытесняющей многозадачности перепутал? Так ведь, инженер?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

150. Сообщение от Аноним (-), 14-Фев-25, 19:17	+/–
> все тяжёлые вычисления [...] не критичны к тику А остальные приложения, которые крутятся параллельно этим тяжёлым вычислениям? Это ведь может в рамках одного процесса происходит, это вполне себе паттерн программирования, выкидывать "тяжёлые" вычисления в отдельный поток, так же как в отдельный ядерный поток уходят все блокирующие операции, для того, чтобы основной поток не блокировался бы ни на вводе/выводе, ни на вычислениях, чтобы он мог быстро отреагировать на ввод пользователя или на пакет прилетевший в сетевую карту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

151. Сообщение от Аноним (-), 14-Фев-25, 20:10	+/–
> В глюках твоего компа частота таймер не играет никакого значения. Эффекты от конечности кванта времени - глюками не являются, для начала. Если уж хочется казаться умным - неплохо бы понять хотя-бы вот это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

152. Сообщение от Аноним (152), 14-Фев-25, 21:30	–2 +/–
Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару гуглоидов будут до посинения меряться патчами в рассылке
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #158

153. Сообщение от Аноним (153), 15-Фев-25, 02:59	+1 +/–
А если в системе 32 потока? 32 задачи одновременно могут вообще ни с кем не бороться за ресурсы. Но опять же, если работающих задач в момент времени больше чем кол-во хардварных потоков, то оверхед гораздо меньше так как вычислительных ресурсов достаточно, чтобы это покрывать. По идее, если процесс все ещё требует ресурсов по окончанию кванта времени и при этом ещё есть свободные ресурсы для других задач - ему выделится сразу же следующий квант времени без переключения контекста, но, его выполнение будет прерываться чаще на 1000 "попросту", чем на тех же 250/300. Конечно, если запустить компиляцию в 32 потока, то скорей всего, десктоп на 1000hz будет более отзывчив, но не на столько, чтобы терять в производительности долгоиграющих задач.
Ответить | Правка | Наверх | Cообщить модератору

154. Сообщение от nrv (ok), 15-Фев-25, 04:36	+1 +/–
ага и там безальтернативно впилен .NET Framework, в который впилен XAML который для своей отрисовки ставит свою частоту на которую потом ругается powercfg /energy ..если это, конечно, сабж
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

157. Сообщение от sysop (?), 15-Фев-25, 08:43	+/–
Получается, ОС для десктопа готова?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

158. Сообщение от Аноним (-), 15-Фев-25, 08:51	+1 +/–
> Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, > iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару > гуглоидов будут до посинения меряться патчами в рассылке И какой процент например серверов на этом? Ах, примерно нулевой?... Понятия о нормальном - достаточно растяжимое понятие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

161. Сообщение от Аноним (172), 15-Фев-25, 09:48	–1 +/–
Хочу тебя расстроить, но «работает — не трогай» это очень плохой девиз придуманный в 90ые, когда для многих что-то настроенное было почти магией Если что-то работает, но можно улучшить, тем более если это что-то работает как сейчас просто в силу исторических причин, то можно и нужно менять Тем более, что по факту в дистрибах и так 1000, а тут просто хотят сменить дефолтное значение. То есть тебя это вообще не коснется никак. Тем более под твоей виндой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #171, #177

163. Сообщение от Аноним (172), 15-Фев-25, 10:41	+/–
Poco X3 NFC — среднебюджетник 2021 года, из коробки 120 Hz обновление экрана Poco M6 Pro — low-бюджетник 2024 года, из коробки 120 Hz обновление экрана Или ты про совсем какую-то дичь разговор ведешь? У Сяоми вон на миддл-бренде 120 это норма
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

164. Сообщение от Аноним (137), 15-Фев-25, 11:11	+/–
Автоматическая адаптация, адаптивная автоматизация. Адаптивная синхронизация...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

166. Сообщение от Онанимб (?), 15-Фев-25, 17:43	+1 +/–
Ну они изначально позиционировали Фуксию как экспериментальную ОС. Ни о каком захвате мира речи не было, всю эту тему раздули блохеры и журнашлюхи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #172

167. Сообщение от Jh (?), 15-Фев-25, 18:44	+/–
в генте это вообще не проблема, можно менять при каждой сборке ядра.
Ответить | Правка | Наверх | Cообщить модератору

169. Сообщение от Аноним (-), 15-Фев-25, 19:05	+/–
> Сижу на 300 и никаких жутчайших лагов и проблем о которых тут > пишут нету. ЧЯДНТ? Систему плотно подгрузить не пробовал чтобы шедулинг стал актуален. Если шедулить нечего - то и проблем с этим нет :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

170. Сообщение от name (??), 15-Фев-25, 19:48	+/–
К сожалению, чтобы написать ОС надо обладать какими-то навыками и опытом кроме верчения деревьев на питоне. А индусы-олимпиадники ничего другого не умеють.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

171. Сообщение от th3m3 (ok), 15-Фев-25, 22:34	–2 +/–
> Тем более под твоей виндой Мaстдаем не пользуюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

172. Сообщение от Аноним (172), 15-Фев-25, 23:36	+/–
Всю эту тему раздули на опеннете, нигде за пределами оного никто и не писал, что дескать все, линукс выкинут и будет Фучия Это реально было просто местечковым бредом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

173. Сообщение от Аноним (173), 16-Фев-25, 04:21	+/–
> секретов почему в фри так голимо с управлением питанием. У фряхи > с управлением питанием и оптимизацией потребления очень голимо все. Голимо ты man'ы читаешь, это точно. УМВР более семи часов, при чём видео безпрерывно стримится. По сравнению с GNU/Linux разница есть, но вообще не большая. Рекоммендую pkg install powerdxx && man -k dev
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

174. Сообщение от Аноним (174), 16-Фев-25, 13:55	+/–
как то на хабре видел пример того что 300 хорошо делится сразу и на 50 (25) и на 60 (30) - отсюда более оптимальная работа графики с частотой дискретизыции, соответственно, на мониорах/телевизорах в том числе при воспроизведении видео и частично борется с тирингом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

175. Сообщение от Аноним (175), 16-Фев-25, 20:12	+/–
По идее, нужно посмотреть как меняется оптимальный интервал на каждом тике. Если он около такой же, то вполне можно предсказывать оптимальный интервал для следующего тика на каждом тике, а не лепить фиксированное значение.
Ответить | Правка | Наверх | Cообщить модератору

176. Сообщение от Аноним (-), 16-Фев-25, 23:19	+/–
А ты 600 Hz (50*120)/10 ей выставить пробовал? Сюрпризы были? (не думаю что будут - я в далёком прошлом выставлял 120 с поллингом, и всё работало - это то-ли семёрка была, то-ли предрелизная бэта восьмёрки...)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

177. Сообщение от Аноним (177), 17-Фев-25, 08:54	+/–
> очень плохой девиз придуманный в 90ые Видимо ваш девиз больше глючности, изменения всего подряд на совершенно другое, каждое обновление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

178. Сообщение от Смузихлеб забывший пароль (?), 17-Фев-25, 13:48	+/–
У многих железок установлена микросхема, в которой определены многие параметры. Вплоть до планок ОЗУ. И ничего, не померли. По сути, изначально требуется чтобы при начальной загрузке системы подтягивались данные в т.ч из моника и на основе них выставлялись некоторые множители. Они и так выставляются на основе иных параметров, просто именно монитор до последнего не учитывали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

179. Сообщение от Аноним Нелюдимович (?), 17-Фев-25, 17:44	+/–
В патчах К. Коливаса это было уже лет 15 тому назад по умолчанию. Теперь и создатели ванили что-то такое поняли. ©"Горячие финские парни".
Ответить | Правка | Наверх | Cообщить модератору

180. Сообщение от roman (??), 17-Фев-25, 22:23	+/–
>Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный. Если софт умер за 5мс то планировщик просто возьмет следующий из очереди, не дожидаясь прерывания, потом сделает его по расписанию еще раз, то есть может быть ситуация что первый отработает 9мс а второй 1мс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема