Fai 7 8ns что это

Ионизаторы воздуха (Описание и конструкции различных вариантов ионизаторов)

В данной теме обсуждаем различные варианты ионизаторов в том числе Люстра Чижевского

В продолжение темы:

3 однофазных твердотельных реле для нагрева тэна

День добрый, столкнулся со следующей задачей, мне нужно управлять нагревом трехфазного ТЭНа 10кВт, можно ли использовать три однофазных реле? Сигнал управления 4-20мА. – Коллега…

Помогите найти терморезистор

Всем доброго времени суток.В общем у меня на webasto air top evo 3900 навернулся датчик перегрева, точнее темоелемент который стоит в датчике.Помогите пожалуйста найти…

19 комментариев к “Ионизаторы воздуха (Описание и конструкции различных вариантов ионизаторов)”

-igRoman-, в основе умножитель напряжения)) разберал в печке как и наш ун

Типа так

Прикрепления:
Вложение1

хотя мой отличался формой и были ероглифы)

ряд недостатков. это накопление статики на всех мет предметах комнаты, а также заряжается пыль в результате оседает не на полу а на потолке)), из за чего поставил, мет пластину от общего отвода на растоянии 7см от излучающей пластины, и для компенсации поставил кулер который продувает излучатель, результат оказался приятным, при относительно одинаковой производительности пыль ведет себя естественно)), а предметы перестали накапливать статику

как-то давно думал собрать люстру Чижевского(по оригинальной статье), но там было указано, что трансформатор самостоятельно надо мотать на сердечнике от твс и ещё смутили габариты устройства, а именно при оригинальной констр-ии “…крепится к потолку или кронштейну на расстоянии не менее 150 мм…”.
вот эти два момента мне непонятны…
поэтому помогите ответить на вопросы:
1- по поводу трансформатора- почему в статье /publ/ljustra_chizhevskogo_svoimi_rukami/1-1-0-516 про трансформатор мало что написано, неужели так просто можно поставить “…катушка зажигания Б2Б …”, никак не скажется ли это на работе устройства, на сколько такой вариант надёжен и практичен?
2- про излучатель- какие варианты излучателя можно использовать для квартир с низкими потолками(в моём случае 2,5м), как лучше расположить излучатель(как настольный прибор или люстру)? как я понял, в статье в качестве излучателя применён лист металла, насколько это корректно, практично?
С ув. Александр

Как по мне ни насколько, по ЭЛЕКТРОЭФФЛЮВИАЛЬНОЙ ЛЮСТРЕ целые лекции написаны, и только от правильности. изготовления излучателя ионов зависит итог всей этой бадяги. Я лично когда читал за иголки, мне уже перехотелось.
А преобразователь – хоть ТВС, катушки зажигания каму как удобно

-igRoman-, с пластины как у меня в конструкции ионы стекают лучше, придумал не сам где то года 3 назад наткнулся на патент именно доказывающий что с такой конструкции производительность лучше
собрал по оригиналу с иголками работает хуже но это субьективное мнение и основывается на расстоянии с которого чувствуется ионный ветер с этой конструкции 20 см такого же размера иголки 7-10см

[, а еще в новой статье совместил иголки и пластину
игроман по поводу иголок я использовал обычные резисторы ненужные на 330ком 0,125вт(было очень много)

Источник

Найден секретный способ улучшить скорость интернета на вашем телефоне

Что такое DNS сервер

DNS — это система доменных имен, которая обеспечивает связь между названием сайта и его адресом. Принцип ее работы можно сравнить с телефонной книгой на вашем смартфоне. Каждому названию сайта соответствует определенная цифровая комбинация на сервере, и когда вы вводите название в адресной строке браузера, компьютер или смартфон запрашивает цифровой IP-адрес сайта через специальный сервер, который хранит базу этих адресов.

Переход на сторонние серверы может помочь вам устранить эти ошибки, а также получать доступ к некоторым заблокированным ранее сайтам, уменьшить время отклика между вашим устройством и сервером, а значит повысить и скорость соединения.

Существует также специальный протокол DNS over TLS, это тот же DNS, но осуществляемый с дополнительным шифрованием, повышающим безопасность и конфиденциальность пользователя путем перехвата данных.

Как выбрать и изменить DNS-сервер на телефоне Android

Во всех смартфонах на Android, начиная с версии 9.0 добавлена возможность ручной настройки DNS-сервера в настройках.

Чтобы настроить персональный сервер:

Список некоторых альтернативных DNS-серверов:

Google Public DNS. Бесплатный глобальный сервис от Google известен по всему миру, поэтому нет смысла говорить о его надежности. Сервер обеспечивает безопасность и более высокую скорость интернет-соединения, обеспечивая ускоренную загрузку страниц за счет кэширования данных, а также обеспечивает улучшенную защиту от кибератак.

Имя хоста: dns.google

Quad 9 DNS. Эта бесплатная рекурсивная служба, что означает, что для поиска информации сервер может обращаться к другим DNS серверам. Данный сервер обеспечивает высокую производительность, а также блокирует большинство вредоносных доменов, повышая безопасность интернет-серфинга.

Имя хоста: dns.quad9.net

Cloudflare. Данный сервис владеет и управляет огромной сетью серверов и использует их для ускорения работы сайтов, а также для защиты их от вредоносных атак, таких как DDoS. Многие пользователи, подключившиеся к данному серверу, отмечают ускоренную по сравнению со стандартными серверами загрузку страниц в интернете.

Имя хоста: 1dot1dot1dot1.cloudflare-dns.com

AdGuard DNS. С помощью данного сервиса, кроме повышенной защиты личных данных, вы также сможете избавиться от рекламы на страницах сайтов и игр. Реклама вырезается в момент обработки DNS запросов, в результате страницы загружаются быстрее, не потребляя ресурсы смартфона.

Имя хоста: dns.adguard.com

После установки любого сервера из списка необходимо включить, а затем выключить режим полета в настройках вашего смартфона. Это нужно для очистки кэша DNS.

Установка альтернативного DNS с помощью приложения

Для поиска и установки оптимального DNS-сервера можно воспользоваться сторонним приложением из Play Маркета. Одним из таких бесплатных приложений является приложение Net Optimizer, которое сканирует наиболее быстрые и безопасные DNS и производит подключение в один клик.

Скачиваем и устанавливаем приложение Net Optimizer из Play Маркета.

Источник

Исследуем разгонный потенциал шины Infinity Fabric (Zen)

Предупреждение: Особых предупреждений нет, хотел бы я сказать.

реклама

Предупреждение 2: Ввиду полного отсутствия каких-либо доступных методов управления шиной IF, поиск ее пределов будет осуществлен в основном по косвенным признакам.

реклама

Начнем пожалуй с мифа, который железно укоренился в сознании некоторого количества людей, которые так или иначе разносят данный миф везде, где только могут разнести, а после перейдем к практическому разрушению мифа, с тестами и наглядными результатами.

Суть мифа: Частота шины Infinity Fabric (далее IF) = эффективная частота ОЗУ / 2, например: ОЗУ работает на частоте 3200 МГц, значит IF будет работать при частоте 1600 МГц.

На первый взгляд все выглядит логично, если конечно опустить некоторые проблемы данной «формулы» (которые прекрасно будут видны в результате тестов), и конечно если не придираться к словам «проговорившегося» возможно* представителя AMD на Reddit.
* — Лично я не переписывался, так что без понятия кто именно давал ответ, и был ли это ответ именно представителя AMD, и насколько он правдивый.

реклама

Взять, например, CPU-Z, который рапортует о том, что частота КП 1666 МГц, работает ли с такой же частотой шина IF? не факт, и в случае с ZEN и ZEN+, такие частоты, как показала практика, для шины IF недостижимы на постоянную работу, и это будет наглядно подтверждено результатами тестов.

Суть теста для проверки скорости шины IF: Измерение времени доступа между ядрами из разных CCX, в данном случае отлично подойдет SiSoftware Sandra, а так же, для разнообразия, будут тесты в других приложениях.
Важно: Частота ядер процессора должна быть зафиксирована на протяжении всех замеров, работающий BOOST скорее всего внесет значительную погрешность, из за множества факторов, от которых зависит работа технологии.

В теории суть проста, изменяем частоту ОЗУ, и следим за изменениями в задержках, когда частота ОЗУ растет, а задержки изменяются в районе погрешности, это уже сигнал, о том, что частота шины IF больше не поднимается за частотой ОЗУ.

реклама

Для начала, покажу собранные прошлогодние результаты, с процессором Ryzen 5 2600X и памятью Geil GP416GB2400C16SC, те самые, когда тестировал просто из интереса, и после перейдем к более подробному тестированию, уже используя процессор Ryzen 3 1200.

Результаты Sandra, продублированы в текстовые документы, благодаря чему, не составило труда вычислить среднее арифметическое значение задержек, и наглядно представить результаты.
Среднее арифметическое значение брал среди результатов, относящихся только к ядрам из разным CCX, результаты задержек, среди ядер одного модуля CCX, не учитываются, мы ведь ищем разницу скорости шины IF.

Процентная разница по отношению к предыдущему значению была округлена для удобства.
Тест PhotoWorxx реагирует преимущественно на пропускную способность памяти, поэтому разница растет за разницей в частоте ОЗУ, а вот задержки взаимодействия между разными CCX, снижались ровно до частоты ОЗУ в 2400 МГц, при дальнейшем повышении частоты ОЗУ задержки не изменяются в большинстве времени.
Иногда задержки опускаются прямо во время проведения теста, до уровня

111нс, но это не частое явление и бывает только при частотах ОЗУ в 2666 МГц или выше.
Не уверен что получится такие моменты «ускорения» шины IF обнаружить используя Ryzen 3 1200, ввиду малого количества ядер у процессора.

Отчетливо видно, что часть одного из тестов, прошла при более высокой частоте шины IF чем обычно, в данном случае ОЗУ работала при частоте 2866 МГц, я не стал включать все результаты старых тестов в статью, ничего примечательного в них больше нет.

Такое же явление было обнаружено у других людей, которые согласились протестировать свои системы, и поделились со мной своими результатами.

Ryzen 7 1700 & Ryzen 5 2600x

Какие собственно выводы можно сделать на основе полученных данных?

1) Частота IF не может быть выше эффективной частоты ОЗУ / 2

2) Частота IF может быть ниже эффективной частоты ОЗУ / 2

3) Частотой IF невозможно управлять вручную, IF сама выбирает частоту на которой будет работать, и делает она это динамически во время работы.

4) Частота IF не привязана к частоте ОЗУ, но она ограничена частотой ОЗУ.

5) Потолок скорости шины IF по данным Sandra:

6) На этом можно было бы закончить статью, но тогда будет неизвестно, как поведет себя шина IF у моего текущего Ryzen 3 1200, поэтому продолжаем.

Тестовая система:

Теперь настало время более подробного тестирования, использовать я буду следующую конфигурацию:

CPU: AMD Ryzen 3 1200
MB: MSI B450-A PRO MAX
Cooler: Кастом на основе Titan TTC-NK34TZ/RF(BX)
RAM: 2x Samsung M378A1G43TB1-CTD
VGA: Sapphire Radeon RX 560 OC (20.1.2)
Storage: SATA порты: 3-4-5-6, 1x 1TB HGST HTS541010A9E680, 3x 1TB TOSHIBA DT01ACA100
OS: Windows 7 x64 SP1

Замеры будут проводится при следующих параметрах:

CPU: 3.85 GHz
RAM: 1600 MHz, 1866 MHz, 2133 MHz, 2400 MHz, 2666 MHz, 2800 MHz, 2933 MHz, 3200 MHz, 3333 MHz.
VGA: GPU: 1420 MHz, vRAM: 2000 MHz.
Swap file: OFF

Т.к. у системной платы от MSI, нету множителя для частоты 1333 МГц, начинать буду с частоты ОЗУ в 1600 МГц.

Софт участвующий в тестировании:

