Pull to refresh
19
0
Ilia Zykov @izyk

Администратор ПК

Send message
Ну и активы, надеюсь, не в рф.

Как раз, скорее всего в РФ, иначе сложнее отобрать. Это и есть основная ошибка. ИМХО.
Всё как в кино получается: 'И тут Улигбек стелал трагический промах, показал деньги'.
В ордынском государстве живя нельзя булки расслаблять. Конечно, это никого не оправдывает, но удивляться не стоит, Сысоев не первый. И уж точно, не последний.
PS.
Собачье сердце — Взять все, да и поделить
Если можно:
«ICE кандидаты и установка соединения между двумя точками, STUN и TURN сервера»
Пожалуйста.
Ниже скинули ссылку, но там не всё верно.
Спасибо, конечно. Но это описание, по крайней мере в части работы STUN сервера, является неверным. Неверно описан алгоритм работы NAT, в таблице не учитывают адрес и порт STUN сервера. Из-за этого делают неверный вывод:
Что же дальше? Какая от этого всего польза? Польза – это запись в таблице r1_nat. Если теперь кто угодно будет отправлять на роутер r1 пакет с портом 888, то роутер перенаправит этот пакет узлу p1. Таким образом, создался небольшой узкий проход к спрятанному узлу p1.
Там всё сложнее и применять за NAT получится только UDP, потому что stateless. Но подробности были бы интересны. Так что я голосую за:
ICE кандидаты и установка соединения между двумя точками, STUN и TURN сервера
.
Что за реклама из песочницы? Как то работает?
Объясните, пожалуйста, в общих чертах, хотя бы, как через ссылку на ваш сайт я попаду на свой ПК? Особенно, если мой ПК за NAT. Спасибо.
А я вот ждус разблокировки пяти IPV4 из сети 95.217.xx.xx/29.
Судя по всему их Телеграмм использовал. Потом бросил, т.к. в июне РКН их заблокировал, а мне они достались в августе, как часть /29 сетки. Пишу в РКН каждую неделю. Нашёл две точки жалоб:
zapret-info@rkn.gov.ru и
rkn.gov.ru/treatments/ask-question Сайты… — Разблокировка…
Пока всё тихо. Ни ответа ни привета.
Но я надеюсь, правда не очень сильно, что 5 из 8 моих IP адресов "поймут и простят".
Если кто-нибудь может подсказать, куда ещё написать, кроме «Спорт-лото» и «Лиги сексуальных реформ», буду рад помощи.
Был тут на собеседовании в одной, почти такой же большой компании на должность сис. админа. Или как сейчас модно — SRE инженер. Не взяли, к сожалению, но было интересно. А главное, что я понял, растут они быстрее, чем успевают строить грамотную инфраструктуру. Поэтому, затыкают дыры грамотными админами, которые одним взглядом могут починить стойку серверов. При этом всё это, на живую.

Не ошибается, тот, кто ничего не делает. Хорошо это или нет, сложно сказать, не удивлюсь, если в Google, да и везде так же. Хотя в своей книге они пишут красиво. Кто ж в книге правду скажет.

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

Что надёжней? Хороший админ с кучей, не только вашего, оборудования или плохой админ на вашем сервере? ИМХО более менее одинаково, т.к. плохой админ всё сразу вряд ли сотрёт, совсем клинический случай не берём, но будут частые небольшие простои. А при хорошем админе простоев меньше, но уж если случилось, то как в этом случае.
Всё разобрался.
Максимальная частота при нагрузке меняется в зависимости от количества загруженных ядер. При загрузке только одного, действительно, оно должно работать на максимальной частоте TurboBoost. Собственно Intel это так и объясняет:
Max turbo frequency is the maximum single core frequency at which the processor is capable of operating using Intel® Turbo Boost Technology and, if present, Intel® Thermal Velocity Boost. Frequency is measured in gigahertz (GHz), or billion cycles per second.
А вот если подключаются ещё ядра, то максимальная частота TurboBoost должна снижаться. И будет где то между базовой и TurboBoost. Более менее внятный источник этой информации Вот (Upper limit based on active core count).
А насчёт i9-9900k — это исключение, Intel слукавил, он как-бы разогнан. Вот статья про это.
# cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.60 GHz - 3.50 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1.60 GHz and 3.50 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: 3.50 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes
    3300 MHz max turbo 4 active cores
    3400 MHz max turbo 3 active cores
    3500 MHz max turbo 2 active cores
    3500 MHz max turbo 1 active cores
Спасибо, ещё раз.
В федоре29 на ноуте частота, при 100% загрузке всех ядер, ушла даже ниже базовой. Охлаждение ни к чёрту.
Intel:
Какие факторы влияют на работу технологии Intel® Turbo Boost?
Работа технологии зависит от запаса мощности, существующего в одном или нескольких ядрах. Время работы системы в режиме Turbo Boost зависит от рабочей нагрузки, условий эксплуатации и конструкции платформы.

