To HPET or not to HPET – тестваме отново Coffee Lake vs Pinnacle Ridge

To HPET or not to HPET – тестваме отново Coffee Lake vs Pinnacle Ridge

В раздел: Ревюта, Ревюта, статии и ръководства, Статии от на 11.05.2018, 4,988 показвания
Страница от ревюто: 1 2 3 4 5 6



В ревюто на новите модели на AMD от серията Ryzen 2000 бях споходен от неочакван проблем – изключително ниски резултати на процесорите на Intel в някои игри. Както видяхте и там, причината за това се оказа активирането на High Precision Event Timer. За съжаление ефектът от това се оказа по-голям от ретестваните в статията 4 игри,  поради което реших да изтествам изцяло процесорите с деактивиран HPET.


Нещо повече, този проблем се оказа, че не е уникален, като колегите от Anandtech също са се сблъскали с него и дори успяха да ме изпреварят с обяснението по темата. Така че ако искате да видите по-подробно за какво става дума, силно препоръчвам да разгледате тяхната статия. А аз ще се опитам доколкото е възможно по-просто да обясня за какво става дума, преди да преминем към резултатите.

Всички сме свикнали да измерваме времето с часовник и да се ориентираме лесно по него. За съжаление нещата не са толкова прости за компютърния хардуер и операционната система, тъй като стандартната за хората „резолюция” се оказва прекалено голяма за ефективна работа. Сам по себе си процесорът не разполага с датчик за време, така че не може да каже точно колко е часът в момента. Нещо повече – тъй като по същество работата му се дели на дискретни интервали (тактова честота) с различна дължина при различните модели, „възприемането” на времето може да се различава. За това се използват различните хардуерни и софтуерни таймери, с които да се отмерва времето и да се „напасва” според случващото се в процесора. Лошото при различните таймери, обаче, е разликата в тяхната точност, както и честотата на която оперират, като диапазона варира от няколко КХЦ до десетки МХЦ.

High Precision Event Timer (HPET) е един такъв таймер, който е представен преди доста време от Intel, първоначално с цел да се синхронизират медийните потоци и да не се получават неприятни прекъсвания поради сбъркана синхронизация. Изискването при него е честота от поне 10 МХЦ, което предполага доста висока точност. Заедно с това, за разлика от повечето таймери, които броят от зададена стойност до 0, HPET е постоянен таймер, който брои от 0 нагоре. Това обаче създава и някои проблеми, като заявката за прекъсване трябва да съвпада с дадена стойност на HPET, за да се удовлетвори, което понякога води до загуба на време.

Към другите варианти на таймери попада Real Time Clock, който би следвало да е наличен при почти всяка система, не само в персоналните компютри, който е един от най-старите таймери и оригинално се е базирал на външна схема. Той, обаче, обикновено е с много ниска резолюция (1 или няколко КХЦ), a в някои нови системи е дори и изцяло софтуерен. Още един вариант е използването на Time Stamp Counter, който пък е просто брояч на изминалите тактовете в процесорното ядро. И макар че той би следвало да е с много висока ефективност и резолюция, в зависимост от реализацията може да се окаже, че TSC не е синхронизиран между отделните ядра. Нещо повече, в съвременните системи на Intel (поне от Sandy Bridge насам) и AMD (АМ4) той е свързан към честота на системната шина, промяната на която може доведе до изкривяване на данните от него.

Именно последното беше разкрито през 2013-та година на сайта HWBOT, един от най-големите (ако не и най-големият) ресурси за споделяне на овърклок резултати, при което системите с Windows 8 можеха много лесно да се излъжат и да дадат значително по-големи от реалните резултати. Причината за това беше, че от Windows 8 насам Microsoft смени стратегията си, като целта на операционната система е да се постигне по-широка поддръжка на различни платформи (както по-стари ПЦ, така и таблети и дори смартфорни), което доведе до промяна на използвания по подразбиране таймер от HPET към RTC или TSC.

На пръв поглед това може да не изглежда от значение, тъй като повечето хора така или иначе не овърклокват системите си, още по-малко пък при използването на базовата честота. В действителност, обаче, базовата честота не винаги е абсолютна стойност, закована на 100 МХц – някои дънните платки използват малко по-ниска честота от сорта на 99,8 МХц, при активиран “Spread Spectrum” честотата също може да се променя в рамките на +/- 0,5 МХц, като влияние отказват и температурата и натоварването. Нещо повече, ставал съм свидетел на разсихнронизиране на системния часовник на Windows до такава степен, че за всеки ден имаше отклонение в десетки минути, а възпроизвеждането на видеоклипове беше очевидно по-бавно от нормалното с периодично насичане на звука.

