Мемори: спасибо! По каналам и переруженности диапазонов... я просто отметаю это так как точка доступа wi-fi на виндовс 7 и точка доступа на андроид смартфоне LG-Sprint в том же самом месте работают без эффектов провалов
Не полностью исключено. Может они на другой канал "договорились"?
Исключить можно только если все происходит в чистом поле.
Эта причина хоть и банальна, но наиболее вероятна.
Канал можно вручную выбирать и наблюдать что происходит, хотя обычно это не рекомендуется.
Как и ручное управление мощностью (уже тоже об этом писали)
Мемори: А вот как бы вы сделали такое буферизацию если бы вам дали задание такое сделать на роутере под юникосм?
(переписать придется видимо, попробовал на вебсокетах из js/html5, вроде значительно лучше, но там конект клиентов идет с участием отдельного сервера, что не всегда хорошо)
Так по прежнему не известно в чем причина.
Не буферизацию надо делать, а повторную доставку при потерях.
Веб-сокеты, кажется слишком громоздко. Если ваше приложение работает с UDP, его можно переделать на TCP не подключая ничего дополнительно.
С устройства (планшет) посылается UDP через wi-fi в роутер и далее по wi-fi на другой планшет или ноут. Частота посылки 20 раз в сек, размер пакета 1 кб. (маленький)
Пакеты пропадают потому что могут. Вариантов много. В городской застройке масса излучающих устройств.
Может это переписать на TCP?
В телефоне, возможно, Wifi более современный и работает либо на другом канале, либо на 5ггц.
saloed, а как долго он не имеет доступа в инет после попытки переключить?
С точки зрения протоколов, понятия VIP не существует. Провайдеры вообще ничего не настраивают чтобы работал этот Virtual IP. Он реализуется в терминах ARP. Соответственно, разбираться надо в рамках ARP и того как маршрутизаторы взаимодействуют с ARP, MAC-адресами и портами.
Если у провайдера какая-то жесткая привязка MAC к портам, очевидно работать не будет. Или, допустим, заработает попозже.
Могу только заявить, что в нормальной сети все нормально работает. Трафик соберите и подумайте.
SeVlad: Те, кто отключил флеш (и мобильные пользователи у которых флеша нет как класса) - они этот маразм не увидят. Те, кто не отключил - сразу закроют сайт.
Чейто? они же не читают Хабр и не станут смотреть код страницы. Они просто видят движущиеся картинки.
Тут все зависит от того, что там движется и насколько назойливо.
treshnyuk: по вашему сотрудникам в ДЦ нечего делать и они ставят все "как можно хуже для клиента" ?
Ну вообще-то да. На практике админ датацентра не представляет задач конкретного сервера. Нужно или все подробнейшим образом расписать или просто попросить KVM или как в Hetzner описывать конфигурации raid и разделов в файле.
спасибо! По каналам и переруженности диапазонов... я просто отметаю это так как точка доступа wi-fi на виндовс 7 и точка доступа на андроид смартфоне LG-Sprint в том же самом месте работают без эффектов провалов
Не полностью исключено. Может они на другой канал "договорились"?
Исключить можно только если все происходит в чистом поле.
Эта причина хоть и банальна, но наиболее вероятна.
Канал можно вручную выбирать и наблюдать что происходит, хотя обычно это не рекомендуется.
Как и ручное управление мощностью (уже тоже об этом писали)
А вот как бы вы сделали такое буферизацию если бы вам дали задание такое сделать на роутере под юникосм?
(переписать придется видимо, попробовал на вебсокетах из js/html5, вроде значительно лучше, но там конект клиентов идет с участием отдельного сервера, что не всегда хорошо)
Так по прежнему не известно в чем причина.
Не буферизацию надо делать, а повторную доставку при потерях.
Веб-сокеты, кажется слишком громоздко. Если ваше приложение работает с UDP, его можно переделать на TCP не подключая ничего дополнительно.
С устройства (планшет) посылается UDP через wi-fi в роутер и далее по wi-fi на другой планшет или ноут. Частота посылки 20 раз в сек, размер пакета 1 кб. (маленький)
Пакеты пропадают потому что могут. Вариантов много. В городской застройке масса излучающих устройств.
Может это переписать на TCP?
В телефоне, возможно, Wifi более современный и работает либо на другом канале, либо на 5ггц.
saloed, в принципе - да . На практике узнавайте у вашего датацентра чем у ваш случай осложняется.
Условия такие, что на интерфейсе eth0 нет реального белого IP. Т.е. там прописан левый Ip который нам не принадлежит, но с нашим шлюзом.
т.е. чужой? да они вас выключат и не будут разбираться.
попробуйте серый 192.168.*
saloed, а как долго он не имеет доступа в инет после попытки переключить?
С точки зрения протоколов, понятия VIP не существует. Провайдеры вообще ничего не настраивают чтобы работал этот Virtual IP. Он реализуется в терминах ARP. Соответственно, разбираться надо в рамках ARP и того как маршрутизаторы взаимодействуют с ARP, MAC-адресами и портами.
Если у провайдера какая-то жесткая привязка MAC к портам, очевидно работать не будет. Или, допустим, заработает попозже.
Могу только заявить, что в нормальной сети все нормально работает. Трафик соберите и подумайте.
Те, кто отключил флеш (и мобильные пользователи у которых флеша нет как класса) - они этот маразм не увидят. Те, кто не отключил - сразу закроют сайт.
Чейто? они же не читают Хабр и не станут смотреть код страницы. Они просто видят движущиеся картинки.
Тут все зависит от того, что там движется и насколько назойливо.
по вашему сотрудникам в ДЦ нечего делать и они ставят все "как можно хуже для клиента" ?
Ну вообще-то да. На практике админ датацентра не представляет задач конкретного сервера. Нужно или все подробнейшим образом расписать или просто попросить KVM или как в Hetzner описывать конфигурации raid и разделов в файле.
baas, купите еще не раз как миленький. Ведь другие еще хуже установят пока вы будете им неделями объяснять в тикетах как вам надо.
Пусть чинят, мы за сервис не фантиками расплачиваемся, а реальным баблом.
зачем? ну просто вас слишком мало чтобы им подробно изучать freebsd.
Радуйтесь тому, что дают.
find /dir/to/find/ -type f -iname "*.php" -mtime -7
... не поможет.
это потому что нужно запускать -ctime