Технологии

Процессоры Panther Lake и Wildcat Lake могут снижать частоту RAM для защиты Wi-Fi от помех В документации к процессорам Core Ultra Series 3 (Panther Lake) и Core Series 3 (Wildcat Lake) Intel раскрыла детали работы контроллера памяти IMC. Для снижения энергопотребления системы используют режим Gear 4, при котором частота IMC составляет четверть от реальной частоты DRAM. При работе с DDR5-7200 у Panther Lake частота контроллера составляет 900 МГц, а у Wildcat Lake на DDR5-6400 — 800 МГц. Низкая частота IMC компенсируется расширенной шириной шины данных. Технология System Agent Geyserville (SA-GV) поддерживает четыре состояния скорости памяти: LowBW, MedBW, HighBW и MaxBW/Lowest latency. Третья ступень (HighBW) используется алгоритмом DDR Radio Frequency Interference Mitigation (RFIM) для подавления электромагнитных наводок на Wi-Fi в диапазоне 5–7 ГГц. Если работа DRAM на максимальной скорости создает помехи для расположенных рядом антенн Wi-Fi, контроллер автоматически снижает частоту (например, c DDR5-6400 до DDR5-6000 у Wildcat Lake или с DDR5-7200 до DDR5-6400 у Panther Lake), уводя гармоники из радиочастотного диапазона.

Фонд НТИ получил 3% в космической “дочке” АФК “Система” - ООО “Спутникс”. Изменения в ЕГРЮЛ были внесены 7 октября. Одновременно c 75,04% до 72,04% сократилась доля ООО “ГК “Спутникс”, которое принадлежит структурам Владимира Евтушенкова. В числе учредителей ООО “Спутникс” остались Ирина Козловская [15,01%], Владислав Иваненко [6,95%], Станислав Карпенко [1,29%], Анатолий Копик [1,08%], Роман Жарких [0,63%]. “Спутникс” занимается разработкой и производством высокотехнологичных спутниковых компонентов и технологий. Ранее Владимир Евтушенков заявлял, что “крупнейшая частная спутниковая группировка”, которую строит АФК “Система”, составляет 116 спутников. Проект развивается в рамках более масштабной программы, которая предусматривает создание орбитальной сети из 157 малых спутников. Она должна обеспечить новые возможности для дистанционного наблюдения Земли, мониторинга природных пожаров и навигации морских судов. Фонд НТИ планируют отслеживать лишь один проект “Спутникса”, в который он инвестировал, - масштабируемую платформу для низкоорбитальных малых космических аппаратов массой 80-200 кг “Паллада” для оптического зондирования Земли, радаров, широкополосного доступа в интернет в составе спутниковых группировок. @rusven

🧪 Мини-задача перед выходными: читаем дамп С хоста 10.0.0.5 просканировали 10.0.0.10. Вот что показал tcpdump:

10.0.0.5.51234  > 10.0.0.10.22: Flags [S],  seq 1000
10.0.0.10.22    > 10.0.0.5.51234: Flags [S.], seq 5000, ack 1001
10.0.0.5.51234  > 10.0.0.10.22: Flags [R],  seq 1001

10.0.0.5.51235  > 10.0.0.10.23: Flags [S],  seq 2000
10.0.0.10.23    > 10.0.0.5.51235: Flags [R.], seq 0, ack 2001

10.0.0.5.51236  > 10.0.0.10.80: Flags [S],  seq 3000
10.0.0.5.51237  > 10.0.0.10.80: Flags [S],  seq 3500   (через ~1 сек)

❓ Вопросы Какой статус у портов 22, 23 и 80? Какой это тип скана? Почему на порту 22 клиент отправил [R], а не [.] (ACK)? Обращаем внимание на на флаги и на то, что ответил (или не ответил) сервер. Пиши ответы в комментарии. Разбор в понедельник. 🕕 #практика #network #nmap #pentest

А давайте немного поговорим про карты. Вот пара кейсов из жизни разработчиков карт. Пишет Kanat Zhussipov (Senior Software Engineer, Python):

