Если хочется прям совсем мелкий, с минимальным потреблением, то можно что-то из подобных выбрать. А если нужно помощнее и смотрим на платы с 8гб ОЗУ цену под 80 можно купить уже mini PC на Intel N100, где сразу будет 8 или 16гб ОЗУ, 256-512гб SSD ну и процессор заметно мощнее. Их минус разве что в потреблении энергии, порядка 16ватт под нагрузкой. Но цена и мощность выигрывают
Я летал на 250гц, 100мв. Ттго у меня тоже есть, как раз там ощущение, что битрейт вообще никакой, вся система рассчитана на передачу очень мелких и редких сообщений. А на коптер льется непрерывный поток. Каждый пакет примерно 60бит, на 250гц это 15кбит/секунду, не так уж мало
Она тоже построена на модуляции LORA, есть варианты под 868Мгц и под 2.4. Я лично летал на 2.4ггц на мощности 100мв на 10 километров. Есть данные о дальности в 30+км, в прямой видимости конечно, т.к. коптер/самолёт летит в небе.
Теоретическая дальность связи на 868 и прямой видимости 100+ километров
Я тоже сначала стал думать про точность, но потом поискал исследования с тестами какую точность может услышат человек. Если не путаю, там оказалось, что средний человек не слышит разнцу меньше 20мс. Я сразу расслабился и не стал тратить десятки часов на создание сверх точного метронома. Реализовал за два часа простой механизм и перешёл к следующей задаче :)
Делал именно так, самый простой и самый точный способ. Бесконечный цикл и Thread.Yield(). Не знаю уж что у автора не так с Yield, это очень старая тема и лично для меня всегда работала. В итоге цикл с Yield давал погрешность меньше 1мс. Использовал этот таймер, чтобы играть тики/таки метронома. На слух невозможно услышать ошибку
Например ваш ребенок играет только когда вы разрешили и не может ставить произвольные программы, потому что у него нет прав администратора. С помощью такой дыры и короткой инструкции из интернета он не только сможет выдать себе права администратора, но и заразить компьютер вирусом. Вся суть в том, что ему не нужно ставить программу, достаточно скачать подготовленную другими людьми длл из интернета, положить в нужную папку и перезагрузить систему
Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми
Автор молодец, классная тема. От души советую купить закрытый шлем (мотокроссовый или для даунхилла на велике), а также страховку в несчастных случаев с покрытием хотя бы 1млн.
Эти траты (10 на шлем разово и 10 на страховку раз в год) могут показаться лишними, но мой большой опыт езды на кроссовых мотоциклах говорит, что эти траты окупаются очень быстро и в десятки раз.
В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями
Вот у нас похожие результаты получились. Давно хотим уйти с service fabric на linux и kubernetes, но не можем позволить себе поднять расходы на хостинг так сильно
Может дум что-то и предполагал, но вы наверно забыли какое было низкое качество у мышей того времени. Шарик, который постоянно залипал, надо было его чистить и ролики внутри. Спецаильный маленький коврик, иначе шарик не будет нормально кататься…
Короче играть в динамичную игру с мышками того времени было очень сложно. А когда стало выходить больше игр требующих мышь уже и оптические мышки стали появляться и тогда стало удобно
Я не спорю что можно сделать. Но вы сами согласны, что объем большой. А ещё нужно учесть, что раз в 30 минут не уберёт проблему описанную в статье. Если запустить большую параллельную задачу на pay as you go тарифе без ограничений по ресурсам даже за полчаса легко на много тысяч улететь. Я слышал, что Microsoft поставила цель сделать поминутный биллинг во всём azure, не уверен по срокам, но движение в эту сторону есть и уже есть некоторые сервисы, которые это умеют.
Также у пользователей существует фундаментальное не понимание как работает биллинг, в статье это упоминается "у меня на карте было всего 100$". В контексте, что "как же я мог потратить больше". А вот легко мог, потому что биллить карту даже раз в полчаса это мало реально, поэтому даже в деньгах лимит нужно явно устанавливать руками в сервисе. Иначе к тому времени когда система решить списать с карты, уже будет большой счёт
На сколько я знаю лучше всего дела в этом направлении идут у Амазана, у них на многих сервисах реальная посекундная тарификация.
Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему. Вот у вас есть база данных, которая может обрабатывать 9млн запросов в минуту, как в статье, для одного клиента. Для всех клиентов она наверно 10^11 запросов в минуту обрабатывает, а то и больше. И нужно каждый запрос посчитать, перевести в доллары и обновить счёт у клиента и чтобы не тормозило… Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных. Поэтому они и делают лаг, обновляют биллинг только раз в какой-то интервал, например в сутки. А пользователям рекомендуют следить за метриками и ставить лимиты по метрикам, т.к. метрика не требует особой обработки, это просто число запросов, его можно быстро выкинуть в АПИ и обновлять, а уж юзер сам решит как реагировать на взлёт метрик — например установит лимит.
Опять же в большой компании наверняка есть специальный отдел биллинга, то есть сервис базы данных сам ничего не переводит в деньги, он только отправляет метрики использования в систему биллинга, она там уже внутри в соответствии с тарифами пересчитывает в деньги, выставляет счета, списывает с карт. Это всё занимает время.
Так что на любой облачной платформе легко можно уйти в минус, если моментально создать нагрузку в 1000+ раз больше, чем ваша средняя нагрузка за день, вы просто сгенерируете себе счёт как за 1000 дней типичного использования.
Что странно конечно, это автоматический апгрейд уровня обслуживания. Если у них был бесплатный тарифный план, их должны были затротлить и всё. Вот в этом реальный косяк гугла, наверно поэтому они и не стали требовать оплату, поняли, что в суде проиграют
Проблема в том из какого региона нанимают. Если вы живёте в России и хотите попасть в гугл, вас должны взять на довольно высокую позицию, чтобы имело смысл оплачивать переезд, визу и так далее. Поэтому отбор очень суровый.
Если вы уже живёте в США, есть рабочая виза или гражданство и вы ещё и студент последнего курса, то попасть на стажировку на начальную позицию не составляет особых проблем. Потребность в кадрах на порядок выше предложения, поэтому берут всех подряд
Если хочется прям совсем мелкий, с минимальным потреблением, то можно что-то из подобных выбрать.
можно купить уже mini PC на Intel N100, где сразу будет 8 или 16гб ОЗУ, 256-512гб SSD ну и процессор заметно мощнее. Их минус разве что в потреблении энергии, порядка 16ватт под нагрузкой. Но цена и мощность выигрывают
А если нужно помощнее и смотрим на платы с 8гб ОЗУ цену под 80
Продавец курсов по обучению трейдингу, перелогиньтесь! :)
Я летал на 250гц, 100мв. Ттго у меня тоже есть, как раз там ощущение, что битрейт вообще никакой, вся система рассчитана на передачу очень мелких и редких сообщений. А на коптер льется непрерывный поток. Каждый пакет примерно 60бит, на 250гц это 15кбит/секунду, не так уж мало
Вот система радиоуправления для квадрокоптеров https://www.expresslrs.org/2.0/
Она тоже построена на модуляции LORA, есть варианты под 868Мгц и под 2.4. Я лично летал на 2.4ггц на мощности 100мв на 10 километров. Есть данные о дальности в 30+км, в прямой видимости конечно, т.к. коптер/самолёт летит в небе.
Теоретическая дальность связи на 868 и прямой видимости 100+ километров
Я тоже сначала стал думать про точность, но потом поискал исследования с тестами какую точность может услышат человек. Если не путаю, там оказалось, что средний человек не слышит разнцу меньше 20мс. Я сразу расслабился и не стал тратить десятки часов на создание сверх точного метронома. Реализовал за два часа простой механизм и перешёл к следующей задаче :)
Вот такой код не жрёт CPU
Позже по аналогичному принципу код был портирован на JS для работы в браузере.
while(true) {
if (ещё рано) setTimeout(сам_себя, 0)
}
и тоже нормально игралось и не было какой-то космической нагрузки
Делал именно так, самый простой и самый точный способ. Бесконечный цикл и Thread.Yield(). Не знаю уж что у автора не так с Yield, это очень старая тема и лично для меня всегда работала. В итоге цикл с Yield давал погрешность меньше 1мс. Использовал этот таймер, чтобы играть тики/таки метронома. На слух невозможно услышать ошибку
Не Гб, а мб и объем диска визитки был 60мб. Даже был специальный дистрибутив livecd Линукса, который влезал в 60мб
Например ваш ребенок играет только когда вы разрешили и не может ставить произвольные программы, потому что у него нет прав администратора. С помощью такой дыры и короткой инструкции из интернета он не только сможет выдать себе права администратора, но и заразить компьютер вирусом. Вся суть в том, что ему не нужно ставить программу, достаточно скачать подготовленную другими людьми длл из интернета, положить в нужную папку и перезагрузить систему
Amazon, как и другие облачные сервисы оптимизирован для больших клиентов, у которых траты в месяц тысячи долларов. Мелкие разработчики, с бюджетами в 10$ в месяц не дают никакой значительной прибыли. Не надо облака сравнивать с мобильными донат играми
На сколько я знаю, работа в этом направлении идёт и уже есть сервисы с поминутным биллингом
Автор молодец, классная тема. От души советую купить закрытый шлем (мотокроссовый или для даунхилла на велике), а также страховку в несчастных случаев с покрытием хотя бы 1млн.
Эти траты (10 на шлем разово и 10 на страховку раз в год) могут показаться лишними, но мой большой опыт езды на кроссовых мотоциклах говорит, что эти траты окупаются очень быстро и в десятки раз.
В очередной раз обсасывается эта тема. Да, если настроить неограниченное масштабирование можно попасть на деньги. Но даже в статье написана правда: практически невозможно сделать биллинг в реальном времени.
Вот у вас один маленький аккаунт S3, который стоит положим 0.001 цента за операцию и ваше маленькое приложение делает всего 100 операций в минуту. Это значит, что только для вашего приложения Амазон должен 100 раз в минуту сделать запись в базу биллинга, пересчитать сколько вы потратили и проверить ваши лимиты. То есть автоматом, ваш аккаунт начинает работать в среднем в два раза медленее (ведь надо и в аккаунт записать и в биллинг) и так во всех сервисах.
А теперь прикинем, что есть премиум аккаунты, которые должны уметь выдавать 100к операций в секунду. Физически невозможно, чтобы такие аккаунты выдавали метрику по цене на каждый запрос и чтобы эта метрика в реальном времени проверялась против лимита расходов.
Не знаю как в AWS, Azure для всех автомасштабирований требует указать лимит в единицах измерения сервиса. То есть для виртуальной машины в количестве ядер, для базы данных в гигабайтах и так далее. Может показаться, что это не столь удобно как в деньгах. Но это недоубно, только если вы пришли первый раз и хотите просто поиграться и сами не особо понимаете чего конкретно хотите. Если же вы создаёте даже маленькое, но приложение с конкретной целью, то вы более или менее представляете какие ресурсы будут нужны вашему приложению и наоборот удобнее указать лимиты в ресурсах. Azure вам сразу покажет сколько это примерно будет стоить в деньгах и будет списывать эту сумму равномерными долями
Мы даже не дошли до тестов kubernetes, потому что kestrel в докере уже показывает заметно худший результат на линуксе
Вот у нас похожие результаты получились. Давно хотим уйти с service fabric на linux и kubernetes, но не можем позволить себе поднять расходы на хостинг так сильно
Может дум что-то и предполагал, но вы наверно забыли какое было низкое качество у мышей того времени. Шарик, который постоянно залипал, надо было его чистить и ролики внутри. Спецаильный маленький коврик, иначе шарик не будет нормально кататься…
Короче играть в динамичную игру с мышками того времени было очень сложно. А когда стало выходить больше игр требующих мышь уже и оптические мышки стали появляться и тогда стало удобно
Я не спорю что можно сделать. Но вы сами согласны, что объем большой. А ещё нужно учесть, что раз в 30 минут не уберёт проблему описанную в статье. Если запустить большую параллельную задачу на pay as you go тарифе без ограничений по ресурсам даже за полчаса легко на много тысяч улететь. Я слышал, что Microsoft поставила цель сделать поминутный биллинг во всём azure, не уверен по срокам, но движение в эту сторону есть и уже есть некоторые сервисы, которые это умеют.
Также у пользователей существует фундаментальное не понимание как работает биллинг, в статье это упоминается "у меня на карте было всего 100$". В контексте, что "как же я мог потратить больше". А вот легко мог, потому что биллить карту даже раз в полчаса это мало реально, поэтому даже в деньгах лимит нужно явно устанавливать руками в сервисе. Иначе к тому времени когда система решить списать с карты, уже будет большой счёт
На сколько я знаю лучше всего дела в этом направлении идут у Амазана, у них на многих сервисах реальная посекундная тарификация.
Вообще сделать даже поминутную тарификацию очень сложно и это проблема не одного гугла. Просто попробуйте спроектировать такую систему. Вот у вас есть база данных, которая может обрабатывать 9млн запросов в минуту, как в статье, для одного клиента. Для всех клиентов она наверно 10^11 запросов в минуту обрабатывает, а то и больше. И нужно каждый запрос посчитать, перевести в доллары и обновить счёт у клиента и чтобы не тормозило… Это колоссальная задача, по ресурсам сравнимая с работой самой базы данных. Поэтому они и делают лаг, обновляют биллинг только раз в какой-то интервал, например в сутки. А пользователям рекомендуют следить за метриками и ставить лимиты по метрикам, т.к. метрика не требует особой обработки, это просто число запросов, его можно быстро выкинуть в АПИ и обновлять, а уж юзер сам решит как реагировать на взлёт метрик — например установит лимит.
Опять же в большой компании наверняка есть специальный отдел биллинга, то есть сервис базы данных сам ничего не переводит в деньги, он только отправляет метрики использования в систему биллинга, она там уже внутри в соответствии с тарифами пересчитывает в деньги, выставляет счета, списывает с карт. Это всё занимает время.
Так что на любой облачной платформе легко можно уйти в минус, если моментально создать нагрузку в 1000+ раз больше, чем ваша средняя нагрузка за день, вы просто сгенерируете себе счёт как за 1000 дней типичного использования.
Что странно конечно, это автоматический апгрейд уровня обслуживания. Если у них был бесплатный тарифный план, их должны были затротлить и всё. Вот в этом реальный косяк гугла, наверно поэтому они и не стали требовать оплату, поняли, что в суде проиграют
Проблема в том из какого региона нанимают. Если вы живёте в России и хотите попасть в гугл, вас должны взять на довольно высокую позицию, чтобы имело смысл оплачивать переезд, визу и так далее. Поэтому отбор очень суровый.
Если вы уже живёте в США, есть рабочая виза или гражданство и вы ещё и студент последнего курса, то попасть на стажировку на начальную позицию не составляет особых проблем. Потребность в кадрах на порядок выше предложения, поэтому берут всех подряд