rPman

разделитель не запятая а ';'

Тебя не смущает что до сих пор не сказал нам что за проект используется и почему не взглянул на его исходники?, Как окружающие должны понимать с чем ты работаешь?

p.s.

скрывались за модификатором доступа private

доступ к private members имеют ваши методы, в вашем классе, порожденном от целевого, это почти не зависит от языка программирования и используют даже там где классов в привычном понимании нет.

p.p.s. по названию свойств могу догадаться (я же почти телепат), что используется llama.cpp, только там я видел выбор mirastat алгоритма как опция
Советую полистать хелп к llama.cpp llama-cli (раньше он назывался main) llama-cli --help там все это есть но чуть чуть названное по другому. Напомню что llama.cpp все еще разрабатывается, документация к нему не всегда понятна а многие вещи приходится вытаскивать из issue и discussion проекта на github и даже из исходников.

p.p.p.s. если лень читать, скопируй этот хелп в запрос llm-ки и добавь вопрос в конец, спросив что то типа

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

upd. я сделаю это за тебя, спросив у бесплатного anthropic

затем по каждому делай запрос отдельно, добавляя что это утилита по inference llm и что может значить соответствующая опция, пример:

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

ВАЖНО: важнейший навык, который может понадобиться в ближайшие годы наверное любому человеку, хоть как то работающему с информацией, и тем более программистам, это умение работать и понимание недостатков современного ИИ, хотя бы на базе chatgpt или других компаний.
Это похоже становится даже важнее чем гуглить (но не вместо, потому что современный ИИ все еще тупит и может напридумывать чуши), поэтому учиться учиться и еще раз учиться.

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

кстати можно наоборот, сначала обнулить функционал, установив чистую прошивку (надеюсь она взята правильная) и по одному, начинаешь добавлять модули magisk или что ты еще с прошивкой делаешь.

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

p.s. и да, вам на 4pda или xdaforums

Нет не опасно, но пользовательский ввод все равно нужно валидровать

Для пространственного арбитража (выравнивание цен между биржами) тебе нужны только ask и bids, т.е. для этого тебе нужны только depth запросы.

Но ни одна крупная биржа не позволит тебе делать достаточно оперативно делать запросы depth стаканов по всем валютным парам (там их сотни даже на мелких биржах), ограничивая количество запросов в секунду.

Но есть потоковые api (в криптоэкономике его реализуют на основе websockets), когда бот подписывается на определенный класс событий (прописывая интересующий список валютных пар в т.ч.) и получает информацию сразу в тот момент, когда она появляется на бирже. К сожалению, в большинстве случаев depth при этом придется восстанавливать на основе периодических (не частых) запросов depth и вручную обновлять их у себя в памяти на основе информации о лимитных ордерах (а так же торговых событиях, потому что некоторые биржи не дублируют информацию об отмене лимитного ордера, если этот ордер был съеден торговой сделкой).

Т.е. только так можно оперативно получать информацию о стаканах, и уже на основе ее делать поиск пересечений bids/asks с разных бирж.

В довесок можно создавать виртуальные торговые пар (кросс-курсы), если к примеру на одной бирже они есть а на другой нет.

Чтобы ускорить процесс, нужно делить его на две части - поиск торговой пары, для которой появилась возможность совершить арбитражную сделку, и вычисление объема, в пределах которого эта сделка может быть исполнена (речь идет о сделках по маркету, когда она совершается на весь объем одномоментно). Первое - достаточно при вычислении depth дополнительно хранить две цены buy и sell, по которой здесь и сейчас можно совершить сделку на минимальный объем сделки, определяемый лимитами биржи, соответственно сравнение проводить только этих чисел. При обнаружении пересечений - вести подсчет предельного объема уже на основе стаканов (если анализ проводить на каждое событие, получаемое по websocket, то алгоритм можно сократить до сравнения одного нового лимитного ордера со стаканами других бирж).

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

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

