Да, между узлами сети провайдера всё бегает в соответствии со скоростями портов коммутаторов (ну скажем 100 Мбит), и в принципе провайдеру на этот трафик наплевать, но к этому нужно ещё и пачку энтузиастов, которые выставят в сеть подобные сервисы. Впрочем, да, тут за народом не заржавеет, когда у нас была горсеть, там чего только не было доступно без выхода наружу и соответственно тарификации. А для выхода в Инет - VPN-клиент, и QoS следил, чтобы не было проблем.
Но тут есть куча граблей, от которых провайдеру будет сплошная головная боль. Попадётся вот с тобой на домовом коммутаторе перец, который поднял торрент-трекер и имеет неслабое хранилище. И сосут с него в сто потоков разные товарищи. А у тебя в итоге канал в Инет не 10 абы гарантированных мегабит, а дай бог два процента от них. А ты ж за ширину платишь - и вот у провайдера заявка, которую он обязан отработать.. Или ещё хуже - находится в сети малолетний придурок, которому руки чешутся свежескачанный NetBIOS-сканер попробовать, у тебя файрвол взрёвывает, ты жалобу провайдеру, а он опять обязан реагировать.. и таких ситуаций предостаточно. Вот оно провайдеру надо? И если у него задача не организовать и поддерживать горсеть, то он вполне обоснованно переводит все порты в изолированный режим. Он получает деньги за доступ в Инет - вот нахрена ему обеспечивать кого-то за просто так ещё какими-то сервисами?
Основной, и даже единственный, вопрос, на который надо найти ответ - нахрена бы это было надо провайдеру? Лишний геморрой, причём неслабый, и при этом вообще никакого монетизируемого профита.
В общем, я бы сказал, что даже теоретической возможности - и той нет.
То есть если бы вес был 0.234, 0.235 и 0.236 - было бы всё в порядке, выводить не нужно, ибо первое округлится в 0.23, а остальные в 0.24? Похоже на какую-то дурь...
Как по мне, так надо смотреть по разнице qty и LAG(qty,2).
Да переведи ты принтер в приостановленное состояние да с утра посмотри, откуда создано задание... ну что как маленький-то?
Заодно включи (если не включен) расширенный лог, чтобы и станцию, и пользователя, и время определить.
Вот всё одно не могу понять такого упорного цепляния за Memory engine.
Ну в качестве эксперимента всё же переведи таблицу в InnoDB и посмотри, как будет выглядеть процесс. Без всяких там рамдисков для начала, с таблицей на SSD. Думаю, что после тестов необходимость столь глубокой оптимизации, которой тут было запахло, тихо скончается.
Всё же MyISAM/Memory оптимизировано под высокое соотношение чтение/запись.
Всё же переходи на статические таблицы и InnoDB. Memory под капотом - та же MyISAM, и от табличной блокировки тут не убежать от слова "совсем".
С другой стороны, создаётся у меня впечатление, что ты блокируешь таблицу насмерть, пока программа там что-то считает, хотя надо минимизировать время работы с таблицей. Подключился-записал-отключился.
Какой у тебя получается поток запросов? среднее количество в штуках по каждому типу в секунду, плюс по ним же среднее количество записей...
На сколько мне известно, он ее сначала записывает на свой диск
Как правило, это неверно.
Информация с камеры поступает в оперативную память регистратора. Оттуда она и пишется на диск, и передаётся потребителю. Кстати, именно поэтому live video на сервере нельзя поставить на паузу.
100 метров - это предел для сегмента. На 200 метрах придётся отмерить точно середину, и не факт, что она попадёт на то место, где удобно ставить промежуточное оборудование.
Что же до PoE - то из подаваемой в 100-метровый сегмент энергии до другого конца доберётся хорошо если половина. В общем, репитеру будет несладко.
Потому полностью согласен с Андрей Гаврилов - кладите оптику. Для столь короткого сегмента лучше многомод, и минимум 2 волокна. Трансиверы в принципе любые, но рекомендую SNR SNR-SFP+SR (можно получить 10 гигабит, правда, нужны коммутаторы с SFP+ портами).
По какому, интересно знать, признаку?
PS. Запросы 2 и 3 - синтаксически ошибочны.