- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Synology NAS
- 3,6 billió dollárt ér az NVIDIA, idáig még egy cég sem jutott el soha
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Hálózati / IP kamera
- Windows 7
- QNAP hálózati adattárolók (NAS)
- Windows 10
- AliExpress tapasztalatok
- Windows 11
-
IT café
Specifikációjához képest meglepően olcsó router, ami AC1200-as Wifi-t és gyári firmware-val is több hasznos szolgáltatást ígér (fájlmegosztás, dlna, nyomtató megosztás, stb.)
Új hozzászólás Aktív témák
-
dchard
veterán
Kis érdekesség B1 procival kapcsolatban:
root@LEDE:~# cat /proc/cpuinfo
system type : MediaTek MT7621 ver:1 eco:3
machine : D-Link DIR-860L B1
processor : 0
cpu model : MIPS 1004Kc V2.15
BogoMIPS : 586.13
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp mt
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
VPE : 0
processor : 1
cpu model : MIPS 1004Kc V2.15
BogoMIPS : 437.45
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp mt
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
VPE : 1
processor : 2
cpu model : MIPS 1004Kc V2.15
BogoMIPS : 586.13
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp mt
shadow register sets : 1
kscratch registers : 0
package : 0
core : 1
VCED exceptions : not available
VCEI exceptions : not available
VPE : 0
processor : 3
cpu model : MIPS 1004Kc V2.15
BogoMIPS : 586.13
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp mt
shadow register sets : 1
kscratch registers : 0
package : 0
core : 1
VCED exceptions : not available
VCEI exceptions : not available
VPE : 1Ezek szerint két fizikai mag, és négy logikai szál van a cuccban, ha jól értem a MIPS VPE működését. Gondolom az Intel-féle HT-hoz hasonlóan működik.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Egyelőre marad a LEDE 17 RC2. Nem tapasztaltam eddig wifis problémát (ezalatt a 3 óra alatt
), de figyelni fogok rá, és a logokat is nézni fogom az ismert jelenségekkel kapcsolatban.Ami eddig feltűnt (LEDE alatt), hogy mennyivel gyorsabb a webes felület mint CC 15.01 + 1043ND v1 alatt. A procival kapcsolatban ha maga a router az iperf3 szerver, akkor a 1043ND v1 valahol 140Mbit-nél maxolta ki a procit, a 860L B1 viszont 650Mbit-nél tekert ki egy azaz egy magot (25% loadnál maxolt, úgy tűnik az iperf3 nem fut több szálon ezen a targeten). És mindkét esetben proci limit van, azért ez nem kis gyorsulás.
Kezdem elhinni, hogy menni fog a giga NAT vele
De majd azt is kipróbálom.Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Igen, LAN oldalrol mertem lede 17 rc2-vel. Egy honap mulvare igerik a 17 finalt, akkor ujra probalkozom (hacsak addig nem talalok irritalo hibat).
Annyi bug van, hogy a wan6 interfeszt nem tudom torolni. Korabban CC 15.01 es LEDE alatt is mukodott ez a resz.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
A kliens egy A6-3600 volt (4magos AMD), közelében nem volt egyik mag sem a 100%-nak, nem a proci koppant ki. Az lehet, hogy az RC2 és a snapshot között van ilyen mértékű eltérés a teljesítményben LEDE-n?
Hibát egyelőre nem találtam, a környezetemben többen ráizgultak, mikor mondtam hogy mit és mennyiért tud
Ha kijön a stabil 17, azzal is kipróbálom, és akkor lesz összehasonlítható eredményünk.Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Sysupgrade-del átmentem mai LEDE snapshot-ra, és ez lett az eredmény:
Hát nem kicsit jobb. És csak a LEDE verzió változott, semmi más. A leszívások - ki nem fogod találni - a webes felület frissítése a háttérben.
Ez LAN-LAN mérés, iperf3 szerver a routeren futott ismét. Az RC2-höz képest 650Megáról gyorsult 830-ra, és megint csak az egyik mag pörgött fullon (egy szál 25%-on).
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Wifin Redmi Note 3 SE-vel AC-n stabil 240 mega le,220mega feltöltést mértem az alábbi csatornával:
325.0 Mbit/s, 80MHz, VHT-MCS 7, VHT-NSS 1, Short GI
433.3 Mbit/s, 80MHz, VHT-MCS 9, VHT-NSS 1, Short GIDe ez MIMO nélkül ennyi (a teló nem tud csak 1x1-et).
Szerintem ennek a duplája reális egy rendes 2x2-es kártyával.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Ma a poén kedvéért kipróbáltam az USB3 sebességet magán a routeren egy HyperX Savage 128GB-os eszközzel, ami a speckó szerint (és Win7 alatt a valóságban is) 350MB/s-et olvas, 250MB/s körül ír.
Mindenfajta hálózati használat nélkül, magán a routeren DD-vel toltam neki tesztet, és meglepődve tapasztaltam hogy 46-48MB/s olvasásnál kikoppant a proci (szintén csak egy szálat használ, mint az iperf3).
Sajnos csak NTFS alatt tudtam kipróbálni eddig. Nem tudom eldönteni, hogy itt az NTFS olvasás, vagy a dd a szűk keresztmetszet?
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Nohát, ha hdparm-al teszteltem, akkor nálam is 98-99MB/s jött ki, ez összevág Vargalex mérésével. Ha DD-vel ext4 mellett olvastam hasonló eredmény jött ki (97MB/s). Ellenben ha ext4 mellett írtam DD-vel, ismét extrém lassúságot tapasztaltam (50MB/s körüli eredménnyel). Utóbbi két esetben fájlrendszer szinten, az elsőben blokk szinten történt a mérés.
Az lenne a kérdésem Vargalex kollégához, hogy a Samba tesztnél mindkét irányban megnézted a sebességet, és mindkét esetben kijött a 98MB/s neked?
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Rossz szóválasztás.
Én eddig teljesen elégedett vagyok, amúgy sem használom a routert adattárolásra, az hogy gigabittel olvas, is egy kisebbfajta csoda. AZ extrém lassulást úgy értettem, hogy még nem láttam olyat linuxon, hogy ennyire aszimmetrikus legyen a fájlrendszert érintő művelet a két irányban.> Ugye noatime-val mount-oltad?
Nem, de akkor így is ki fogom próbálni.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Én 5giga AC-n használom, teljesen korrekt a wifi (is).
És megerősítem: egy hete még Edigital mamutban B1-et kaptam (raktárról).
Szerintem azért árulják hulladék pénzért, mert egyrészt nem tud AC3200at, "csak" 1200-at, se MU-MIMO-t, tehát nem cseng már elég jól a tudása. A másik, hogy gyári SW-vel tényleg elég fos az egész, ezért lehúzták sok reveiw-ban. Tehát összegezve: marketing.
Érdemes volna hasonló MTK chippel szerelt routereket nézni az összehasonlítás kedvéért.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Most frissítettem a legújabb lede snapshot-ra (tegnapi build).
5GHz-en AC-n SISO módban mindkét irányban 220-250Mbit/s-ot mérek, az USB portot nem használom.
2.4gigán stabil 50megabit/s jön ki, de itt megint 20MHz@SISO-ról van szó, tehát az elméleti maximum 72megabitből jön ki 50mega, ez nem rossz eredmény.
MOD: a kernel még mindig 4.4.49, tehát a váltás 4.9-re még nem történt meg snapshot-on sem.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
http://www.pcmag.com/article2/0,2817,2423604,00.asp
És nézzétek csak, pont melyik típusról van szó a cikkben:
"What Are Router Makers Doing?
In addition, router makers are taking other measures. According to Loyd, D-Link added an option to turn on and off the USB 3.0 port on the DIR-860L and DIR-868L routers. When enabled, it notifies users with a message that enabling USB 3.0 might adversely affect the 2.4GHz wireless signal."Az intel szintén beleütközött ebbe:
A másik gond a vékony, szarul szigetelt kábelek, mert hiába a panelon lévő árnyékolás, ha rögtön a csati külső oldalán szétsugározza ezt a zajt egy vacak kábel (vagy a kábel végén lévő szarul árnyékolt USB3-mas eszköz). De ez nem D-Link specifikus probléma az biztos.
A külső merevlemez beépítése biztosan rontott a problmán, mivel a gagyi kínai USB3 vezérlő (a vélhetően műanyag házával) gyakorlatilag az antennák tőszomszédságába került, tehát nem a merevlemez fém teste a gond, hanem az USB3-Sata átalakító és/vagy a kábel által szétsugárzott zaj.
Nálam teljesen jó LEDE-vel a 2.4GHz (nincs semmi USB-n beledugva).
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
-
dchard
veterán
Nem szerencse dolga. Sokkal inkább a használt szoftver (gyári, Openwrt, LEDE), és azok verziója határozza meg, a hardverben nincs szórás.
Érdemes lehet kivárni a 2 hét múlva megjelenő LEDE stabilt, megnézni hogy nekünk mennyit megy, és utána beruházni. Én alapvetően elégedett vagyok AC-n és 2.4 N-en is vele, de nagyon extenzíven nem használom a wifit-t.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Lemaradtam róla
Most felraktam. Ac AC és az N 2.4-en továbbra is jó, viszont érdekes hogy a korábbi 900megabites iperf3 mérésem visszaesett 680-ra. Félreértés ne essék: ez megint a proci limit kérdése, tehát sem a LAN, sem a Wifi, sem NAT képességéről nem szól ez a mérés, de mindenesetre furcsa, hogy volt már olyan LEDE változat, amivel ennél jóval többet mértem.
AC-n SISO módban 250megabitet mérek stabilan (433 elméleti maximumból), 2.4GHz-en N SISO módban 55megabitet mérek (a 75mega elméleti maximumból). Mindkettő teljesen jó érték. Ha egyszer megjön a 2x2 AC-s kártyám, ígérem azzal is lemérem.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Én az oldalukon csak bullshit bingót láttam. A mediatek-nek egyáltalán van HW NAT megoldása? Ennél a modellnél biztosan nem szorulnak rá, az már kiderült. Viszont az is látszik, hogy a LEDE/OWRT repóknak is fel kell készülniük a routerek szintjén is a többmagos procikra, mert lassan jönnek a közép kategóriában is az ilyen megoldások. Teljesen nonszensz, hogy az iperf3 (ami soktíz gigabitig skálázódik) képtelen több szálat használni LEDE alatt, miközben teljesen egyértelmű, hogy x86-on képes több magot is hasznosítani. Az iperf2-ből régen volt egy iperf2-mt nevű verzió is több szálra, nem tudom azzal mi lett, illetve hogy az iperf3-nál miért nem fordítottak ilyet is (ha ehhez külön fordítás kell).
Viszont a wifinél ezt írják:
"The router operates on both the 2.4 GHz band and 5 GHz wireless bands at the same time using concurrent dual-band technology and six internal antennas."
Valaki megtalálta már ezt a hat darab beépített antennát? Mert a képeken csak kettő látszik, ami meg is felel a 2x2 MIMO specifikációnak.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
woodworm
#105
üzenetére
Ezt én is megtaláltam, de a FireWRT leírásában is csak ennyi szerepel. Hogy pontosan hogyan valósítja meg (lásd: BCM és QCA megoldások), arról semmit nem tudunk. Lehet, hogy amit ők HW NAT-nak hívnak, az egyszerűen csak egy "dedikált" sima mag mondjuk a NAT engine-nek, és kész. És mivel tisztán szoftverből is kijön a giga NAT, tulajdonképpen megtehetik. A FireWART-nél az is leírják, hogy hivatalosan OWRT támogatott, ami biztosan nem igaz, mert semmilyen HW NAT implementáció tudtommal nincs az OWRT-ben, erről hosszas viták folytak több nyitott feature request alatt is, a válasz pedig az volt, hogy azért sem implementálják ezeket, mert megtörik a forward chain kompatibilitást, tehát nem mások mint hack-ek.
Arról sem tudunk semmit, hogy ha van is ilyen dedikált HW NAT, azt vajon használja-e mondjuk a Dlink gyári szoftvere, vagy sem.
Vannak értelmes megoldások is, mint az openfastpath vagy az opendataplane, de arról nincs hír, hogy ezeket implementálják-e és ha igen, mikor.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#108
üzenetére
Szia,
LEDE stabil alatt te tudsz mondjuk 100-as csatornát állítani 5gigán? Nálam az istenért sem megy, pedig:
root@LEDE:~# iw phy phy0 channels
Band 2:
* 5180 MHz [36]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40+ VHT80
* 5200 MHz [40]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5220 MHz [44]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5240 MHz [48]
Maximum TX power: 20.0 dBm
Channel widths: 20MHz HT40- HT40+ VHT80
* 5260 MHz [52]
Maximum TX power: 20.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5280 MHz [56]
Maximum TX power: 20.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5300 MHz [60]
Maximum TX power: 20.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5320 MHz [64]
Maximum TX power: 20.0 dBm
Radar detection
Channel widths: 20MHz HT40- VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5500 MHz [100]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5520 MHz [104]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5540 MHz [108]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5560 MHz [112]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5580 MHz [116]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5600 MHz [120]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5620 MHz [124]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5640 MHz [128]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5660 MHz [132]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5680 MHz [136]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- HT40+ VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms
* 5700 MHz [140]
Maximum TX power: 27.0 dBm
Radar detection
Channel widths: 20MHz HT40- VHT80
DFS state: usable (for 30773 sec)
DFS CAC time: 60000 ms36-48 között működik kizárólag, pedig radart sehol sem talál (ott sem, ahol lehetne, mert minket gyönyörűen kitakar a Ferenc hegy
).Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
LEDE-n meg 17dBm (100-as csatorna), 56-os csatin meg 18dBm.
Kiválasztani engedi a 27dBm-et, de hiába választod ki, tx powernek annyit ír, mint egy sorral fentebb vázoltam.
Persze korábban már többször beszéltük, hogy ezek az értékek semmit nem jelentenek, amíg azt meg nem mérjük egy peak power analyzerrel
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vottokar
#118
üzenetére
USB3 témában annyit mondhatok, hogy a múlt héten Zirowe kollégával végeztünk egy gyors spektrum analízist, és nem látszott számottevő kisugárzott interferencia sem a kábelből, sem a teljesen csupasz, minden árnyékolást nélkülöző USB3 kontrollerből. Azért ha elég közel (1cm) helyeztük az antennát, látszott forgalom mellett kb. 5-7dB zaj növekedés, de ha az eszköz tisztességes, legalább 10cm-es távolságban van a vevőtől (nincs beleaplikálva 1cm-re a belső antennától), akkor nem lehet gond.
Szerintem USB3 mellett valamilyen ütemezési és/vagy I/O probléma lehet, ezt lehet javítani szoftveresen.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vottokar
#122
üzenetére
A pontosság kedvéért: az állítás az, hogy normál használat mellett (értsd: nem a router dobozába kókányolt merevlemezzel), a rendszernek működnie kéne rendesen. Nálam nincs merevlemez, és lede stabillal működik is szépen, ha beledugom az USB3-mas pendrive-ot, akkor is működik.
De azért azt nem állítom, hogy az intel mérését sikerült megcáfolni.
Annyi biztos, hogy vacak kábellel és átalakítóval simán összeszedhet komoly mértékű zavartatást a 2.4-es sáv. Ez ellen teljesen fém USB3 házzal és, jó minőségű USB3 kábellel lehet (és kell is) védekezni. Előbbinél érdemes megnézni, hogy a fém ház és az USB3 csatlakozó külső fém része kapcsolatban van-e egymással (egyszerű multiméteres szakadás vizsgálat), mert ha nem, a fém ház sem ér sokat.Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Az N18-ban egymagos coretex A9 van 800MHz-en, ebben meg MIPS 880MHz van, de két fizikai mag, négy szállal. Tehát a DIR-860L-ben erősebb a SoC, nem is kicsit.Az Asus-ban több a RAM és a flash. Kérdés, hogy mire van inkább szükséged.
Engem az, hogy tisztán szoftverből kinyomja a giga NAT-ot eléggé meggyőzött a dir 860L mellett. Különösen ha az árát is figyelembe vesszük.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Na ma végre megjött az Intel AC 7260-as kártya a laposba, bele is raktam hogy kipróbáljam, hát kiábrándító:
Windows és Linux alatt is 15-180megát tudott a kártya 2x2 MIMO AC módban, -60dBm-nél egy teljesen üres 80MHz-es csatornán. Ennél az 1x1 MIMO-s Xiaomi telóm többet tud, és ami egészen megdöbbentő, hogy a router kielzi, hogy valóban használja a 2x2 módot (MCS8-MCS9) és így is csak ennyi jön ki.
Aztán belenéztem a router naplójába és ezt a szép crash-t találtam:
[168989.980000] ------------[ cut here ]------------
[168989.980000] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:306 dev_watchdog+0x258/0x2fc()
[168990.000000] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[168990.020000] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt mt76x2e mt7603e ledtrig_usbport mt76 mac80211 cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables leds_gpio xhci_mtk xhci_plat_hcd xhci_pci xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[168990.140000] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.52 #0
[168990.160000] Stack : 00000000 00000000 804e6862 00000033 00000000 00000000 80490000 80500000
[168990.160000] 87c4b46c 80489d83 8040495c 00000001 00000000 804e367c ffffffff 00000200
[168990.160000] 00100000 80064f7c 80490000 80500000 8048e288 8048e28c 80409270 87c19e04
[168990.160000] 00000003 80062cc8 ffffffff 00000200 00100000 00000000 00000006 00c19e04
[168990.160000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[168990.160000] ...
[168990.230000] Call Trace:
[168990.230000] [<80016934>] show_stack+0x50/0x84
[168990.240000] [<801b709c>] dump_stack+0x84/0xbc
[168990.250000] [<8002cf50>] warn_slowpath_common+0xa0/0xd0
[168990.260000] [<8002cfac>] warn_slowpath_fmt+0x2c/0x38
[168990.270000] [<802cc408>] dev_watchdog+0x258/0x2fc
[168990.280000] [<80074018>] call_timer_fn.isra.4+0x24/0x80
[168990.290000] [<80074270>] run_timer_softirq+0x1fc/0x25c
[168990.300000] [<8002fb64>] __do_softirq+0x294/0x2e0
[168990.310000] [<8002fe4c>] irq_exit+0x78/0x94
[168990.320000] [<801e15e0>] plat_irq_dispatch+0xb4/0xdc
[168990.330000]
[168990.330000] ---[ end trace 1a7925289a9798d2 ]---A mérés során (utolsó 4 sor) pedig ilyeneket:
[168990.340000] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[168990.350000] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[168990.370000] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=07092000, max=512, ctx=358, dtx=358, fdx=357, next=358
[168990.390000] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=073f6000, max=512, calc=463, drx=464
[484855.980000] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[484855.990000] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[484856.000000] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=073f6000, max=512, ctx=370, dtx=370, fdx=369, next=370
[484856.020000] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=07092000, max=512, calc=487, drx=488
[560865.980000] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[560865.990000] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[560866.000000] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=07092000, max=512, ctx=247, dtx=247, fdx=246, next=247
[560866.020000] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=073f6000, max=512, calc=383, drx=384
[718260.980000] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[718260.990000] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[718261.000000] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=073f6000, max=512, ctx=193, dtx=193, fdx=192, next=193
[718261.020000] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=07092000, max=512, calc=61, drx=62
[870825.980000] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[870825.990000] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[870826.000000] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=07092000, max=512, ctx=23, dtx=23, fdx=22, next=23
[870826.020000] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=073f6000, max=512, calc=155, drx=156Ez most a stabilnál valamivel frissebb snapshot LEDE.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#162
üzenetére
Milyen fw volt rajta?
Egyébként most reszelik a 4.9-es kernelt lede alatt, amint kijön kipróbálom.
Nálam az intel AC-s kártyája rosszabb eredményt produkál 2x2 MIMO alatt, mint a Xiaomi telóm 1x1 SISO módban. Előbbi a már korábban linkelt hibákat generálja a router kernel logjában.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#168
üzenetére
Nekem is intel 7260 az AC-s kliensem és nálam borzalmasan rossz. Ha megtolod a wifit AC-n az intel 7260-nal, akkor mit látsz a kernel logban: látsz hasonló hibákat mint amiket én linkeltem korábban? A kliensed windowst vagy linuxot futtat?
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
MrSealRD
#219
üzenetére
Én egyelőre kitartok, túl erős benne a SoC és engem ez (a vezetékes performansz) jobban érdekel. Lassan jön a 4.9-es kernel is, az is hozhat némi fejlődést.
Én már LEDE-n láttam elég jó AC-s sebességeket (lásd: korábbi hozzászólásaim), tehát számomra egyértelműnek tűnik a szoftveres gond, ezt ki fogják reszelni.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
MrSealRD
#222
üzenetére
Nézd, nekem a wifi sebesség nice to have, az én oldalam ki van kábelezve, csak a telóm lóg wifin. Ha lesz egy kis időm, kikábelezem lófütty méretű antennáit, és kipróbálok több felállást, mert nálam is volt teljesen jó 220-250mega LEDE-n (SISO-n az eléggé a vége a sztorinak, 433mega elvi maximummal számolj), szóval nem a hardver tűnik problémásnak.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Az USB porttal semmi gond nincs, kifejezetten gyors (főleg USB3-mon). Egészen biztos vagyok benne, hogy az LTE hálózat lesz a szűk keresztmetszet, nem pedig az USB port a routeren.
mr3420-at utoljára DC+HSPA+-on használtunk, akkor elméleti max közelében (38Mbit-nél) tetőzött a sebesség, viszont a régebbi TP-Link-ekre jellemző volt az USB port alul méretezése, ezért sok volt a táplálási hiba. A 860L viszont legalább 1 ampert ki tud köhögni, tehát ilyen gond nem lehet, pláne egy USB2 modemmel.
Esetleg érdemes lehet a modemet USB hosszabbítóval előnyösebb helyzetbe hozni, vagy eleve úgy elhelyezni a routerrel együtt, hogy jobb rálátása legyen a modemnek a toronyra (ablak közelében, vagy emeletre ha családi ház), ezek befolyásolják leginkább a sebességet.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
#310
dchard
veterán
markussandor
#309
dchard
veterán
válasz
markussandor
#309
üzenetére
Dettó. Ráadásul a TM-et elég jól lehet finomhangolni ami a memória fogyasztást illeti. Persze továbbra is igaz, hogy alapvetően a szálszám és a cache méret határozza meg a memória fogyasztást.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Felraktam a 17.01.1 LEDE-t, és vége visszakaptam a telómat, úgyhogy most mértem egyet 5GHz AC-n, és SISO módban stabilan megvolt a 230Mbit/s, ami jó eredmény. 2.4gigán szintén SISO módban volt 55Mbit/s 20MHz-en, ami szintén baromi jó (72 elméleti maximumból).
A hírhedt intel 7260 kártyámmal még nem néztem meg, ha lesz egy kis időm akkor kipróbálom.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
48-as csatorna fölött 60 másodperces kötelező scannelés van, ahol időjárási radart keres a cucc, és ha talál, nem engedélyezi. Nálam 60 másodperc után elindul az adás 56-on (LEDE alatt). DFS-nek hívják a technikát.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
-
dchard
veterán
válasz
vargalex
#526
üzenetére
Van arra esély, hogy amitől jobb a padavan alatt a wifi (egyébként mitől jobb? tudjuk az okát?), az bekerül LEDE-be is? Most toltak egy nagyobb csomagot mt76-ba lede alatt, a gitlog szerint sokat javít, bár nem próbáltam még.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
#610
dchard
veterán
PowerBuldog
#609
dchard
veterán
válasz
PowerBuldog
#609
üzenetére
Én LEDE-vel használom megelégedéssel. (17.01.2)
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#615
üzenetére
vargalex:
Kérlek vess egy pillantást erre:
https://bugs.lede-project.org/index.php?do=details&task_id=764
Tegnap nyomtam fel az új trunk LEDE-t és akkor tűnt fel (kernel 4.9.37), de korábban is láttam már. Nálam fagyást, újraindulást nem okoz, viszont a leírtakkal ellentétben nem csak SQM vagy más QoS mellett, hanem erős terhelés mellett bármikor előjöhet. Pillanatnyi lassulás okoz: például 120megával jön a torrent (külön NAS-ra), beugrik a linken látható kernel warning, a letöltés egy pillanatra leesik 30-40megára, majd folytatja.
Van hozzá külön pacth is, most próbálom ki, de ennek a kernel warningnak MTK7621-en több inkarnációja is ismert. Érdemes volna odafigyelni rá, hátha másnál is előjön. Mivel egyértelműen minimum komoly időszakos teljesítmény vesztést (de van akinél fagyást) okoz ez a hiba, így lehet hogy a WiFi szarakodásának is részben vagy egészben ez lehet az oka.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Még egy kérésem lenne. Ha valaki használ padavan-t, megtenné hogy a kernel log-ból (dmesg) kiszedni nekem ezt a részt:
[ 64.240000] mt76x2e 0000:01:00.0: ASIC revision: 76120044
[ 64.270000] mt76x2e 0000:01:00.0: ROM patch already applied
[ 64.340000] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
[ 64.350000] mt76x2e 0000:01:00.0: Build: 1
[ 64.360000] mt76x2e 0000:01:00.0: Build Time: 201507311614____
[ 64.400000] mt76x2e 0000:01:00.0: Firmware running!
[ 64.410000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 64.410000] mt76x2e 0000:02:00.0: ASIC revision: 76020044
[ 64.430000] mt76x2e 0000:02:00.0: ROM patch already applied
[ 64.450000] mt76x2e 0000:02:00.0: Firmware Version: 0.0.00
[ 64.460000] mt76x2e 0000:02:00.0: Build: 1
[ 64.470000] mt76x2e 0000:02:00.0: Build Time: 201507311614____
[ 64.500000] mt76x2e 0000:02:00.0: Firmware running!?
Köszönöm!
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Nyomattam mind a 4 magot fullon egy órán át, csináltam egy órányi iperf3 tesztet 4 szállal, de a patchelt verzióban nem jön elő. Az jó hír mert korábban 5-10 perc után könnyen elő tudtam csalni.
Fontos, hogy a patch egyelőre sem a snapshot sem a stabil buildben nincs benne. Itt lehet a patchelt verzióhoz hozzáférni:
https://pub.polyno.me/lede-ramips-FS804/
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#623
üzenetére
A patch-elt verziót töltöttem le, nem forgattam. Egy nap alatt nem jött elő a hiba egyszer sem. Wifi témában:
2.4GHz 20MHz-en MC9-el (SISO) 44-45mega stabilan az elméleti 72-ből.
5.Ghz 80MHz MCS) (SISO!) stabil 240-250megabit az elméleti 433-ból.A 2.4 nem tiszta, az 5giga tiszta volt. Szerintem ezek jó eredmények figyelembe véve hogy SISO mind a kettő.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Proftpd, pureftpd és vsftpd is működik mind lede mind openwrt alatt.
Én évek óta proftpd-t használok szervereken, de tény hogy fölöslegesen nagy a tudása egy router esetében. Ilyen kevés userre meg forgalomra a vsftpd is jó választás.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Ezzel nem, de gyengébbel igen és simán működött. Belülről sem éred el? Nem lehet hogy tűzfal vagy konfig probléma van?
Vargalex:
http://www.t-firefly.com/download/FireWRT/hardware/MT7621.pdf
Hátha valakit érdekel.
Egyébként a egy csomó folyamatban lévő fejlesztés van LEDE alatt ami ezt a platformot - így minket is - érint. Érdemes ránézni erre (még nincs trunk-ben sem), például a HW NAT vagy a HW crypto:
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
#631
dchard
veterán
csocsoszán
#630
dchard
veterán
válasz
csocsoszán
#630
üzenetére
Van ftp elérés, LEDE-n és openwrt-n is.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Oké, akkor mondom én hogy csináltam:
1. Belépsz putty-tyal ssh-n a routerbe.
2. opkg update
3. opkg install vsftpd
4. Kiadod: ./etc/init.d/vsftpd enable
5. Kiadod: ./etc/init.d/vsftpd startÉs belépsz FTP-n (értelemszerűen így csak "root" felhasználóval fog menni amíg nem kreálsz másik user-t)
Innentől kezdve már csak a konfig állományt kell ízlés szerint beállítani (/etc/vsftpd.conf)
Pontosan 3 percbe telt felrakni, működik
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Adatmozgatás igen, egyéni név jelszó nem. De az is le van írva kismillió tutorialban, hogy azt hogyan lehet shell hozzáférés nélkül megcsinálni. A vsftpd egyébként tud külön FTP user név/jelszót saját fájlban is tárolni.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz
vargalex
#636
üzenetére
Szia,
A kernel warningokat/összeomlásokat javító pacth-ek már benne vannak a mai legfrissebb snapshot-ban, fel is raktam tesztelni. Erről a két pacth-ről van szó egyébként:
ralink: fix rcu_sched stalls on mt7621
ramips: refresh the rcu_sched patch and remove debug info
Az eddigi tesztek elég bíztatóak.
A többivel kapcsolatban igazad van, azok nem a ramips tree-be kerültek, viszont mivel mindkettő mediatek, talán nem találták fel újra a spanyol viaszt, és hamarosan jön a HW crypto és a HW NAT is LEDE-n. Asszem padavan-ba hekkelt hw cryptóval értek el 6 vagy 9-szeres gyorsulást nagy méretű csomagoknál. Ha ezt megkapnánk LEDE-n elég boldog lennék
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest