Re: [Ninux-Wireless] Strumenti per benchmark di rete
Il 18/07/2016 12:25, Germano Massullo ha scritto: > Il 18/07/2016 10:10, Stefano De Carlo ha scritto: >>> hardware per la gestione dei pacchetti, soffrono di rallentamenti in >>> caso di installazione di firmware non stock, come Lede/OpenWRT. >>> Tale dubbio è venuto fuori ricordando che alcuni dispositivi Tp-Link >>> hanno un NAT hardware che non viene sfruttato se non si usa il firmware >>> originale[3] >> Se è questo che devi verificare, puoi anche evitare la trafila. Nessun >> Network Accelerator "prosumer" ha supporto open source perché usano tutti >> custom-hack di netfilter, e i dev OpenWrt (presumo anche quelli LEDE), che >> li giudicano ignobili come qualità del codice, non si muoveranno finché non >> ci sarà un approccio general purpose nel kernel. Tutto questo in aggiunta ai >> soliti problemi sulla documentazione e reverse engineering dei chip. >> >> Nei benchmark otterresti gli stessi risultati che se il chip non ci fosse, >> non è predisposto nessun offloading. > Sì conosco la storia, comunque ho avuto una interessante discussione con > gli sviluppatori Lede circa i processori Cavium Octeon che equipaggiano > questi router. Stasera vi incollo tutto > Ubiquiti EdgeRouter(s) claims to have hardware acceleration for packets processing. Their CPU is a Cavium Octeon (example of general datasheet here http://www.cavium.com/pdfFiles/CN50XX_PB_Rev1.pdf ). What I would like to know is: does Ubiquiti enables the hardware acceleration for packets processing using nasty netfilter hacks like Tp-Link does? (example https://dev.openwrt.org/ticket/11779 ). I checked into Linux kernel tree and there are many references to Octeon CPU, so it could it be possible that the hardware acceleration is already managed by Linux kernel https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=cavium+octeon&type=Code So Lede could benefit of such accelration without having to care about nasty code hacks. What do you think about? Title: #11779 (WDR4300 - hardware nat feature) – OpenWrt (at dev.openwrt.org) Title: Search Results · GitHub (at github.com) perhaps I should also send an e-mail to mailing list Germano: what you are seeing is just the support for that CPU and ethernet driver the Linux kernel does not support the offloading like in EdgeOS stintel: mmh, so did Cavium keep such "magic" secret to use it in commercial agreements with networking devices producers? either that, or the code is so crappy that it will never be accepted upstream in that form stintel: is there a chance that Octeon hardware acceleration works without having to be supported by operating system? afaik nope there are some crypto modules for octeon: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/cavium-octeon/crypto Title: kernel/git/torvalds/linux.git - Linux kernel source tree (at git.kernel.org) but I never measured the impact of using those over generic (I have 2 ERLs) stintel: what is an ERLs? ahh EdgeRouter Lite :) EgeRouter Lite stintel: what worries me is that Cavium provides an SDK for Octeon, as I can read from http://www.cavium.com/pdfFiles/CN50XX_PB_Rev1.pdf well most manufacturers are the same, the provided ancient kernels with crappy modifications and can't be bothered with trying to get stuff upstream stintel: so perhaps the only way to see the differencies is to run benchmarks like tcpdive - https://github.com/fastos/tcpdive andApache benchmarks as written in http://arstechnica.com/gadgets/2016/01/numbers-dont-lie-its-time-to-build-your-own-router/ Title: GitHub - fastos/tcpdive: A TCP performance profiling tool. (at github.com) stintel: here http://phx.corporate-ir.net/phoenix.zhtml?c=209126&p=irol-newsArticle_print&ID=1052223 it is written that hardware acceleration concerns encryption, so perhaps even Linux upstream kernel supports such accelerations as we saw before Title: Cavium Networks - Investors > Press Release (at phx.corporate-ir.net) Germano: there are probably some datasheets/NDA that cover "other" acceleration areas on Cavium - and i dont think that ERL/ER do provide 16 MIPS64 cores for example what does mean ù " and i dont think that ERL/ER do provide 16 MIPS64 cores for example" " All accelerators support the OCTEON Plus CN58XX processors with up to 16 MIPS64 cores" from press release ERL is CN5020 ah ok you wanted to say that the press release is about OCTEON Plus CN58XX and Ubiquiti does not use such accelerator yeah- i dont know what ERL /ER is using but you cannot get that price tag with 16 cores plntyk2: Ubiquiti uses dual core Octeon and even now dual core processors on x86 are not that often used in network servers with 10Gbps connections plntyk2: it's a MIPS CPU so that should mean to examine possible throughput claims regarding "how" more carefully ASM optimized DSPs or so? afaik mips does have some dsp subsets plntyk2: we don't know plntyk2: the fastest way for me is to run benchmark on both stock firmware a
Re: [Ninux-Wireless] Torino e Roma
In data domenica 17 luglio 2016 11:05:43 CEST, Massimiliano CARNEMOLLA ha scritto: > [cut...] > - Costringere gli ISP a fare peering e routing nell'ottica di > ottimizzare le distanze di traffico dati tra l'origine e la destinazione > dei pacchetti dati > > > Caso Telecom : io che sono di Siracusa e voglio comunicare con un altro > della mia citta' (o un'altra del centro Italia ) che ha anche lui > Telecom o un altro Operatore e' assurdo che i dati devono passare per > Milano prima di arrivare a destinazione ! (e viceversa) > > > > Qualche settimana fa dovevo scaricare una distribuzione GNU/Linux e ho > cercato un mirror italiano dal quale poterla scaricare :ho trovato GARR. > > > Sulla Rete GARR o cercato un mirror piu' vicino alla mia citta' e ho > trovato BARI. > > > Successivamente effettuando un traceroute mi sono accorto che era meglio > se mi agganciavo a quello di ROMA. > > > I pacchetti da Siracusa arrivano al NAP di Roma , poi entrano nella rete > GARR e vanno a BARI e poi compiono il percorso inverso. > > > > Se la rete garr e quella del tuo isp sono collegate a roma, mi sembra ovvio che i pacchetti passano da li. Vogliamo mettere un internet exchange in ogni citta? Che internamente allo stesso isp i pacchetti girano "lunghi" questo sarebbe da evitare. ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Strumenti per benchmark di rete
Il 18/07/2016 10:10, Stefano De Carlo ha scritto: > Il 17/07/2016 21:51, Germano Massullo ha scritto: >> Avrei bisogno di un software per effettuare dei benchmark su Ubiquiti >> EdgeRouter Pro, come quelli che potete trovare al link [1]. Tali test >> sono stati effettuati con IxChariot[2], che tuttavia è un software >> commerciale. Facendo una breve ricerca su internet ho trovato dei >> software non a pagamento che tuttavia neanche si avvicinano alla qualità >> dei test della sopracitata suite: si limitano a fare delle misurazioni >> della banda passante, ma niente che riguardi ad esempio il massimo >> numero di connessioni aperte contemporaneamente. > Ovviamente scordati GUI ma puoi provare > > * tcpdive - https://github.com/fastos/tcpdive > * Apache Benchmark, con l'approccio descritto qui > http://arstechnica.com/gadgets/2016/01/numbers-dont-lie-its-time-to-build-your-own-router/ Ok grazie. Cito anche i bench https://wiki.openwrt.org/doc/howto/benchmark.openssl (segue) >> Mi interessa scoprire se questi dispositivi, che vantano accelerazione >> hardware per la gestione dei pacchetti, soffrono di rallentamenti in >> caso di installazione di firmware non stock, come Lede/OpenWRT. >> Tale dubbio è venuto fuori ricordando che alcuni dispositivi Tp-Link >> hanno un NAT hardware che non viene sfruttato se non si usa il firmware >> originale[3] > Se è questo che devi verificare, puoi anche evitare la trafila. Nessun > Network Accelerator "prosumer" ha supporto open source perché usano tutti > custom-hack di netfilter, e i dev OpenWrt (presumo anche quelli LEDE), che li > giudicano ignobili come qualità del codice, non si muoveranno finché non ci > sarà un approccio general purpose nel kernel. Tutto questo in aggiunta ai > soliti problemi sulla documentazione e reverse engineering dei chip. > > Nei benchmark otterresti gli stessi risultati che se il chip non ci fosse, > non è predisposto nessun offloading. Sì conosco la storia, comunque ho avuto una interessante discussione con gli sviluppatori Lede circa i processori Cavium Octeon che equipaggiano questi router. Stasera vi incollo tutto ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Strumenti per benchmark di rete
Il 17/07/2016 21:51, Germano Massullo ha scritto: > Avrei bisogno di un software per effettuare dei benchmark su Ubiquiti > EdgeRouter Pro, come quelli che potete trovare al link [1]. Tali test > sono stati effettuati con IxChariot[2], che tuttavia è un software > commerciale. Facendo una breve ricerca su internet ho trovato dei > software non a pagamento che tuttavia neanche si avvicinano alla qualità > dei test della sopracitata suite: si limitano a fare delle misurazioni > della banda passante, ma niente che riguardi ad esempio il massimo > numero di connessioni aperte contemporaneamente. Ovviamente scordati GUI ma puoi provare * tcpdive - https://github.com/fastos/tcpdive * Apache Benchmark, con l'approccio descritto qui http://arstechnica.com/gadgets/2016/01/numbers-dont-lie-its-time-to-build-your-own-router/ > Mi interessa scoprire se questi dispositivi, che vantano accelerazione > hardware per la gestione dei pacchetti, soffrono di rallentamenti in > caso di installazione di firmware non stock, come Lede/OpenWRT. > Tale dubbio è venuto fuori ricordando che alcuni dispositivi Tp-Link > hanno un NAT hardware che non viene sfruttato se non si usa il firmware > originale[3] Se è questo che devi verificare, puoi anche evitare la trafila. Nessun Network Accelerator "prosumer" ha supporto open source perché usano tutti custom-hack di netfilter, e i dev OpenWrt (presumo anche quelli LEDE), che li giudicano ignobili come qualità del codice, non si muoveranno finché non ci sarà un approccio general purpose nel kernel. Tutto questo in aggiunta ai soliti problemi sulla documentazione e reverse engineering dei chip. Nei benchmark otterresti gli stessi risultati che se il chip non ci fosse, non è predisposto nessun offloading. Stefanauss. signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Strumenti per benchmark di rete
Il 18 luglio 2016 09:14, federico la morgia ha scritto: > Ovviamente, perché ? Ti cito un pezzo === Facendo una breve ricerca su internet ho trovato dei software non a pagamento che tuttavia neanche si avvicinano alla qualità dei test della sopracitata suite: si limitano a fare delle misurazioni della banda passante, === iperf che già conosco, si limita a fare esattamente ciò ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Recupero Ubiquiti brickate con AirOS 5.6
Buongiorno, da qualche gg che non leggevo la ML..grazie Fabys per aver riproposto il link! Come ho già detto a lui, mi fa piacere se grazie alla guida qualcuno risparmia un po' del tempo che ho perso io per risolvere il problema. Alla fine è questo il motivo per cui l'ho scritta, sperando di ricambiare il supporto che la community ha dato a me nel tempo. Buona "resuscitazione" a tutti Alfredo Il giorno 11 luglio 2016 16:15, Fabio Capriati ha scritto: > Ilario, > il buon Alfredo di Trani aveva già pubblicato la guida da lui scritta > qualche tempo fa: > > > > Buongiorno a tutti. > Dopo impegni personali vari, son tornato a bomba sulla powerbeam brickata > e...son riuscito a debrickarla. > Ho scritto una guida per documentare la procedura che ho seguito, sperano > sia utile a chi dovesse imbattersi nella stessa sventura. > Ho "poggiato" la guida nel mio dropbox pubblico, ma, se siete d'accordo, > sarebbe meglio includerla tra le guide ninux. > > Il link è questo: > https://dl.dropboxusercontent.com/u/96496926/Debrick%20Procedure%20for%20Ubiquiti%20Powerbeam400.docx > > > Dateci prima un'occhiata e magari mi fate sapere dove è più appropriato > caricarla. > Thanks! > Alfredo (Ninux Trani) > > Il giorno 10 luglio 2016 21:39, Ilario Gelmetti > ha scritto: > >> Ciao gente! >> A fine 2015 ero caduto in una trappola di Ubiquiti aggiornando le mie >> antenne Ubiquiti col firmware originale (AirOS 5.6.x) prima di >> installarci OpenWrt/Libre-Mesh. >> Qui [1] il racconto originale dell'avvenuto. >> >> Premessa: il 99% delle volte che una antenna Ubiquiti ha problemi col >> firmware è sufficiente il recupero tramite TFTP, prima provate con >> quello, col sistema classico! >> Questo caso specifico è abbastanza più complesso. E chiaramente più >> pericoloso per l'antenna, perché si sovrascrive il bootloader. >> >> Dunque, l'altro ieri ho trovato quest'ottima guida [2] con una procedura >> di recupero e... funziona! >> >> In sintesi la procedura consiste in: >> * scaricare l'immagine del firmware originale AirOS versione 5.5.x (non >> 5.6.x!) dal sito di Ubiquiti [3] se non trovate nessuna 5.5 per il >> vostro hardware, probabilmente potete trovare il link tra i download di >> antenne simili in cui il firmware è lo stesso, per esempio questo [4] >> link vale per molte [5] antenne della serie XM e questo [6] per molte >> [7] antenne della serie XW; >> * aprire l'antenna (a volte non banale, vedi sotto) e estrarre la sua >> scheda madre; >> * collegare un adattatore USB to TTL alla porta seriale che c'è sulla >> scheda madre della antenna; >> * accendere l'antenna e interrompere il boot scrivendo nella porta >> seriale al momento giusto; >> * dare all'antenna un comando [8] che abiliti il flashing via TFTP e >> dargli delle opzioni che rendano possibile la sovrascrittura del >> bootloader (normalmente, il recupero normale tenendo premuto il bottone >> di reset, non permette di sovrascrivere il bootloader); >> * inviare tramite cavo di rete e TFTP l'immagine del firmware AirOS >> 5.5.x così da fare il downgrade del bootloader; >> * riaccendere l'antenna, riinterrompere il boot, ridare il comando per >> avviare il server TFTP ma questa volta senza le opzioni per >> sovrascrivere il bootloader, reinviare via TFTP la immagine di prima; >> * fare il normale recupero tramite TFTP col bottone di reset, inviando >> sempre la stessa immagine. >> In pratica si installa tre volte la stessa immagine/firmware, non so >> perché sia necessario farlo tre volte. >> >> Qualche dettaglio sui primi due passaggi, i più difficili e meno >> dettagliati nella guida. >> >> Aprire le antenne: io ho dovuto aprire una Ubiquiti NanoStation M5 e una >> Ubiquiti NanoBridge M5. >> La NanoStation ha una vite nascosta sotto l'etichetta [9], si può >> banalmente rompere l'etichetta o sollevarla con una lama dopo aver >> scaldato per bene l'etichetta con un phon/pistola termica. Dunque c'è da >> disincastrare il pezzo di plastica interno (ha dei dentelli) e tirarlo. >> Per reincastrarla poi c'è da provarci un po' di volte finché non prende >> la direzione giusta e finalmente entra. >> Più problematico è stato aprire la testa della NanoBridge, perché è >> chiusa sia con dentelli sia con della colla, nessuna vite. Si può fare >> con un cacciavite fino ma alla fine resta un buco nella plastica. Quel >> che ho fatto io è stato allargare la giuntura tutt'attorno all'antenna >> tra il corpo e la capocchia [10] con un coltello seghettato e poi >> forzare con l'unghia finché non s'è aperta, altri su internet dicono di >> averla aperta mettendola in morsa. Più istruzioni qui [11]. >> >> La connessione seriale: sulla NanoStation sono marcati dei pin con GND, >> SIN, SOUT e PWR. Più informazioni qui [12]. >> Sulla NanoBridge i pin della porta seriale non sono etichettati, >> comunque sono, partendo dal più vicino all'antenna vera e propria: >> ground, TX, RX, PWR. Più informazioni qui [13]. >> >> Non avendo l'adattatore USB to TTL suggerito nella guida [2] ho usat
Re: [Ninux-Wireless] Strumenti per benchmark di rete
Ovviamente, perché ? Da: wireless-boun...@ml.ninux.org per conto di Germano Massullo Inviato: lunedì 18 luglio 2016 08.42.18 A: wireless ninux ML Oggetto: Re: [Ninux-Wireless] Strumenti per benchmark di rete Hai letto la e-mail? ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
