Sun Jul 29 00:55:36 CEST 2007

Sun Jul 29 00:55:36 CEST 2007 gattuso
Ho notato che molti players ita si lamentano dei ping da strabuzzare gli occhi nei vari PROLINUX & MXB Ho deciso di conseguenza di fare un piccolo scriptino per diminuire un minimo le latenza con linux su questi tre server questo è lo scriptino bisogna eseguirlo così all'incirca -creare un documento con il proprio editor preferito -salvarlo -muoverlo in /etc/init.d (sudo mv nomescript /etc/init.d) -cambiargli i permessi (chmod a+x /etc/init.d/nomescript) -riavviare il sistema oppure lanciare lo script P.S. correggetemi vi prego se ci sono delle sviste madornali nello script Spero che vi sara utile Ci becchiamo in game

Sun Jul 29 02:16:14 CEST 2007 peoro
Uh, sembra proprio carino [img:2ndk3si6]http://www.marmotta.ch/faccine/sbav.gif[/img:2ndk3si6] complimenti! Quando ho un po' di tempo lo provo, intanto grazie [img:2ndk3si6]http://www.marmotta.ch/faccine/metal.gif[/img:2ndk3si6]

Sun Jul 29 02:28:26 CEST 2007 Briareos
L'idea sarebbe carina, se mai il tos fosse stato implementato .... se leggete qui http://en.wikipedia.org/wiki/IPv4 all'appostia sezione tos capirete dove pongo i miei dubbi.... Poi se funzionasse ben venga.

Sun Jul 29 12:34:58 CEST 2007 jackal@slack
l'ho provato ora, ma su un server vuoto non ho notato nessun cambiamento nel ping

Sun Jul 29 13:17:07 CEST 2007 gattuso
ho letto velocemente la parte relativa al TOS, dice che ora e' sostiuita da ECN e Diffserv. DiffServ in parole povere è il QOS, ECN è un'altra cosa. Io il QOS un minimo lo so usare l'ECN per nulla, quindi la mia soluzione sarebbe, eliminiamo l'ECN dalla nostra comunicazione col server con una linea del tipo oppure se qualcuno conosce bene il QOS possiamo provare a fare qualcosa con quello.

Sun Jul 29 13:24:26 CEST 2007 Briareos
l'explicit congestion protocol e' una proposta per cui e' possibile notificare esplicitamente che l'apparato e' congestionato (parliamo di router quindi ) e di prendere provvedimenti ( diminuire le window di trasmissione ... ) alcuni host tendono tra le altre cose a gestire male i pacchetti con ecp, è quindi da utilizzarsi solo tra 2 host che siamo sicuri supportare questa feature. Summa del discorso... lascia stare il TOS

Sun Jul 29 13:30:09 CEST 2007 gattuso
Passiamo allora simpaticamente al QOS per questo vi rifaccio sapere tra un pò devo prima documentarmi a fondo. Se avete documentazione al riguardo mi fareste il piacere di non farmela cercare. A proposito ho provato anch'io il mio scriptino ma pare che il ping si abbassi al massimo di 2/3. Se lo provate anche voi magari vediamo se funziona.

Sun Jul 29 16:08:49 CEST 2007 or3fixul
ma trem non usa UDP?

Sun Jul 29 16:26:14 CEST 2007 gattuso
A quanto ne so usa TCP, correggetemi se sbaglio L'UDP a quanto ne so è sgradevole da usare con applicazioni in semi-realtime perche non ha la data di arrivo nell'header NOVITA' Cmq anche il TTL (Time-to-live) dovrebbe aiutare parecchio Da quello che ho capito il TOS non è molto preso in considerazione dai routers vari per cui se il problema è dei routers sara difficile risolverlo Passando invece alle persone che non passano da tremila cinquecento routers all'estero Ho trovato qualcosa di interessante sul TOS: come dice questa pagina il TOS lo si identifica dai byte iniziali e sebbene non viene riconosciuto dai routers può essere riconosciuto dal server il qos riesce a riconoscere i pacchetti anche per byte con cui partono, per cui se si potesse fare uno script lato server potremmo dare priorità con HTB magari alle persone che ne hanno veramente bisogno. Insomma un sistema simil client-server se così si può definire. Il problema più grande è di capire se gli admin dei server sono disposti a far giarare un mini script sulla propria macchina di questo genere. Prima di immergermi negli stude del CFQ vorrei almeno una conferma/smentita dagli admin, almeno per capire se il lavoro sarà inutile e se forse dovrei indirizzarmi ad una soluzione solo-client.

