Tak, śmiem twierdzić, że jesli cały kontroler USB na odroidzie h2+ jest zapiety po szynie której przepustowość jest w okolicy 1Gbit, to tyle właśnie będzie sufitem dla możliwości tego sprzętu, tyle i nic więcej. Tak samo widzę, że ten sam modem wpięty w nowoczesny sprzęt z nowym kontrolerem USB nie widzi tego sufitu i przyjmuje na klatę tyle ile wycisnę z BTS, na tym samym kernelu, zestawie paczek i generalnie podobnym środowisku (bo wszytko wszedzie trzymam na archu i kernelu linux-zen).
Wiele procków ARMowych jest pokracznych, źle zaprojektowanych, USB do niedawna w ogóle było traktowane po macoszemu - a ruting i nating po interfejsach, w sprzęcie, który miał rutować i natować - po interfejsach sieciowych - był zrobiony jako-tako - nie dziwi mnie, że nie wszystkie problemy zostały rozwiązane albo poprawnie zaadresowane.
> Możliwe też , że jak będzie to sprzęt odpowiednio "mocny" z możliwie małą ilością rdzeni/wątków , to sobie da radę mimo to....
jasne, że tak, i czasami rzucenie pieniędzmi w problem to wystarczające rozwiązanie. wiem, jestem na forum dla ludzi, którzy lubią na armowych potworkach to uruchamiać, co szanuję. w międzyczasie z przyjemnością się temu przyglądam, bo parę sztuczek sobie stąd już wybrałem i dla siebie. inna sprawa, że ruting i nating i konfigurację vlanów wolę zrobić ręcznie, z palca albo w innych konfigach niż to co siedzi w openwrt, a do wifi mam kontroler unifi, którego na armie juz nie odpalę.
> Bo znamy dobrze przykład , gdzie router z MT7621AT z modemem RM530 osiąga 1Gbps ( bo szybciej mu nie pozwala gniazdo LAN) , a routery z tym samym prockiem na Openwrt nie są w stanie wyciągnąć nawet 300Mbps....
jaki przykład? z ciekawości.
> Może odpowiednio stary kernel linuxa by wystarczył
bs. jesli tego nie zaraportowałeś, nie zrobiłeś bisecta na wersjach jajka, to winnym jestes tylko ty. cały linux się opiera na raportowaniu regresji przez społeczność.