-SiSoftware Sandra
-AIDA64
-DiRT Rally (EGO 3.0, v1.1.114.5105, оверлей Steam отключен, встроенный тест)
-GRID 2 (EGO 3.0, v1.0.85.8679, AVX, оверлей Steam отключен, встроенный тест)
-Forward to the Sky (Unity, v4.7.0, оверлей Steam отключен, MSI Afterburner)

Методика тестирования:

1) Настройка таймингов ОЗУ для каждого уровня (1600 МГц, 1866 МГц и т.п.).
-Настройка на каждой из частот, производилась до получения минимальных задержек межъядерного взаимодействия, ниже которых больше не выходило получить.
-Для экономии времени (т.к. много профилей частотных нужно настроить), использовался метод разгона ОЗУ, описанный в предыдущей моей статье, а так же ручная «доводка» таймингов.
-Из за большого количества частот, я не буду тестировать на максимальную стабильность (24/7) профили, т.к. это займет очень много времени.

2) Проведение тестов с использованием настроенных профилей частоты/таймингов ОЗУ.

3) Сохранение результатов.

Изначально я не планировал подробно сравнивать результаты AIDA64 cachemem, по причине избыточности пропускной способности шины IF, но для полноты картины их тоже рассмотрю, тем более, данные будут собраны в любом случае.

Результаты в играх: Будут получены средствами встроенных тестов, за исключением Forward to the Sky, в данной игре не предусмотрено встроенных средств тестирования, поэтому для получения результатов будет использован MSI Afterburner, в самом начале игры после высадки, 1 минута тестирования в неподвижном состоянии персонажа и камеры.

Теперь перейдем к настройкам, при которых будут проведены тесты:

Grid 2 (AVX):
Настройки игры были подобраны так, чтобы видеокарта на протяжении всего теста, не доходила до состояния полной загруженности.

DiRT Rally:
Аналогично и в этой игре, настройки подобраны так, чтобы видеокарта не доходила до состояния полной загруженности.

Forward to the Sky:
Не стоит пугаться максимального качества графики, на таких настройках хватит даже GT1030 GDDR5 чтобы «посадить» любой процессор, настолько суровые разработчики на Unity бывают.

Сводка результатов:

— Из-за невнимательности, я забыл запустить Ryzen Timing Checker на частотах 1600 МГц и 1866 МГц, и чтобы не делать тесты заново, я добавлю отдельно скрины RTC.

Внимание: У некоторых людей, скорее всего, будет негодование по поводу таймингов, которые были настроены, и обязательно найдется человек, который упрекнет меня в том, что настроил бы тайминги лучше меня. что я могу сказать, вперед и с песней, я буду только рад если найдется человек, который возьмется провести подобное тестирование, и при этом учтет абсолютно все тайминги, для всех частот, и сможет настроить все идеально.

Полученные данные:

25 178 MB/s

149.1 ns
(-10.4%)

101.6 ns
(-8.5%)

29 308 MB/s
(+16.4%)

143.8 ns
(-3.5%)

92.9 ns
(-8.6%)

33 478 MB/s
(+14.2%)

134.5 ns
(-6.5%)

87 ns
(-6.3%)

37 597 MB/s
(+12.3%)

127.4 ns
(-5.3%)

79.7 ns
(-8.4%)

41 728 MB/s
(+11%)

123.7 ns
(-2.9%)

43 720 MB/s
(+4.8%)

117.5 ns
(-5.0%)

45 662 MB/s
(+4.4%)

116.4 ns
(-0.9%)

49 307 MB/s
(+8%)

115.8 ns
(-0.5%)

51 508 MB/s
(+4.5%)

SiSoftware Sandra:

116 ns, что идентично для R5 2600X (с учетом количества ядер), который я тестировал год назад, уровень задержек R5 2600X оказался примерно таким же, единственное что различает R5 2600X и R3 1200 в данном случае, это то, что для R5 2600X потребовалась частота ОЗУ всего 2666 МГц, когда для R3 1200 потребовалась частота ОЗУ минимум 2933 МГц.