Sun Jul 29 17:22:25 CEST 2007 or3fixul
wiresharkato e confermo che trem (almeno il mio) al 100% usa UDP se si puo usare TCP, dove si imposta? il mistero di ping e fps piacerebbe svelarlo anche a me sui server italiani da quanto mi risulta io difficilmente pingo sopra 100, di solito tra 50 e 80 ma gli fps raramente sono sopra i 50 (di solito tra 20 e 40 con rovinose cadute a 6fps in mappe laggose) su server stranieri dove pingo anche piu di 100, spesso ho ottimi fps (tra 60 e 120) quindi le motivazioni riguardanti scheda video e processore mi fanno rimanere un po perplesso (se fosse computer e/o scheda video cessosi = trem cessoso su tutti i server, non solo sugli ita) ancora una volta colpa di telecom? ettecredo tutti quei kill con 90fps! il goon chompa a un chilometro

Sun Jul 29 17:31:50 CEST 2007 gattuso
quindi e da cambiare tutto in udp, anche se mi ricordo che slux aveva detto che trem usa solo tcp (scusa per la frase contorta. --------- script modficaato, riprovate, avevo confuso tcp con udp, è anche per questo che avevo chiesto un aiuto per controllare.

Sun Jul 29 17:58:15 CEST 2007 CoderNeM
Cerca, se hai tempo e proprio ti va, una soluzione solo client.

Sun Jul 29 18:33:35 CEST 2007 gattuso
ok niente server side quindi. Sarà piu dura allora (un bel po).

Sun Jul 29 18:53:14 CEST 2007 Slux
Vorresti fare magari un servizio in streeming con TCP? [img:1qc0cd6g]http://www.marmotta.ch/faccine/nondirlo.gif[/img:1qc0cd6g] Pensa a vedere una partita di calcio su aliceSerieA con TCP... alle 5 del pomeriggio, mentre io sto ancora vedendo il promo tempo, gia so tutte finite Ah si'? e quando mai l'ho detta na cazzata simile?! Credo che tu faccia un po di confusione quando una parla di TCP e TCP/IP! Una ripassatina della pila iso-osi? [img:1qc0cd6g]http://www.marmotta.ch/faccine/fagiano.gif[/img:1qc0cd6g]

Sun Jul 29 19:08:03 CEST 2007 gattuso
ho detto "mi pareva", preferivo una consultazione amichevole senza mi facessi vedere tutto il tuo nozionismo; se ci sai fare aiutami, una mano anche piccola non sarebbe male. Del resto questo script non lo faccio per me che vado con fastweb a 20 di ping ma per i poveri utenti di alice e co.

Sun Jul 29 19:29:19 CEST 2007 Slux
chiarito su PM... Cmq, non credo che la soluzione che hai adottato, anche se elegante funzioni in pratica.. questo perche' ogni ISP setta i propri router come cavolo gli pare e con le politiche che gli pare!

Mon Jul 30 15:35:01 CEST 2007 Briareos
Allora, rimettiamo un po di ordine ( scusate ma e' il mio lavoro nn riesco a starmene fuori ) TOS e' una specifica iniziale di tcp MAI implementata. TTL e' il numero di hop ( router attraversati ) massimo prima che il pacchetto venga SCARTATO prima che arrivi a destinazione. QOS serve a definire ( di solito in un router ) quali pacchetti tra le connessioni che transiatano hanno la precedenza. Questa cfg DEVE essere fatto sul router e riguarda solo le connessioni che lo attraversano ( priorita' sul suo router di casa nn significa priorita su altri router in internet ). Serve nel caso tu abbia un router di border nella tua rete e tu vogli decidere che il traffico (ad es ) voip in uscita dalla TUA rete debba pasare con precedenza ( leggi anche banda riservata o banda garantita come dicono oggi ) rispetto a altri protocolli. Se sei da SOLO sulla tua rete ( leggi modem adsl ) il qos non fa nulla. Bon avanti la prossima idea EDIT: Basta che nn resuscitate altri cadaveri come il source routing

Mon Jul 30 18:06:45 CEST 2007 or3fixul
si potrebbe dare anche un'occhiatina all'RFC per IP su piccione viaggiatore sono quasi sicuro che il succitato carrier scagazzante abbia prestazioni migliori della mia merdosa alice (e' incredibile come gli aggettivi relativi alle secrezioni anali si adattino particolarmente bene ai servizi telecom)

Mon Jul 30 18:25:10 CEST 2007 gattuso
a parte che del TOS si dice circa (it isn't WIDELY implemented, per cui traducendo alla carlona "non é implementato completamente" non sono sicuro che la frase sia esattamente quella di wikipedia ma mi ricordo l'avverbio widely alla perfezione). Saltando questo punto passiamo alla interfaccia che avevo in mente di utilizzare. Presupponendo che la teoia del QOS la so é più o meno così All'ora all'incirca è così: Il TTl lasciamolo perdere tanto piu e basso e meglio é. il TOS cambia (come scritto qua parte dell'header del pacchetto) aggiungendoci una sigla esadecimale (http://iptables-tutorial.frozentux.net/ ... TOSMATCHES) Il Qos cambia le code in uscita, qualsiasi esse siano e a quanto ne so riesce a identificare un pacchetto anche per la sigla esadecimale. Volevo utilizzarla sul server per dedicare della banda agli utenti piu bisognosi. La mia idea era di far utilizzare il TOS e il TTL alla macchina client, tanto da far creare pacchetti con la sigla esadecimale all'inizio; mentre di mettere uno script sul server che "forzi" (in parole povere) il riconoscimento dei pacchetti con TOS non normal tramite una qdisk apposita (é possibile anche se dovrei studiarmi un algoritmo che faccia al caso nostro). -------------------------------- Seconda Idea: Forse è solo una supposizione questa: spesso ho sentito dire che certe linee (come TISCALI appunto) diano la precedenza (tramite QOS dei loro router) a determinate porte di utilizzo comune (a volte peggiorando la connessione su porte alte (spesso utilizzate da programmi come DC++ e co.). La mia seconda idea sarebbe quella di provare a cambiare porta magari con una più piccola sempre UDP (mi pare, anche se non sono convinto che la imap sia una ). ---------------------------------- Terza Idea: Generalizzare lo script per le varie linee magari con un po di if & co. almeno per migliorare le prestazione della singola linea modificando l'mtu rwin e il ttl secondo il valore migliore. -------------------------------------- Quarta Idea: Sommare le precedenti per avere un riscontro più netto dopo averle magari provate una a una. EDIT: non solo un'idea ma 4.. lol EDIT2:orf3 guarda che i servizi telecom sono sicuramente meglio di quelli tiscali.. almeno per la pubblicità della brunetta (anche se l'hanno sostituita) Dove non c'è qualità c'è la fi..... mmm la fotomodella

Mon Jul 30 20:16:48 CEST 2007 zukka
Pensa che l'hanno implementato veramente con stampante -> piccione -> lettore . L'rtt era di qualche ora e un sacco di pacchetti sono andati persi Edit: typo

Mon Jul 30 22:54:16 CEST 2007 or3fixul
DOS causato da frumento sparso da qualche parte o contadino con doppietta?

Tue Jul 31 00:52:58 CEST 2007 zukka
[img:4n2o1ek7]http://www.marmotta.ch/faccine/z012-malol.gif[/img:4n2o1ek7]

Tue Jul 31 01:04:51 CEST 2007 gattuso
Zukka sei un moderator almeno te basta OT

Tue Jul 31 08:07:42 CEST 2007 zukka
Vedo che sono in buona compagnia

Sat Aug 04 23:06:59 CEST 2007 gattuso
Versione 0.2 dello script: -TTL anche in uscita -riduzione della lunghezza dello script (aggiungendo funzione generic_rulez) -supporto ai server dei (!) e dei =V= P.S. Ho eseguito inoltre dei test: sui server ita io non noto grandissima differenza (sto sui 20-30 con fastweb) si vede invece la differenza sugli altri server come quello di karma, li io pingo a 60 ma con sbalzi che arrivano a 150 con lo script si stabilizza intorno ai 50-56 e non si alza ne si vedono quei noiosi scatti a video, uguale con (!) server anche se li io laggavo pochissimo e solo a volte già prima. Ora ho bisogno di almeno due tester per ognuno di questi provider: TISCALI, FASTWEB FIBRA, ALICE, INFOSTRADA; delle altre me ne basta anche uno solo, cerco anche persone con la 56k per provare. Se possibile fatevi avanti in pm. Se la cosa si fara più seria pensero ad una interfaccia in python gtk per rendere più intuitivo il programmino e per aggiungere server al volo, per il momento va benissimo così.

Sun Aug 05 07:30:55 CEST 2007 tux [ITA]
io provo con wi-fi... lo stesso mio credo lo abbia Castyo...

Sun Aug 05 07:49:42 CEST 2007 tux [ITA]
Antilag --- Stato: Server |SST| (quello con 260 bps): 210 al posto di 215 ed evita sbalzi a 350 Server Dretch Storm: oscilla tra 210 e 250 , ogni tanto 300 ed evita continui sbalzi a 400 Server MJTavern: 65-80 invece di 70-90 (questo a server vuoto) Server Prolinux: NON ACCESSIBILE!

Sun Aug 05 10:47:17 CEST 2007 gattuso
tux sei capace di programmare?? penso che prima delle prove tu abbia cambiato le variabili dello script?? Se no lo script era tarato per questi 5 e per ciò non era neanche funzionale a quei server server: -MXB T e PVT -Prolinux -(!) Server -=V= Server

Sun Aug 05 13:50:00 CEST 2007 Briareos
Dicesi effetto placebo. Io raga ve l'ho detto... lasciate stare e preservatevi la vista, state prendendo delle cantonate... btw se vi divertite e ci passate il tempo fate pure, non nuoce a nessuno Over and out.

Sun Aug 05 14:54:31 CEST 2007 gattuso
Bah BRIA io ci provo tanto è un passatempo per migliorare il mio scripting CMQ è probabile abbia cambiato le variabili anche lui, con i commenti era palese come aggiungere un altro server P.S. cos'è sto effetto PLACEBO?? Sto cmq pensando di implementare anche una parte in cui si configura MTU e co.

Sun Aug 05 15:06:42 CEST 2007 tux [ITA]
no non so una cicca di programmazzione (un po di bash scripting), quindi ho semplicemente avviato lo scriptolo e l'ho provato. Quello che ho capito è che cambia le regole di iptables...

Sun Aug 05 15:24:39 CEST 2007 jackal@slack
Ok non intervengo piu sulla validita' dei presupposti. Volevo solo suggerire che i test vadano fatti con un certo criterio, l'affermazione "evita sbalzi" mi suona fuorviante visto anche che quei server non erano previsti nello script. Gli sbalzi li puoi avere oggi, ora, ma magari domani o tra un ora il tuo isp e' meno intasato e non li hai, lo script potrebbe non centrare nulla. Entra in uno dei server menzionati da gattuso, campa un po, salta corri ecc ma tenendo d'occhio chi hai intorno, e sempre col TAB premuto. Se il num di giocatori attorno a te cambia, devi considerarlo. Ideale e' fare una prova iniziale col server vuoto. Scassati per un minuto con TAB premuto, controlla le reazioni del ping. Abbassa trem a finestra, esegui lo script, e ora riprova sempre nelle stesse condizioni dell'ambiente. Io sono dell'idea di Bria, pero' mi piace vedere qualcuno preso da un buon proposito. Il metodo scientifico e' l'unico per una verifica che non tragga in inganno, altrimenti sono solo opinioni fuorvianti EDIT: l'effetto placebo e' quello di una finta medicina somministrata ad un malato (o un individuo convinto di esserlo) senza che lui sappia dell'inganno, che sorprendentemente rimuove i suoi sintomi. Un esempio lo vedi nel film dal romanzo di Stephen King IT: il ragazzo asmatico che ogni tanto rischia il soffocamento se non ha con se quel tubetto che sprizza un bronco-dilatatore (ehm non mi viene il nome dell'aggeggio :p). Ad un certo punto del film, gli viene sbattuto in faccia che nel "spruzzino" c'e' solo acqua e nessun bronco-dilatatore, il che comporta che gli attacchi di asma che ogni tanto lo colpiscono sono un effetto psico-somatico dovuto a forte stress. Andando un po' OT, non si tratta di "pazzia" come qualcuno potrebbe etichettarla stupidamente, in realta' una bella fetta dei dolori/fastidi/limiti che la gente vive sono dovuti ad effetti psico-somatici, solo che le case farmaceutiche che governano la nostra economia della salute ci sguazzano dentro E' meglio far capire a qualcuno la causa del suo male, avviandolo verso la guarigione, o vendergli regolarmente la pomatina/pilloletta/ecc ? Inapetenza? acidita' di stomaco? certi casi di diarrea? insonnia? la stessa psoriasi? tendenza ad ammalarsi spesso? dolori di una zona del corpo specifica non riconducibile ad una causa evidente (schiena, petto, stomaco.... ) ? Meditate...

Sun Aug 05 16:18:04 CEST 2007 gattuso
Avevo immaginato fosse qualcosa del genere: CMQ io i test li faccio senza tab (cioè con "\cg_lagometer 1" sempre attivo). I test che mi hanno mostrato effetti evidenti (ho FW e a meno di 30-20 millisec non penso andro sugli altri serve) sono stati nel =V= Server dove io laggo sempre (nel senso che anche con un ping di 50 60 mi ritrovo dall'altra parte del mono dopo aver preso un ping di 150; tenendo conto che questo accade spesso e che con lo script non accade direi che sono già ad un buon punto) Lo so che lo script non è del tutto scientifico ma è più una cosa tagliagambe: nel senso che non si interessa particolarmente del problema in se ma cerca piuttosto di migliorare la connessione tra i due ip, tuttavia vedo che lo scrpt funziona (per il mio caso, quindi non vedo il motivo di non usarlo... anche se mi aiuta solo psicologicamente) EDIT: summa= molto più semplice fare \cg_lagometer 1 che stare col tab aperto Volevo anche implementare nello script un'assegnazione automatica della coppia MTU RWIN più efficace per la linea