В същото време HPET обикновено се реализира в чипсета и не зависи от тези фактори, съответно неговото използване означава висока достоверност на резултатите и би следвало да елиминира съответните проблеми. Поради тази причина често диагностичните програми използват HPET и понякога своеволно го активират (ако програма ви иска рестарт има голям шанс причината да е това). Също така ако използвате софтуер на HWBOT (за тестовете например използвам HWBot X265 Benchmark и HWBot версията на RealBench) или искате да публикувате резултати там, то активирането на HPET е задължително. Примерно HWBot X265 Benchmark отказва да се стартира на Ryzen системите с изключен HPET, въпреки че по някаква причина може да се пусне на актуалните системи с Intel. Друг пример е използването на софтуера за овърклок на AMD – Ryzen Master, който изисква активиран HPET преди да ви позволи да го използвате.

По принцип производителите в повечето случай не дават особени препоръки по темата с използването на различните таймери, като се изключи AMD по време на първите ревюта за процесорите им Ryzen, които предлагаха деактивирането на HPET, което би следвало да дава малко по-добра производителност. Предвид изложените по-горе проблеми, аз лично до момента винаги използвам активиран HPET по време на тестовете, още повече, че на повечето дънни платки това е стойността по подразбиране в BIOS/UEFI, като някои дори не дават възможност за деактивирането му. Разбира се активиране и деактивиране може да се постигне и на ниво OS. И когато преди съм правил сравнения между производителността, те като цяло са били в рамките на грешката между активиран и деактивиран HPET.



Всички страници от статията:

  1. Таймери и Windows
  2. Spectre и Meltdown
  3. Тестови системи
  4. Резултати – приложения
  5. Резултати – игри
  6. Заключение


Страница от ревюто: 1 2 3 4 5 6




Етикети: , , , , ,


4 коментара

  1. 1 Nichi // 11.05.2018 в 15:06

    Като гледам резултатите, който и процесор да се вземе няма да се сбърка.
    Към DeepBlue – Може ли да се усети някаква субективна разлика между процесорите по време на работа и игра?

    И-и-и-и да не се превръщам в gramar-nazi ама… Тези проценти накрая на страницата с гейм-тестовете не ми излизат. 8700к е по скоро 108% от 8600к а не 116%, а райзена е 104% а не 111%. Процентите за приложенията не съм ги гледал.

    И още един въпроса към всички, защо са над 500лв 8600к и 2600х? Да не е имало някакво поскъпване май 1600х беше по-евтин.

  2. 2 Nichi // 11.05.2018 в 15:10

    Я нрапво да ги постна сметките
    1%мин средни
    i5 100,0 100
    i7 108,3 102,1
    r7 104,1 97,5

  3. 3 Сашо // 11.05.2018 в 16:09

    > Нещо повече, ставал съм свидетел на разсихнронизиране на системния часовник на Windows до такава степен, че за всеки ден имаше отклонение в десетки минути

    Това не е от хардуера, на линукс такова нещо не съм видял при включен ntpd или chrinyd, които стандартно идват със всяка линукс дистрибуция и коригират аномалии в часовника. Даже напоследък се чудех при виндос, как изобщо могат да работят коректно бази данни и други приложения с високи изисквания към точността на времето.

    Друго нещо ми прави впечатление, че при DX12 и вулкан, нещата отиват в полза на AMD. А това бъдещето. То я ясно, че интел ще оптимизират бъдещите процесори, но това показва, че нещата, както много пъти, ще идат в крайна сметка в посоката, която АМД развиват. Да има конкуренция е добре за нас.

  4. 4 Димитър Чизмаров (DeepBlue) // 11.05.2018 в 20:40

    @Nichi – за обобщената производителност в игрите, бях забравил да добавя Civilization DX12, вече уж е оправено. Отделно към средните кадри са добавени и отношенията от времето за хода в Civ. Колкото до дали се усеща разлика при нормална работа – Core i7-8700K с HPET се усещаше на места. Във всички останали случаи не мисля че имаше някаква разлика.

    @Сашо – Vulkan и DX12 работят на по-ниско ниво и са по начало оптимизирани за многонишковост, така че има полза понякога от допълнителните ядра. В добавка в момента Райзените дори имат по-бърз Л3 кеш от Интелите, така че е напълно възможно в някои ситуации да са държат по-добре. На мен ми прави впечатление че минималните кадри в някои случаи са им по-високи, дори и средните да са по-ниски.

Коментари: