rPman

в триггеры добавь условие - включение компьютера

Ответ на этот вопрос можно получить либо экспериментально либо изучив серверную реализацию (в конечном счете тоже экспериментально).

У тебя 2 основных узких 'горла' - скорость подготовки ответа сервером (процессор и диск) и скорость сетевого соединения до него... ну а медленный клиент можно распараллелить несколькими машинами (и соответственно провайдерами если проблема в сети на стороне клиента).

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

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

Ну и вишенка на торте, транспортный уровень может внести корректировки, полистай статью

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

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

Ну и нагрузка на процессор, если реализация однопоточная (асинхронная реализация сильно усложнит подсчет) то скорость ответа будет линейно зависеть от времени обработки одного и нагрузки на процессор (проще замерить сколько клиентов дадут 100% нагрузку). Но вот многопоточные реализации могут давать неожиданные ухудшения характеристики, т.е. 10 потоков могут не дать 10-кратное увеличение скорости, и с величением потоков будет много ресурсов уходить на поддержание этой работы (кажется теория вообще говорит о квадратном корне из количества потоков), и это еще про кеш процессора речи не идет, так как в зависимости от того, влезает ли алгоритм обработки (нужная ему память) в него или нет тоже можно получить кучу странностей, например 1-2 потока будут давать быструю скорость, но добавив третий, даже не нагрузив весь процессор, можно получить значительное понижение производительности, так как данные трех потоков не влезают в кеш. Кстати оперативная память хоть и называется Random Access memory но может давать разную производительность в зависимости от характера нагрузки (особенно это видно по вычислениям на GPU) что тоже не лучшим образом влияет на многопоточный результат.

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

для начала запустить проверку диска с исправлением ошибок (в свойствах диска в проводнике - обслуживание) для системног диска оно предложит перезагрузиться

дальше, существуют имена, которые windows обработать не может, это зарезервированные слова типа com lpt prn и т.п. их создать не просто но реально, и штатные утилиты работать с ними не смогут

p.s. rmdir /s/q имя_каталога
у меня удаляло обычно все максимально быстро (/s/q это без запросов и с подкаталогами)

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

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

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

Первое что нагуглил это для VB# но разницы нет никакой

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

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

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

Кстати в биос майнеры могут зашить нестандартные параметры, сравнивать это с официальными данными по модели
upd. погуглила бы хоть
если продавец - магазин, то ты можешь вернуть карту в этот же день если заметишь что она БУ (по уму у тебя 10 дней на это есть но меньше будет проблем если в тот же день вернешь)

шлешь в бесконечном цикле паузу и запрос
SHOW FULL PROCESSLIST;
сохраняешь список идентификаторов для проверки а следующем шаге, проверка - если какой то id остался с прошлой проверки - считать этот запрос медленным, интервал (длина пауза) между запросами - пороговый интервал для определения что такое 'медленный'

upd. можешь добавить к идентификатору содержимое info, как то поможет, чтобы хоть немного обойти замечание акина

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

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

да найсхеш будет выплачивать после определенного порога и это логично, ваша транзакция ему может стоить от 50 центов до десятков баксов на участника (чтобы оптимизировать их будут объединять в несколько но на каждого все равно получатся заметно)

Не понимаю, зачем тебе посредник между nicehash и тобой в виде awesome miner, абсолютно все необходимое есть у самого nicehash

p.s. мало того в прошлом году они говорили о снижении порога вывода через сеть лайтинг, т.е. ты один раз открываешь канал с ними а затем получаешь выплаты (правда для открытия канала нужно минимум 0.005btc но это не плата а заморозка на время жизни канал, формально ты можешь большую часть этой суммы вывести через какой-нибудь шлюз лайтинг-btc и канал останется открытым с перекосом баланса в сторону пула но ты же майнишь)

и сказано что в человеко-читаемом формате это (08.11.1965)

кто тебе это сказал? в смысле что за приложение?
unix time определен как количество секунд с 01.01.1970 года, и про отрицательное их количество речи не идет

для определения времени до этого события нужно использовать другие стандарты

Удивительно, что нужно сделать с windows чтобы в php номера форматировались под настройки локали (в русской там запятая стоит, но я точно помню даже со времен winxp в официальных сборках php там возвращались точки, собственно я сейчас порыл коментарии под setlocale и там твоя проблема подтверждается)
Наверное setlocale похоже не отрабатывает корректно, покажи вывод после setlocale - localeconv, точнее что там в decimal_point будет

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

Либо использовать number_format чтобы фиксировать свой десятичный символ вне зависимости от локалей

может в некоторых крайних случаях работать чуть медленее

не могу представить ситуацию когда один индекс и список объектов будет медленнее нескольких для каждого поля.
подскажи в каких

локальная sql база данных - это sqlite

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

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

для 'отлично' я предлагаю написать функцию, которая будет заметно эффективнее и вместо N умножений будет делать примерно log(N)
для этого попытаться представить возведение в степень не как N раз X*X*...*X а как (N/2 раз X*X*..*X)^2, а чтобы это делать в цикле, поступить так, если N четное, то делим его на два, вызываем рекурсивно свою же функцию и результат умнажаем на самого себя, иначе берем N-1 и делаем тоже самое но результат дополнительно умножаем на X

p.s. полгаю если сумеешь заменить рекурсию на цикл, будет однозначно плюсищем

твоя прокси умеет работать только с http, а https сайты с ней не работают (запрос подвисает в бесконечный таймаут)
CURLOPT_SSL_VERIFYPEER, false
вот такие выкрутасы на анонимных проксях могут прокатить, так как прокси атакуют Man-in-the-middle, подменяя на невалидный сертификат, т.е. у тебя утекут либо логины пароли либо куки либо еще какая то критичная информация, а еще прокси могут подменять трафик, в лайтовом виде - подмена рекламного идентификатора и просто реклама, а в хардкоре... любые финансовые сервисы станут уязвимы

Лучший открытый проект по работе с распознаванием и синтезом речи - mozilla deepspeach и он закрыт (логично, гугл перестал финансировать мозиллу)
можно взять его, взять публичные или свои базы и обучить, на хабре были статьи где этим занимались (т.е. не только распознавание языка но и в принципе распознавание речи)

p.s. у гугла есть android (физическое железо, эмулятор кажется не подойдет) проприетарные библиотеки и наборы данных для распознавания, позволяющие делать это оффлайн для кучи языков, но на сколько я знаю лицензию на их использования они не раздают, но я слышал что народ как то приспосабливали эти библиотеки самостоятельно... процесс не простой, с каждым обновлением формат их использования будет меняться. Так же я слышал о попытках использования готового гугловского приложения google translate на android, с настройками на оффлайн распознавание (симулируя поведение человека и считывая содержимое экрана с помощью приложений на основе технологий для людей с ограниченными возможностями), можно что то сделать... наверняка там будет тьма подводных камней, так как гугл будет с этим бороться

p.p.s. до 4-ой версии android доступ к распознаванию речи как я понимаю был официальный