🛰 Почему ваш навигатор не тормозит? Разбираем Contraction Hierarchies (CH) Представьте: вы строите маршрут из Нью-Йорка в Бостон. Между ними ~350 километров дорог, тысячи развязок, заправок и десятки тысяч жилых тупиков в штате Коннектикут. Если искать путь обычным алгоритмом Дейкстры, он будет «заглядывать» в каждый двор по пути, проверяя: «А вдруг через эту парковку в Стэмфорде доехать до Бостона быстрее?». Это занимает секунды. Google Maps или OSM выдают результат за миллисекунды. Секрет — в Contraction Hierarchies (CH). 🏙 Пример: NY ➔ Boston Вместо того чтобы работать с «плоской» картой, CH превращает её в строгую иерархию, где каждому перекрестку присвоен ранг важности. 1. Выезд из Нью-Йорка (Climbing the Ladder) Вы стартуете из Таймс-сквер. Алгоритм запускает поиск, но с железным правилом: идти только к узлам с более высоким рангом. С узкого переулка он сразу перескакивает на авеню, оттуда — на шоссе I-95. Как только вы оказались на I-95, алгоритм «забывает» про существование съездов в маленькие городки. Для него их ранг ниже, а значит, они «невидимы». 2. Магия Shortcuts (Прыжки через штаты) На этапе подготовки (Preprocessing) алгоритм уже «схлопнул» скучные участки дорог. Вместо сотен мелких узлов на трассе между городами, у нас есть один Shortcut (ярлык) с весом, равным общему времени в пути. Поиск из Нью-Йорка просто «летит» по этим ярлыкам, не тратя ресурсы на обсчет каждого километра. 3. Встреча в Бостоне (The V-Shape Search) Одновременно запускается поиск из Бостона навстречу. Он тоже идет только «вверх» по иерархии: От вашего отеля в Бэк-Бэй ➔ на городскую магистраль ➔ на то же шоссе I-95. Два поиска встречаются в «самой высокой» точке (на главной магистрали). Область поиска выглядит не как огромный круг, а как два узких луча, направленных друг на друга. 🚀 Почему это System Design Masterpiece? Скорость: Поиск сокращается с миллионов операций до нескольких сотен. Точность: В отличие от эвристик (типа A*), CH гарантирует математически кратчайший путь. Space-Time Tradeoff: Мы тратим немного памяти на хранение ярлыков (Shortcuts), чтобы получить колоссальный выигрыш в скорости ответа (Latency). Итог: Когда вы едете в Бостон, алгоритм видит мир как сеть скоростных хайвеев. А когда вы ищете дорогу в соседний двор — он работает на «нижних этажах» той же самой иерархии.

А вот еще был случай. Пишет Ivan Petrakov (Senior Staff Software Engineer, Ruby on Rails): Н

аш поиск по карте занимал 3 секунды на запрос. Пользователи зумили и двигали карту. Каждое движение запускало новый запрос к базе. 3 секунды каждый раз. Карта казалась сломанной. Мы снизили до 300мс. Улучшение на 900%. Вот как. Старый подход: мы хранили широту и долготу в двух отдельных колонках. Каждый поиск использовал ST_DWithin или bounding box запрос с PostGIS. Работало нормально на маленьких данных. С 2 миллионами точек стало слишком медленно. Решение: quadkeys. Quadkey - это одна строка, которая кодирует местоположение на сетке тайлов карты. Думайте о нем как о почтовом индексе, но для тайлов карты. Чем длиннее строка, тем точнее локация. Зум уровень 1: мир - это 4 тайла (quadkeys: 0, 1, 2, 3) Зум уровень 15: каждый тайл - примерно квартал Вот что мы изменили: 1. Добавили колонку quadkey к каждой геолоцированной записи. Мы предрассчитали quadkeys для каждого поддерживаемого зум-уровня (с 10 по 18). 2. Заменили PostGIS bounding box запросы на простой поиск по префиксу строки. Вместо: WHERE ST_DWithin(point, user_location, radius) Теперь: WHERE quadkey LIKE '0213012%' Поиск по префиксу строки на индексированной колонке работает очень быстро. 3. Добавили составные индексы: (zoom_level, quadkey). 4. Предагрегировали количество точек на quadkey для кластерных представлений. При отдалении показываем кластеры с количеством. Не нужно загружать отдельные точки. Результат: 3 секунды стали 300мс. Карта работает мгновенно. Пользователи могут зумить и двигать карту без ожидания.