Как оказалось, при равной частоте ОЗУ в 2666 МГц, R3 1200 не способен рядом встать по задержкам с R5 2600X, даже несмотря на около равные частоты ядер (3.85 ГГц и 3.87 ГГц), и более быструю память в паре с R3 1200.

При 2666 МГц ОЗУ, R3 1200 остановился на значении около 127ns, в то время как R5 2600X уже при 2400 МГц ОЗУ, держит около 123 ns, а при частоте ОЗУ в 2666 МГц, способен кратковременно опускать свои задержки до уровня

111 ns, за R3 1200 я не заметил такого поведения, чтобы уровень задержек, в таких же условиях, падал ниже

Но при частотах 2933 МГц и выше, R3 1200 способен был иногда доходить до 110-113ns, преимущественно на частотах 3200-3333 МГц, естественно при тестовой нагрузке от Sandra (по причине редкости таких событий, я не стал создавать отдельную таблицу под такие результаты).

AIDA64 PhotoWorxx:

При частотах ОЗУ 2133-2400 МГц, результат увеличивался по

8%, но при переходе к частоте ОЗУ 2666 МГц, результат увеличился лишь на 5%, даже несмотря прибавку в 11% к ПСП ОЗУ.

При частотах ОЗУ 2800 МГц и выше, прибавка вовсе составляла чуть более 2%, даже при разнице в ПСП ОЗУ 8%.

Исходя из такого поведения, можно предположить следующее: PhotoWorxx интенсивнее использует шину IF, чем Sandra, и как следствие, Sandra показала лимит на уровне 2933 МГц, при котором задержки перестают значительно снижаться, а вот PhotoWorxx, уже после частоты ОЗУ в 2666 МГц, перестал значительно наращивать результат.

Немного математики, используя полученные результаты тестов (округлено для упрощения восприятия):
-разница ПСП ОЗУ между 1600 МГц и 2666 МГц: 66%
-результат PhotoWorxx поднялся на 48%
-разница ПСП ОЗУ между 2666 МГц и 3333 МГц: 23%
-результат PhotoWorxx поднялся на 10%

Итого мы имеем два диапазона, до 2666 МГц, и после 2666 МГц, можно легко заметить, что после 2666 МГц, ПСП ОЗУ растет в разы быстрее, чем результат теста, в отличии от диапазона 1600-2666 МГц, где разница, между разницей ПСП ОЗУ и результатом теста, всего 37% (130% для диапазона 2666-3333 МГц).

И еще один момент, который хотел бы отметить, результаты R5 2600X могут быть выше, при этом имея медленнее ОЗУ, это следствие разницы в объеме кэша, количестве ядер, наличие многопоточности, скорости шины IF (тест Sandra прекрасно показал разницу zen и zen+ в плане IF).

R5 2600X имеет 2 CCX по 3 ядра с быстрыми межъядерными связями, и 2.6 MB L3 кэша на ядро внутри CCX.
R3 1200 имеет 2 CCX по 2 ядра с быстрыми межъядерными связями, и 2 MB L3 кэша на ядро внутри CCX.
По сути для R3 1200, скорость шины IF более критична, чем для R5 2600X, т.к. кэша меньше, разбит на два куска по 4 MB (R5 2600X имеет 2 куска по 8 MB), естественно выше вероятность отсутствия данных в ближнем куске кэша, и ядро будет чаще обращаться к дальнему куску кэша из другого CCX, чем это будет делать R5 2600X.
Как следствие, R5 2600X может достигать более высоких результатов в данном тесте, чем R3 1200.

AIDA64:

Чтение из ОЗУ, закономерно изменяется в след за частотой ОЗУ, ничего примечательного.

25 178

29 308 (+16.4%)

33 478 (+14.2%)

37 597 (+12.3%)

41 728 (+11%)

43 720 (+4.8%)

45 662 (+4.4%)

49 307 (+8%)

Скорости L3 кэша в районе погрешности, ничего интересного, даже в таблицу вносить смысла нет.

Наиболее активное снижение задержек наблюдается до частоты 2666 МГц, когда задержки снижаются на половину или более, от разницы частоты ОЗУ, после 2666 МГц разница задержек, почти всегда, не достигает даже половины разницы частоты.

Копирование в ОЗУ (Copy) поднимается практически линейно с частотой ОЗУ вплоть до уровня 2400 МГц, при переходе к частоте ОЗУ 2666 МГц и выше, скорость копирования в ОЗУ поднимается немного меньше, чем частота ОЗУ и скорость чтения-записи по отдельности.

В итоге рост скорости копирования в ОЗУ после достижения отметки ОЗУ 2666 МГц, на

1% меньше, чем рост чтения и записи по отдельности.
Такая, казалось бы, маленькая разница в 1%, на частоте 3333 МГц создала разрыв в 7.3% между скоростью чтения, и скоростью копирования в ОЗУ, а так же разрыв 6.1% между скоростью записи, и скоростью копирования в ОЗУ, для сравнения, при 2400 МГц ОЗУ, разница была менее 3% в обеих случаях.

DiRT Rally:

Вот и первая программа из разряда игр, что же она покажет?

Все тесты были проведены с первого раза, т.е. без повторных прогонов, по большей части это сделано для экономии времени, заодно исключается возможность искажения результатов, из-за возможного кэширования результатов вычислений игры.

И здесь, я вижу смысл подробнее разобрать полученные данные.

И что мы в итоге имеем:

— значительный рост количества кадров, среднего FPS, мин. и макс. FPS, происходит ровно до частоты ОЗУ в 2400 МГц.
— практически никакого роста по всем параметрам (а то и падение), в диапазоне между 2400 МГц и 2800 МГц, даже несмотря на разницу в частоте ОЗУ 16%, и снижение задержек доступа к ОЗУ на 10%
— начиная с частоты ОЗУ 2933 МГц, происходит незначительный рост производительности, но он весьма неоднозначный.

Grid 2 (AVX):

Настало время Grid 2, и на этот раз, результаты получились гораздо интереснее.

В данной игре я заметил небольшие отклонения во встроенном тесте, машины в тесте имеют небольшие отклонения в маршруте, и это в итоге повлияло на то, каким числом, какие машины приезжали на финиш, я это не сразу заметил, поэтому не стал исключать из тестов данную игру, т.к. часть результатов уже была собрана, объективность результатов в итоге страдает.

Но, даже учитывая небольшую случайность происходящего во встроенном тесте игры, можно заметить, что результат активно поднимался по всем параметрам, вплоть до частоты ОЗУ 2400 МГц.

При частоте ОЗУ 2666 МГц результат продолжил рост, но уже снизился максимальный FPS, что можно попытаться списать на случайность происходящего во встроенном тесте игры.

При частоте ОЗУ 2933 МГц максимальное значение FPS резко поднялось относительно предыдущих значений, однако при дальнейшем повышении частоты ОЗУ, максимальное значение FPS все сильнее падало, возможно так совпало, а может и нет. точно сказать невозможно, из-за случайности происходящего во встроенном тесте игры.

Особое внимание заслуживает общее количество кадров, рост между 1600 и 1866 МГц, оказался практически линейным к частоте ОЗУ, но при достижении частоты ОЗУ 2666 МГц, рост прекратился, и лишь при частоте ОЗУ 3200 МГц (+20% частоты ОЗУ) игра прибавила 5% к общему количеству кадров.

По хорошему следовало бы провести многократно тесты данной игры, но, учитывая специфику встроенного теста, это сделает результаты «размытыми», и скорее всего, не оправдает потраченных усилий и времени, поэтому я просто исключу данную игру из своих следующих тестов, из-за невозможности получить приемлемой точности результат.

Forward to the Sky:

Это довольно старая игра, сделанная в редакторе Unity версии 4.7.0. использует в основном 2 ядра, крайне требовательна к частотам, по причине отсутствия многопоточности в реализации некоторых частей игры.

0.1% low FPS не стал включать в таблицу, т.к. рост заметный происходит только при переходе между 1600 МГц и 1866 МГц ОЗУ, и составил 28%, во всех остальных случаях результат оставался неизменным, и никакой полезной информации не несет.

На количество кадров (всего кадров), частота ОЗУ не сильно повлияла, наибольшая разница оказалась между 1600 и 2400 МГц, при дальнейшем повышении скорости ОЗУ, разница оказалась слишком маленькой.

Идентичная картина со средним, минимальным и максимальным FPS.

1% low FPS между 1600 и 1866 МГц совершил заметное повышение на 7%, но далее случилось затишье, пока частота ОЗУ, не достигла отметки 3200 МГц, подъем на 29% по отношению к частоте ОЗУ 2933 МГц, но повышение частоты ОЗУ до 3333 МГц, ничего не прибавило.
Поведение 1% low FPS конечно странное в зависимости от частоты ОЗУ, но такие получились результаты.

С основной частью пожалуй закончили, теперь перейдем к бонусу, я ведь не зря упомянул в конфигурации тестовой системы SATA порты? и количество накопителей, настал черед разгона BCLK!

На текущей системной плате от MSI, и так все печально с разгоном BCLK, о чем я уже упоминал в своей первой статье, и казалось бы, сравним еще в разгоне BCLK результаты, но увы, отключив половину дисков, и разогнав шину BCLK до 102 МГц, я подогнал множители процессора и ОЗУ чтобы получить такие же частоты, как и без разгона шины BCLK, в итоге я столкнулся с серьезной проблемой.

Результаты Sandra и AIDA64 не отличались от результатов без разгона BCLK, должна быть разница примерно в 2%, но даже такой разницы не оказалось, в итоге я решил не продолжать тесты, и поделился отсутствием результата.

Конечно разгон BCLK на 2% ничего не изменил в плане результатов, но может изменит отпуск таймингов в автоматический режим?

47 765

116.4 ns
(+0.5%)

46 657
(-9.4%)

42 013
(-12%)

Несмотря на значительную разницу в таймингах ОЗУ, которая порой доходит до 15-22%, задержки случайного доступа к ОЗУ поднялись всего на 6.4%, и в линейном доступе на 9%, пропускная способность ОЗУ снизилась на значительные

11%, несмотря на это, результат PhotoWorx снизился лишь на 5.6%.

Отдельно стоит упомянуть разрыв между чтением и копированием в ОЗУ, который достигает 10% (был 7.3%), причем на частоте ОЗУ в 2400 МГц, разрыв менее чем 3%

А вот задержки которые показала Sandra оказались в районе погрешности, ничего интересного.

DiRT Rally:

Падение производительности по всем параметрам не доходит даже до 4%, несмотря на

GRID 2:

И снова переходим к игре с некоторой случайностью происходящего во встроенном тесте, несмотря на значительную разницу в пропускной способности ОЗУ, а так же в задержках доступа к ОЗУ, результаты изменились не так значительно.
Только минимальный FPS линейно задержкам доступа к ОЗУ изменился, а максимальный FPS даже слегка прибавил, но учитывая его пиковое значение на частоте в 2933 МГц (236 FPS), как то не впечатляет.

Forward to the Sky:

Значительная потеря пропускной способности ОЗУ, и увеличение задержек доступа к ОЗУ, практически не повлияли на результаты в данной игре, лишь минимальный FPS слегка изменился, и еще меньше изменился средний FPS.

1% low FPS остался неизменным.

Заключение:

Хотя у меня сейчас и нет возможности протестировать zen+ снова, но собранные результаты говорят об одном, по данным Sandra, шина IF не переходит предел

110 ns, как в случае с zen, так и в случае с zen+, единственная разница в том, что для zen+ чтобы достичь «потолка» скорости шины IF, достаточно частоты ОЗУ всего 2666 МГц, для первого zen «потолок» достигается при частотах ОЗУ 2933-3000 МГц.

Но в реальной работе как показала практика, уже при частотах ОЗУ выше чем 2400 МГц, наблюдается пониженный рост производительности, и чем выше частота ОЗУ, тем меньше повышается производительность, даже если задержки доступа к ОЗУ снижаются, а пропускная способность растет, но сказывается это не так положительно, как хотелось бы.