Значит на какой максимальной частоте при 100% загрузке будет работать процессор, зависит от охлаждения… Не знал, спасибо, думал что на базовой, а на деле, от мат. платы, питания, вентиляторов зависит. Я для тестов https://www.mersenne.org/download/ пользую.
Проверил ещё один сервер, там тоже самое при 100% 3.4 вместо базовой 3.3, тут процессор CPU E3-1225 v5 @ 3.30GHz. ОС CentOS7.
И там и там
# cpupower frequency-info | grep driver
  driver: intel_pstate

Ну и при 100% загрузке без дополнительных ограничений процессор должен работать в бусте.

Вот тут не соглашусь, он должен работать как раз на базовой частоте, все ядра загружены на 100%. Но по факту, утилиты показывают нечто среднее, между базовой и турбо буст. Вот это непонятно, от слова совсем. Может баг какой сейчас в Fedora 29 ноут перегружу проверю на нёй.
Офтопик, можно, пожалуйста. Я чего то не понимаю. У меня вот какой результат от разных комманд.
# dmidecode -t processor | grep Speed
        Max Speed: 4000 MHz
        Current Speed: 3100 MHz
# cat /sys/devices/system/cpu/cpu{0,1,2,3}/cpufreq/cpuinfo_cur_freq
3299993
3299993
3299993
3299993
# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz
Stepping:              9
CPU MHz:               3299.993
CPU max MHz:           3500,0000
CPU min MHz:           1600,0000
BogoMIPS:              6185.74
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-3

Все 4 процессора загружены на 100%. Почему «cat /proc/cpuinfo» показывает 3.3 GHz, хотя на мой взгляд должно быть 3.1 GHz — базовая частота cpu. Только dmidecode показывает верно, но почему-то turbo у dmidecode 4 GHz, вместо 3.5. А я им верил. Больше всего интересно почему 3.3 GHz под нагрузкой, вместо 3.1?
Спасибо.
А при чём тут память в однопоточных Geekbench и Himeno? Вы же видите, что в этих тестах, базовая частота повлияла на результаты, а память как раз нет. А в mp3, не зная не разбирался. В принципе, я просто предположил, если вы считаете по другому, хорошо, я не настаиваю. Шайтан машина :)
Однопоточный тест Himeno почти в точности повторяет результаты однопоточного теста Geekbench

Я чего то, не понял. Как раз «буст» и не работат. А почему mp3 подругому? Надо посмотреть.
Я не знаю, что делают эти тесты mp3, Himeno, но может они оба в память упираются, а не в частоту процессора. А память у них одинаковая.
Значит не достаточно быстрый, чтобы технология «буст» повлияла на результаты. Посмотрите на графики, там как раз эти 200 MHz.
Например, я взял однопоточный Geekbench:
6008/3,5*3,3=5665, а у вас в таблице 5739 чуть выше, за счет turbo boost IMHO.
Хоть базовая частота у старшей модели и ниже на 200 MHz, но частота в «бусте» у них одинаковая. Я повторил каждый тест по несколько раз с каждым процессором, чтобы получить ожидаемый мной результат, но достичь его так и не смог :) Очень не люблю делать выводы и заключения, поэтому с удовольствием узнал бы мнения уважаемых читателей: с чем могут быть связаны такие необычные результаты?

Очевидно же, «буст» не работает, на любом более менее длинном временном отрезке с загруженностью 100 процентов, даже на одном ядре. Только на коротких промежутках, рискну предположить, до одной секунды.
В третьем задании так же перемудрил — откуда в потерянном диске, на 7.5GB, две партиции, по 7.5GB — Подумал я. Поэтому, как и у вас, собрал массив, что тоже сработало, вместо raid10 -> raid0:
mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sda2 /dev/sdc2
Тогда не нужно:
$ pvmove /dev/md0 /dev/sdb2
$ vgreduce vg_c6m1 /dev/md0
А нужно поменять, местами диски 1 и 2, чтобы grub стартовал нормально.
Диски при загрузке 2, 1, 3
Что конечно не правильно и усложнило задачу, но не мытьём так катаньем.
Игра мне понравилось. Спасибо.
либо создается лишнее соединение
Исключено т.к. соединение либо создается, либо нет, и такси ищется только один раз. Пока клиент не получит номер такси, он номер заказа не меняет. Только если решил сделать ещё один заказ, установить два соединения.
Клиент заказ N1 -> Сервер подтверждение N1 -> Клиент адрес для N1 -> Сервер (соединение установлено) Ищем такси -> Клиент (соединение установлено) отобразил заказ, номер такси.

Только, если клиент действительно хочет сделать два заказа, клиент работает с двумя номерами заказа. Повторюсь, пока клиент не получит номер такси, он номер заказа не меняет.
Для защиты еще можно ввести команду список заказов, но это, возможно, лишнее. А вот PING заказа на сервере, каждые 1-2 минуты клёвское дело, тем более статус заказа в любом случае мониторить.
А если как в TCP сделать? Интернет работает, никто не жалуется.
Клиент заказ N1 -> Сервер подтверждение N1 -> Клиент адрес для N1 -> Сервер номер такси для N1 -> Клиент отобразил заказ.
Первые два этапа установление соединения, только потом данные или разрыв соединения по таймауту или инициативе клиента, сервера. Клиент может одновременно открыть хоть 1, 2… 10 заказов ничего страшного. Все заказы уникальны, сервер и клиент знают их номера, договариваются на первых двух этапах.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity