История изменений
Исправление AEP, (текущая версия) :
Вот что у меня было, пока я не выбросил CAKE-autorate из-за низкого доверия к bash-скиллам автора и наличия соавтора, дающего советы, с которыми я не согласен. Заточено на очень плохой сигнал в пригороде (а по российским меркам это сельская местность), RSRP = -119 dBm (это с внешней антенной), SINR = -3 dB, RSRQ = -12 dB. Вечером, если идет дождь, скорость просаживается до 400 kbit/s или еще меньше. Снижение порога задержки ниже 500 мс приводит к многочисленным ложным срабатываниям, но в основном она держится в пределах 100 мс. Без SQM под нагрузкой ping растет до нескольких секунд.
dl_if=ifb4wwan0 # download interface, created by sqm-scripts
ul_if=wwan0 # upload interface
delay_thr_ms=500
min_dl_shaper_rate_kbps=100
base_dl_shaper_rate_kbps=500
max_dl_shaper_rate_kbps=20000
min_ul_shaper_rate_kbps=100
base_ul_shaper_rate_kbps=500
max_ul_shaper_rate_kbps=20000
connection_active_thr_kbps=100
startup_wait_s=5
monitor_achieved_rates_interval_ms=1000
shaper_rate_adjust_up_load_high=1.05
shaper_rate_adjust_down_load_low=1.0
shaper_rate_adjust_up_load_low=1.0
bufferbloat_refractory_period_ms=5000
reflector_health_check_interval_s=10
reflector_response_deadline_s=5
Еще у меня была дискуссия с автором по поводу более быстрого восстановления после радиопомех. Я предлагал считать, что фактическое получение данных с определенной скоростью является неопровержимым доказательством того, что канал связи способен на это. Как оказалось, для DSL это не так - модем может переспрашивать испорченные фреймы и буферизовать то, что пришло до ответа на перезапрос, а потом быстро отдать набуферизованное. Поэтому предложение не приняли.
Форум конкретно по CAKE-autorate тут: https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379
Поскольку это резервный канал, я на просадку скорости по сравнению с теоретически достижимой забил и просто сконфигурировал SQM статически на «терпимый» уровень. Да, вечером в дождь получается bufferbloat.
config queue 'wwan0'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option itarget 'auto'
option etarget 'auto'
option linklayer 'none'
option enabled '1'
option interface 'wwan0'
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option qdisc_really_really_advanced '1'
option eqdisc_opts 'nat dual-srchost'
option download '2000'
option upload '500'
option iqdisc_opts 'nat dual-dsthost ingress'
Исправление AEP, :
Вот что у меня было, пока я не выбросил CAKE-autorate из-за низкого доверия к bash-скиллам автора и наличия соавтора, дающего советы, с которыми я не согласен. Заточено на очень плохой сигнал в пригороде (а по российским меркам это сельская местность), RSRP = -119 dBm (это с внешней антенной), SINR = -3 dB, RSRQ = -12 dB. Вечером, если идет дождь, скорость просаживается до 400 kbit/s или еще меньше. Снижение порога задержки ниже 500 мс приводит к многочисленным ложным срабатываниям, но в основном она держится в пределах 100 мс. Без SQM под нагрузкой ping растет до нескольких секунд.
dl_if=ifb4wwan0 # download interface, created by sqm-scripts
ul_if=wwan0 # upload interface
delay_thr_ms=500
min_dl_shaper_rate_kbps=100
base_dl_shaper_rate_kbps=500
max_dl_shaper_rate_kbps=20000
min_ul_shaper_rate_kbps=100
base_ul_shaper_rate_kbps=500
max_ul_shaper_rate_kbps=20000
connection_active_thr_kbps=100
startup_wait_s=5
monitor_achieved_rates_interval_ms=1000
shaper_rate_adjust_up_load_high=1.05
shaper_rate_adjust_down_load_low=1.0
shaper_rate_adjust_up_load_low=1.0
bufferbloat_refractory_period_ms=5000
reflector_health_check_interval_s=10
reflector_response_deadline_s=5
Еще у меня была дискуссия с автором по поводу более быстрого восстановления после радиопомех. Я предлагал считать, что фактическое получение данных с определенной скоростью является неопровержимым доказательством того, что канал связи способен на это. Как оказалось, для DSL это не так - модем может переспрашивать испорченные фреймы и буферизовать то, что пришло до ответа на перезапрос, а потом быстро отдать набуферизованное. Поэтому предложение не приняли.
Поскольку это резервный канал, я на просадку скорости по сравнению с теоретически достижимой забил и просто сконфигурировал SQM статически на «терпимый» уровень. Да, вечером в дождь получается bufferbloat.
config queue 'wwan0'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option itarget 'auto'
option etarget 'auto'
option linklayer 'none'
option enabled '1'
option interface 'wwan0'
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option qdisc_really_really_advanced '1'
option eqdisc_opts 'nat dual-srchost'
option download '2000'
option upload '500'
option iqdisc_opts 'nat dual-dsthost ingress'
Исходная версия AEP, :
Вот что у меня было, пока я не выбросил CAKE-autorate из-за низкого доверия к bash-скиллам автора и наличия соавтора, дающего советы, с которыми я не согласен. Заточено на очень плохой сигнал в пригороде (а по российским меркам это сельская местность), RSRP = -119 dBm (это с внешней антенной), SINR = -3 dB, RSRQ = -12 dB. Вечером, если идет дождь, скорость просаживается до 400 kbit/s или еще меньше. Снижение порога задержки ниже 500 мс приводит к многочисленным ложным срабатываниям, но в основном она держится в пределах 100 мс. Без SQM под нагрузкой ping растет до нескольких секунд.
dl_if=ifb4wwan0 # download interface, created by sqm-scripts
ul_if=wwan0 # upload interface
delay_thr_ms=500
min_dl_shaper_rate_kbps=100
base_dl_shaper_rate_kbps=500
max_dl_shaper_rate_kbps=20000
min_ul_shaper_rate_kbps=100
base_ul_shaper_rate_kbps=500
max_ul_shaper_rate_kbps=20000
connection_active_thr_kbps=100
startup_wait_s=5
monitor_achieved_rates_interval_ms=1000
shaper_rate_adjust_up_load_high=1.05
shaper_rate_adjust_down_load_low=1.0
shaper_rate_adjust_up_load_low=1.0
bufferbloat_refractory_period_ms=5000
reflector_health_check_interval_s=10
reflector_response_deadline_s=5
Еще у меня была дискуссия с автором по поводу более быстрого восстановления после радиопомех. Я предлагал считать, что получение данных с определенной скоростью является неопровержимым доказательством того, что канал связи способен на это. Как оказалось, для DSL это не так - модем может переспрашивать испорченные фреймы и буферизовать то, что пришло до ответа на перезапрос, а потом быстро отдать набуферизованное. Поэтому предложение не приняли.
Поскольку это резервный канал, я на просадку скорости по сравнению с теоретически достижимой забил и просто сконфигурировал SQM статически на «терпимый» уровень. Да, вечером в дождь получается bufferbloat.
config queue 'wwan0'
option qdisc 'cake'
option script 'piece_of_cake.qos'
option ingress_ecn 'ECN'
option egress_ecn 'ECN'
option itarget 'auto'
option etarget 'auto'
option linklayer 'none'
option enabled '1'
option interface 'wwan0'
option debug_logging '0'
option verbosity '5'
option qdisc_advanced '1'
option squash_dscp '1'
option squash_ingress '1'
option qdisc_really_really_advanced '1'
option eqdisc_opts 'nat dual-srchost'
option download '2000'
option upload '500'
option iqdisc_opts 'nat dual-dsthost ingress'