Это тот случай, когда цифры, остаются цифрами в тесте AIDA64 cachemem, а в реальной работе все не так радужно с ростом производительности от разгона ОЗУ.

Конечно бывают задачи, которые сильно зависят именно от пропускной способности ОЗУ, да и при росте количества ядер, требования к пропускной способности ОЗУ возрастают в ряде случаев, поэтому никто не говорит про бессмысленность разгона ОЗУ, но разгон ОЗУ не панацея, когда дело доходит до скорости шины IF.

В PhotoWorxx результат в любом случае увеличивался с ростом частоты ОЗУ, т.к. этот тест использует активно ОЗУ, но самый активный рост производительности происходил до 2400-2666 МГц ОЗУ.

Значительное снижение пропускной способности ОЗУ на частоте 3333 МГц, влияет довольно слабо на результат PhotoWorxx, набирая с трудом половину разницы, между разницей пропускной способности ОЗУ, когда при частотах ниже 2400 МГц включительно, разница была больше половины, от разницы пропускной способности ОЗУ.

Тем временем, в протестированных играх, результаты прекратили значительный рост после частоты ОЗУ 2400 МГц, были конечно интересные нюансы когда при росте частоты ОЗУ выше чем 2933 МГц, падал максимальный FPS, и странный рост 1% low FPS в игре на Unity, хотя все остальные значения FPS прекратили свой значительный рост уже после 2400 МГц ОЗУ, даже несмотря на рост пропускной способности и снижение задержек доступа к ОЗУ.

Учитывая все имеющиеся данные, можно сделать следующие краткие выводы:

1) Zen и Zen+ имеют значительные различия в скорости шины IF, в пользу Zen+.

2) Zen требует уровень ОЗУ

3) Zen+ уже при частотах ОЗУ 2666 МГц, достигает предела скорости шины IF по данным Sandra.

4) Zen: в играх значительный рост показывает на частотах ОЗУ вплоть до 2400 МГц, дальнейший рост производительности происходит только при активном использовании ОЗУ.

5) Zen: в многопоточном софте активно использующем ОЗУ (по данным PhotoWorxx), значительный рост происходит вплоть до частоты ОЗУ 2400 МГц.

6) Zen: при достижении предельной скорости шины IF, стремительно увеличивается разрыв между чтением и копированием в ОЗУ, при частотах ОЗУ 3333 МГц способен доходить до 10%, когда при частотах в 2400 МГц, разрыв был всего 2.7%

7) Zen: задержки доступа к ОЗУ значительно снижались, вплоть до частоты 2666 МГц, при дальнейшем росте частоты, задержки случайного доступа к ОЗУ замедляют свое снижение, даже при значительной разнице в таймингах.

8) Пропускная способность шины IF избыточна при малом количестве ядер, и без специфических условий (2990WX).

9) Одинаковый рост скорости шины IF в паре с ростом скорости ОЗУ, обычно приводит к линейному росту производительности.

10) Рост частоты ОЗУ, без роста частоты IF, обычно, поднимает результат на половину от роста частоты ОЗУ.

111 ns (на основе результатов полученных с использованием R3 1200, R5 2600X, R7 1700, по данным Sandra).

12) Нет никаких доступных способов ручного управления шиной IF.

Главный вывод у нас следующий:

Частота IF не может быть выше частоты ОЗУ, но, может быть ниже частоты ОЗУ.

Никакой жесткой привязки частоты шины IF к частоте ОЗУ нет, известная формула: «IF = RAM / 2» просто не может работать, шина IF зависит от частоты ОЗУ, но это лишь следствие того, что частота шины IF, ограничена частотой ОЗУ, не более.
Иначе никто не разогнал бы ОЗУ с zen (особенно с zen+)выше 2400-2933 МГц в зависимости от конкретного экземпляра, шина IF просто не позволит такой разгон, будь она жестко завязана на частоте ОЗУ.

Статья и так получилась большой, поэтому на этом закончим.

Источник