Пришлось слегка попотеть, надеюсь она вам правда была нужна и вы не поверили мне на слово, не прогуглили сами.
Litepoint один из производителей чипов, в том числе блютус www.litepoint.com/whitepaper/Bluetooth%20Low%20Energy_WhitePaper.pdf
Страница 3.
peak — десятки mA, idle — десятки nA
В качестве примера на странице 4 — пик 12.5 mA, порядка 12микро ампер за секунду передачи. Возьмем за эталон, хорошо?
Страница 5. Передачи на скорости 1mbit 8-27 октетов. Думаю имеется в виду передача данных, включая служебных, протокола bluetooth. Заметим и учтем что чип применяет AES.
Рассмотрим паке(8 стр) — 8 октет служебных данных и кадр 2-37 октета. (Причем 2 байта — заголовок)
Т.е 10 байт это минимальный overheat, причем его достаточно для поддержания соединения.
Страница 12 — картинка. Такую нагрузку дают стеки. В данном случае запрос ARP.
C блютус покончили, езернет(ваш пинг) en.wikipedia.org/wiki/Ethernet_frame
В вашу пользу начальные и конечные данные я отброшу, наверняка их нет в итоге — блютус же давал начало фрейма.
6+6 маки, 2 тип запроса, CRC 4 байта. Причем скорее всего не отброшено, что бы считаться корректно для этой части.
— Что мы получаем
Пусть для bluetooth-keepalive будет проверка каждые 10 секунд(Sniff-subtracking). Получается в минуту 60 байт для передачи.
ping ethernet over bluetooth каждую минуту(однократный) это — 10+18 байт в одну сторону. Т.е 56 байт.
===Т.е для вашей ситуации передача выгоднее
Давайте решим задачку(О которой спор, и я оговорился там, 8 минут передачи менее эффективно). 8 часов пассивного соединения это 28.125 kb, на скорости 0.3Mbps(ухудшим ситуацию) это 65.918ms передачи данных.
С этим ок. По вашей ситуации:
В день вы передаете 61.523ms, что согласно приведенной таблице — 0.8 миллиампер в день на передачу, плюс шифрование (AES процессора), плюс операционка возбудится что ее пингуют. вобщем я оцениваю в 100mA расходы максимум(cpu, ram, шина бла бла). В моем же методе дальше чипа информация не проходит, а значит тратится в районе 1mA.
Итог
Я распинался больше двух часов что бы доказать кому то в интернете что он не прав что ваши ежеминутные расходы на пинг того же порядка что и расходы на keepalive. Но любой запрос выше протокола обслуживаемого чипом требует ответа котроллера шины, прерывания МК и вероятно просыпания ОС. Все это ведет дополнительные расходы, которые в лучшем случае удвоят потребление, в худшем приведут его к бесконечности.
Мы маленькая команда, и новички у нас появляются очень редко. Ваше замечание обосновнанно.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Это просто глупо.
Все компьютеры считают примерно одинаково. Но это до сих пор создает множество проблем для написания аппаратно-независимого кода.
Я лучше лишний раз прокомпилирую данные исходя из своих особенностей, чем запущу жрущую ява-машину.
Такие кнопки появились на нескольких сайтах и пользуются популярностью(на этих сайтах).
Значит это кому то нужно. Зачем еще какие то уточнения вопроса?
Зачем наверх — пишу пост в хабре, и решил прочитать что то.
Это похоже на игру «а зачем вам это» — «а затем».
Скролл гугла это 3-4 движения. И вообще мне этот спор наскучил. Скажите, что вы пытаетесь доказать?
Что мне такая кнопка не нужна? Не докажите. У меня она прижилась.
И опять же, ради любопытства прошу аргументировать минусы.
Вопрос «зачем вам что то нужно наверху» выходит за рамки спора, и я не отвечал на него без явного уточнения, о чем и сообщил.
С чем связаны минусы?
Раз за разом меня поражает непонимание.
Litepoint один из производителей чипов, в том числе блютус
www.litepoint.com/whitepaper/Bluetooth%20Low%20Energy_WhitePaper.pdf
Страница 3.
peak — десятки mA, idle — десятки nA
В качестве примера на странице 4 — пик 12.5 mA, порядка 12микро ампер за секунду передачи. Возьмем за эталон, хорошо?
Страница 5. Передачи на скорости 1mbit 8-27 октетов. Думаю имеется в виду передача данных, включая служебных, протокола bluetooth. Заметим и учтем что чип применяет AES.
Рассмотрим паке(8 стр) — 8 октет служебных данных и кадр 2-37 октета. (Причем 2 байта — заголовок)
Т.е 10 байт это минимальный overheat, причем его достаточно для поддержания соединения.
Страница 12 — картинка. Такую нагрузку дают стеки. В данном случае запрос ARP.
C блютус покончили, езернет(ваш пинг)
en.wikipedia.org/wiki/Ethernet_frame
В вашу пользу начальные и конечные данные я отброшу, наверняка их нет в итоге — блютус же давал начало фрейма.
6+6 маки, 2 тип запроса, CRC 4 байта. Причем скорее всего не отброшено, что бы считаться корректно для этой части.
— Что мы получаем
Пусть для bluetooth-keepalive будет проверка каждые 10 секунд(Sniff-subtracking). Получается в минуту 60 байт для передачи.
ping ethernet over bluetooth каждую минуту(однократный) это — 10+18 байт в одну сторону. Т.е 56 байт.
===Т.е для вашей ситуации передача выгоднее
Давайте решим задачку(О которой спор, и я оговорился там, 8 минут передачи менее эффективно). 8 часов пассивного соединения это 28.125 kb, на скорости 0.3Mbps(ухудшим ситуацию) это 65.918ms передачи данных.
С этим ок. По вашей ситуации:
В день вы передаете 61.523ms, что согласно приведенной таблице — 0.8 миллиампер в день на передачу, плюс шифрование (AES процессора), плюс операционка возбудится что ее пингуют. вобщем я оцениваю в 100mA расходы максимум(cpu, ram, шина бла бла). В моем же методе дальше чипа информация не проходит, а значит тратится в районе 1mA.
Итог
Я распинался больше двух часов что бы доказать
кому то в интернете что он не правчто ваши ежеминутные расходы на пинг того же порядка что и расходы на keepalive. Но любой запрос выше протокола обслуживаемого чипом требует ответа котроллера шины, прерывания МК и вероятно просыпания ОС. Все это ведет дополнительные расходы, которые в лучшем случае удвоят потребление, в худшем приведут его к бесконечности.P.S нас рассудит эксперимент
В случае обрыва — попытка подключения, иначе блокировка.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Все компьютеры считают примерно одинаково. Но это до сих пор создает множество проблем для написания аппаратно-независимого кода.
Я лучше лишний раз прокомпилирую данные исходя из своих особенностей, чем запущу жрущую ява-машину.
Значит это кому то нужно. Зачем еще какие то уточнения вопроса?
Зачем наверх — пишу пост в хабре, и решил прочитать что то.
Это похоже на игру «а зачем вам это» — «а затем».
Скролл гугла это 3-4 движения. И вообще мне этот спор наскучил. Скажите, что вы пытаетесь доказать?
Что мне такая кнопка не нужна? Не докажите. У меня она прижилась.
Вопрос «зачем вам что то нужно наверху» выходит за рамки спора, и я не отвечал на него без явного уточнения, о чем и сообщил.
С чем связаны минусы?
Раз за разом меня поражает непонимание.
С помощью Home нельзя вернуться на то место какое читал.(т.е наверх, а потом обратно)
историю TF2к чему это приведет.В примере с гуглом я иногда ощущаю необходимость проверить почту.
В любом случае я чувствовал дискомфорт читая форумы(профиль, навигация) и мембрану(меню).
На сайтах где фокус по умолчанию отдается input полю (google к примеру) — не работает.
Экран у меня не сенсорный, но для успокоения совести коснулся.
Кстати кнопку не убрали. Появилась возможность убрать. У меня она стоит.
Нам как команде это удобно, решил поделиться с «миром».