alexalexes

Выводить с заданной точностью:
printf("%.1f", c);

Из более-менее новых карт, и народных по распространенности - 1660 можно без super.
Можно с ali, но осторожно.
Все остальные более ранние карты - уже музейные экспонаты, или уже доживают свой ресурс.

Есть к примеру airodump-ng но не отображается имя сети и нет графика который бы показывал мощность сигнала во времени.

ESSID - же? Если имени сети нет, то оно скрыто настройками точки доступа и в трафике вы его не увидите. Если свою точку анализируете, то вы легко определите BSSID и ни с чем его не спутаете.
График? А зачем вам рюшечки? Статистика и так собирается в реальном времени и обновляется в консоли - этого достаточно.
Чтобы сделать более активный сбор статистики, то заставьте работать свою точку более активно. Включите, например, youtube, на другом устройстве, которое тоже подключено к вашей точки доступа, и точка доступа будет активно обмениваться пакетами и в мониторинге это будет видно.

У true программистов всегда было много вопросов к switch (как в свое время к go to). Поэтому в любой непонятной ситуации используйте цепочку if else, так вы будите ближе к строгим стандартам.

if(a > b) {
  alert(a + b)
} else if(a < b) {
    alert('Lorem Ipsum terebismum')
} else {
    alert('Isn"nt number')
}

Нужно подкидывать матрицу где-нибудь у ремонтников, и настраивать переключение мониторов.
Если никто не заморачивался с корректной установкой видео драйверов и Fn менеджера, то редко бывает так, что будет работать переключение, просто подключив кабель.

Потому что, это Lite. У локальных СУБД должно быть минимум функционала и максимум переносимость в любую среду разработки.

Гуглите border-radius.
1. border-radius делаете >= 50% и у вас получается круг.
2. Закругление можно делать по отдельным сторонам блока.

выдает только фон

$image = imagecreatefromjpeg('/banner/png');
Символ около расширения файла не смущает? И расширение png для метода *jpeg?
PS: если вы var_dump-ните $image, то обнаружите false - значит, что-то с путем к файлу или его отсутствие.

В цепочке Телефон -> ПК интерфейс usb будет беспокоить в последнюю очередь в плане надежности и скорости.
Чтобы начать беспокоиться насчет usb, вам нужно гонять трафик не менее 1 Гбит/с или иметь отклик не более 1 мс.
Либо если у вас между телефоном и ПК более 5 метра провода.

Очень принципиально по производительности имеет значение количество атрибутов в строке выборки, и есть ли там бинарные типы данных или длинные строки - это именно то, что будет просаживать производительность при попытке сделать большую выборку.
Если в реальной системе из этой таблицы выбираются сначала "легкие" атрибуты в тысячи записей, а потом по конкретным записям дозапрашиваются "тяжелые" атрибуты (бинарные данные, длинные строки).
То синтетический тест:
SELECT * FROM articles LIMIT 1000
к реальной жизни не будет иметь никакого отношения, потому, что вы выбираете все атрибуты (*), при наличии "тяжелых" атрибутов, в здравом уме никто не будет делать такие большие выборки. Разве что, если это не импорт/экспорт - но это сам по себе процесс затяжной.

Если нет особых требований, то пока удобно создать такие таблицы:

Таблица "План накопления статистики"
id - идент. плана
begin_date - дата/время начала сбора статистики
end_date - дата/время окончания сбора статистики
name - название плана
description - описание плана
interval - интервал накопления статистики в секундах
... - другие параметры плана

Таблица "Точка фиксации показателей"
id - идент. точки
plan_id - инд. плана накопления статистики
begin_date - дата/время начала сбора данных для точки фиксации
end_date - дата/время окончания сбора данных для точки фиксации

Таблица "Агрегированные показатели точки фиксации"
id - идент. показателя
Name - название показателя
measure_id - инд. единицы измерения показателя (тоже нужна таблица справочник: байты, биты, байт/с, Ватт, Кг и т.д.)

Таблица "Значения агрегированных показателей точки фиксации"
id - идент. значения показателя
point_id - идент. точки фиксации
param_id - идент. показателя
value_int - значение показателя в целых числах
value_flt - значение в вещественных числах
value_str - значение в строковом представлении
value_... - если нужен еще какой-то тип данных, которых можно индексировать.

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

Если не вдаваться в категории, то простым языком это выглядит так:

Если нужно только 100Мбит/с, то подойдет любой попавшийся кабель (можно сэкономить и взять тонкий кабель с 2 парами).
до 1Гбит/с - кабель должен содержать 4 пары, остальные характеристики не важны.
до 2,5Гбит/с или 10 Гбит/с - 4 пары, плюс металлизированная изоляция коннектора и кабеля, длина кабеля не может превышать 40 метров.

Но для это подойдет для поиска одного размера, а мне прилетает несколько. Не ужели скажем если 10 размеров прилетит, писать 10 запросов для проверки каждого размера?

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

select * from table
where 1 = 1 -- чтобы можно было однотипно подставить выражения с and или or, не заморачиваясь в каких случаях нужен and/or, а в каких нет.
or find_in_set('L', replace(value, ';', ','))
or find_in_set('XL', replace(value, ';', ','))
...
or find_in_set('XXXL', replace(value, ';', ','))

Вам нужно проработать архитектуру таблиц.
Чтобы удобно хранить свойства ads и serp в одной таблице, которые представленные в виде массива. Вам нужно не только выделить тип записи - ads или serp, но нужно как-то связать все записи, которые входят в одно событие свойства p1.
Допустим, для событий мы создаем таблицу Event со свойствами:
Event_Id - код события,
info - строка или JSON-тип,
success - число,
query - строка или JSON-тип,
total_count - число
...
Не все свойства p1 перечисляю, так как, например, paa - тоже массив, и нужно понять, будете ли под него выделять отдельную таблицу или приспособите какую-нибудь существующую, добавив новый тип - paa.
-----
А для хранения элементов массивов ads, serp (и, возможно еще каких-либо свойств-массивов, которые появятся непосредственно в p1 не во вложенных свойствах) вы создадите отдельную таблицу event_prop_array:
prop_arr_Id - код элемента свойства события
prop_id - тип свойства из таблицы-справочника типов свойств (внешний ключ)
event_id - событие, к которому относится запись, внешний ключ к таблице event
link - строка
snippet - строка
...
дальше идут другие скалярные свойства, которые можно найти в одном элементе ads или serp
------
Добавляем таблицу справочник, чтобы закодировать внешний ключ prop_id
Таблица event_prop
prop_id - код свойства
prop_name - имя свойства
----------------------------
Теперь, чтобы залогировать один элемент p1 нужно сделать так:
1. Вставить в таблицу event запись из простых свойств (info, success, query, total_count, ... )
2. Получить event_id вставленной записи (гуглите last_insert_id для PDO или дополнительную клаузу для insert - "returning event_id into :event_id", если вы используете, например, oracle, а не mySQL)
3. Получить prop_id из справочника (тут обычный select)
4. В цикле вставляете записи в таблицу event_prop_array, используя известные event_id, prop_id и текущие свойства элемента ads.
5. Тоже самое как 4, но используете свойства serp.
-------------------
Когда сформируете лог в базе, то типичный запрос для выборки чего-либо будет иметь вид:

select e.*, ep.*, epa.*
from event_prop_array epa
join event_prop ep on ep.prop_id = epa.prop_id
join event e on e.event_id = epa.event_id
-- какие-то условия для поиска
where e.event_id = 1
 and ep.prop_name = 'ads'