p.p.s. Возможна комбинация подхода, после оценки динамики ликвидности валютной пары, на бирже удерживается пара лимитных buy/sell с такой ценой, чтобы ее исполнение могло бы позволить получить доход с арбитражной сделкой по маркету на другой бирже, с отслеживанием их частичного или полного исполнения с помощью websocket. в этом случае можно будет пытаться ловить резкие движения, когда рынок на столько резко меняется, что исполняет ордера по достаточно выгодным ценам...

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

Предпологаю что речь идет о веб бакэнде - приложении, запускаемом на веб сервере по запросу из браузера. И главное, предполагаю что используется cgi подход, когда на каждый запрос из браузера запускается отдельный процесс php (даже если это модуль веб сервера, он конечно оптимизируется до асинхронных потоков) но содержимое памяти каждый раз пустое.

Если у тебя mainpage.php и poisk.php это разные запросы, то через глобальные переменные данные между ними не передать.

Нужна какая-нибудь база данных, чем бы она не являлась, например:
* хранить в специальных заголовках запроса - cookies, эти данные как мяч будут автоматически передаваться между клиентом и сервером, т.е. все запросы от клиента будут содержать копию всех установленных cookies, до истечения их времени жизни
* переменные сессии (используются cookies автоматически)
сессия доступна сразу после session_start() а данные через ассоциативный массив $_SESSION (автоматически сохраняется по окончанию скрипта, учти это при параллельных запросах), идентификатор сессии автоматически поддерживается в заголовках запроса (сессия стартует когда пользователь открывает сайт, и единая для других окон, адже после перезапуска браузера, время жизни опция cookie_lifetime)
Очень часто идентификаторы сессии или специально созданное значение в ней используется как идентификатор для поиска данных в других местах (например БД)
* можно использовать файлы, в которых данные хранятся в сериализованном виде, в php штатно работает var_export/eval, serialize/unserialize, json_encode/json_decode - текстовые и бинарный igbinary_serialize/igbinary_unserialize (очень эффективный формат) или свой собственный, по желанию
* можно использовать базу данных, начиная с sqlite (размещается в файле но работа с помощью sql), настоятельно рекомендую PDO - универсальная прослойка для работы с реляционными БД
* есть еще всякие memcache, apcu, или к примеру самописный сервер данных (на сокетах и не только) но применимость - отдельный разговор

p.s. есть иной подход, когда на php пишется полноценный веб сервер, принимающий http запросы (его напрямую редко пускают в интернет, обычно ставят еще какой-нибудь nginx для поддержки ssl и других тонкостей), в этом случае php приложение скорее всего - один инстанс (один процесс), который не завершается по завершению запроса, обрабатывает запросы клиентов асинхронно, в этом случае глобальные переменные будут доступны между запросами.

Скорее всего причина комплексная, комбинация железа и настроек на роутере.

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

Отсюда совет, найди на роутере настройки стандарта подключения и понизь их до 802.11aс. Так же попробуй изменить канал (хотя этот совет из разряда вредных), зафиксировав его принудительно на другом, вполне возможно соседи мешают.

ты забыл настроить права для /var/www/html/
если продолжать твою идею с 777 то нужно:
sudo chmod -R 777 /var/www/html/

Но вернее выдать права не всем, а только пользователю, под которым запускается сервис:

chown -R username:username  /var/www/html/
chmod -R u+rw  /var/www/html/

Очень странно, код у автора выглядит верным.
Точно никаких ошибок выполнения не происходит? Оберни весь код в try catch и выводи exception
у меня есть смутные подозрения - русские имена в пути и наличие в них onedrive, так как включенное облачное хранилище может делать с файлами в каталоге свою магию. Проверь работу с файлом в другом месте

Одно время активно пользовался именно этим способом, потому что нужно было автоматизировать работу с чужими документами с формулами, и за адекватное время и усилия делать все можно было только средствами офиса, и именно так все делали из c# (vbs никто не любил хотя благодаря автозаписи макросов, написание кода часто было еще проще).