Torna indietro   Hardware Upgrade Forum > Networking e sicurezza > Internet provider in generale > Guide e thread ufficiali

ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR ha introdotto con Magic6 Pro la funzione Magic Portal che consente, tramite intelligenza artificiale, di suggerire scorciatoie agli utenti in modo da permettere di passare e accedere facilmente ai servizi tra app e dispositivi con un semplice tocco. Vi spieghiamo qui come funziona
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 27-08-2016, 12:12   #74901
ironmark99
Senior Member
 
L'Avatar di ironmark99
 
Iscritto dal: Jan 2015
Città: Torino
Messaggi: 1599
Quote:
Originariamente inviato da Yrbaf Guarda i messaggi
Beh l'aumento di latenza non avviene quando c'è un FEC.

Un FEC è un errore corretto SENZA ritrasmettere.
Aehm... no. Almeno se per ritrasmissione intendiamo quella che avviene tra ONU e modem, come in G.INP.

In G.INP il FEC non viene utilizzato per correggere la DTU (ossia il pacchetto di dati) corrotta ma solo per individuare quelle che contengono errore. La correzione avviene a tutti gli effetti ritrasmettendo la intera DUT. Il numero di FEC indicati dal modem di fatto coincide col numero di ritrasmissioni avvenute. Il conteggio dei CRC invece mostra il numero di DTU che non è stato possibile correggere neppure con la ritrasmissione, e che dunque dovranno essere corrette dai livelli superiori (TCP o applicativo).

Il fatto che la latenza resti bassa anche in presenza di molti FEC (e dunque ritrasmissioni) è dovuta al fatto che l'aumento di latenza di 4ms (a parte eventuali bug) non è cumulativo per OGNI ritrasmissione avvenuta, ma complessivo.

I pacchetti ricevuti vengono memorizzati in un buffer di ricezione, essenzialmente per riorganizzarli nella corretta sequenza temporale in caso di ritrasmissione. La profondità di tale buffer è ciò che introduce il massimo ritardo di picco possibile in caso di correzione (Quello massimo POSSIBILE non quello che effettivamente ci sarà, che dipende invece dal tempo di ritrasmissione, ma questo lo vedremo più tardi). Normalmente (senza errori) i dati ricevuti vengono immediatamente inoltrati in uscita, ma contemporaneamente anche accumulati nel buffer di ricezione, in cui rimangono per un tempo che dipende dalla profondità dello stesso, per poi uscirne, uno ad uno, nella stessa sequenza in cui vi sono entrati. Ogni singola DTU resta dunque nel buffer di ricezione per tutta la sua lunghezza. Individuato un errore i dati smettono di uscire direttamente, ma continuano ad accumularsi nel buffer di ricezione. Il modem chiede il reinvio del pacchetto errato e attende che il pacchetto corretto arrivi. Al suo arrivo il pacchetto errato presente nel buffer di ricezione viene sostituito da quello corretto, lì, nel posto in cui nel frattempo è arrivato. A questo punto tutta la parte di buffer di ricezione accumulata nell'attesa e non ancora inviata, può essere trasmessa all'uscita (ovviamente di gran carriera) e i dati ricevuti possono essere nuovamente inviati direttamente in uscita.

Guardando solo l'uscita si noterà dunque che ad un certo punto il flusso dati alla normale velocità si interrompe, e per un tempo pari al tempo del reinvio del pacchetto corretto non arriveranno altri dati. Improvvisamente poi i dati riprenderanno a fluire, ancora nella corretta sequenza di invio, a velocità molto superiore al normale, sino a riprendere, ad un certo punto la velocità normale. Questo effetto di "pompaggio" si chiama jitter, ed ha introdotto un picco di latenza di 4ms.

Ovviamente durante i 4ms di "blackout" sui dati in uscita, ossia nella attesa della ritrasmissione di una DTU corretta, è possibile che altre DTU in arrivo siano errate e se ne debba richiedere la ritrasmissione. Nel caso in cui ciò accada, all'arrivo della prima DTU corretta, il buffer di ricezione viene ributtato all'uscita non completamente, ma solo sino alla posizione della seconda DTU da correggere, che poiché la prima è appena arrivata, dovrà ancora arrivare. Guardando l'uscita del modem si vedrà dunque come prima, una improvvisa interruzione del flusso dei dati dovuto alla attesa della prima DTU corretta, poi un improvviso riprendere del flusso dati a velocità elevata, ma per un totale di solo una parte dei dati mancanti all'appello, per poi reinterrompersi. Finché però il tempo di ritrasmissione non eccede mai i 4ms, anche la latenza non eccede mai questo valore. Semplicemente il jitter, sin ché continuano ad arrivare DTU errate, continua ad "pompare" tra un minimo di 0 ad un massimo di 4ms.

A 100Mbit/s le DTU sono circa 700/s (ogni DTU contiene 65byte di payload più alcuni byte di overhead). Virtualmente il meccanismo sarebbe in grado di correggere tutte le DTU errate, ma almeno due fenomeni lo impediscono.

Il primo dipende dal fatto che anche le DTU ritrasmesse possono essere corrotte dal rumore durante la ritrasmissione. Per limitare questa possibilità esse viaggiano su un canale riservato (bearer1) sul quale la protezione dall'errore è data da un meccanismo più potente di correzione immediata (extended Golay code) al quale si devono i 4ms di latenza di questo canale (2 per direzione, tra richiesta e renvio). Infatti il ritardo nella ritrasmissione non è certo dovuto al tempo di transito del segnale sul cavo, tempo che si misura in microsecondi al chilometro. Tuttavia anche questo metodo non è infallibile e può capitare che, per disturbi particolarmente grandi, una DTU ritrasmessa venga corrotta nella ritrasmissione e dunque debba nuovamente essere richiesta. Ciò porterebbe il ritardo di ritrasmissione al doppio del normale (8ms) e nel frattempo la DTU corrotta immagazzinata nel buffer di ricezione potrebbe esserne già fuoriuscita (dipende dal dimensionamento della profondità del buffer) e a quel punto si avrebbe un CRC, ossia la presenza di una DTU non corretta. Tuttavia se il buffer di ricezione fosse dimensionato per contenere almeno 8ms di DTU, non si avrebbe il CRC, ma un picco di latenza di 8ms. Questo raddoppiarsi della latenza dovuta alla ritrasmissione sarebbe comunque un fenomeno molto raro (dato che una doppia ritrasmissione non dovrebbe accadere se non in casi estremi), e che sposterebbe di pochissimo la latenza media.

Il secondo fenomeno che rende impossibile correggere tutte le DTU è che il bearer1, su cui viaggiano le ritrasmissioni, sottrae banda al bearer0 su cui viaggia il normale flusso dati. Se si dovessero ritrasmettere tutte le DTU (a causa di un rumore impulsivo davvero grave) in pratica si dimezzerebbe il bitrate del canale, portando l'overhead del meccanismo a valori troppo elevati (anche se si tratterebbe di un overhead dinamico, presente solo in caso di disturbi davvero imponenti). Si preferisce dunque limitare il massimo possibile bitrate sostenibile dal bearer1 ad una frazione (che non conosco) del massimo bitrate del canale. Questa operazione di fatto limita il numero massimo di errori correggibili nell'unità di tempo.

Questa è la descrizione di come ho inteso il meccanismo del G.INP... e ovviamente è, come sempre, salvo errori od omissioni.
__________________
Il mio PC autocostruito e raffreddato ad acqua: http://irom.eu/w --- Qui tutti i miei interventi su HU --- Modem reader: qui l'installer e qui l'help on line --- Qui il simulatore VDSL v3.0

Ultima modifica di ironmark99 : 27-08-2016 alle 12:19.
ironmark99 è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:23   #74902
giovanni69
Senior Member
 
L'Avatar di giovanni69
 
Iscritto dal: Jun 2005
Messaggi: 21829
O.T. Una delle cose più disastrose di questo forum che pur fornisce un incredibile servizio a noi tutti, è il fatto che si accedano ai post di ironmark solo dall'inizio dell'anno.. le solite 25 pagine. Grazie ironmark99!!!
E non me ne vogliano gli altri a partire in primis da diaretto & C. che pur ci aiutano tutti con generosità, competenza e... pazienza!
giovanni69 è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:25   #74903
corra98
Senior Member
 
L'Avatar di corra98
 
Iscritto dal: Dec 2015
Città: Piacenza
Messaggi: 494
Quote:
Originariamente inviato da drunkct Guarda i messaggi
Dallo screen vedo 3,8 e 10,3.
Ops, me l'ero perso. Grazie
__________________
TIM FTTC 100/20 dal 7/01/16. Aspettando OpenFiber...
corra98 è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:26   #74904
oxidized
Senior Member
 
L'Avatar di oxidized
 
Iscritto dal: Nov 2013
Messaggi: 1455
Devo dire che di solito preferisco forum stranieri, ma quando si parla di certi argomenti, davvero non credo ci siano paragoni rispetto quello che ho trovato su questo forum e su questo thread in particolare. Davvero, grazie
Italians do it better
oxidized è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:27   #74905
drunkct
Member
 
Iscritto dal: Oct 2014
Messaggi: 54
Quote:
Originariamente inviato da oxidized Guarda i messaggi
Giusto per essere precisi, quale sarebbe questa risposta aggressiva? Perché ho controllato i vecchi post, e non c'è niente di simile. Anzi ho risposto a te consigliandoti di usare la funzione "cerca nella discussione"



Allora semplicemente c'è quasi niente di diafonia stando alla tabella di ironmark, ottimo!
Molto probabile...considera che l'armadio dai file risulta attivo da questo mese.

Inviato dal mio SM-G930F utilizzando Tapatalk
drunkct è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:28   #74906
Psyred
Senior Member
 
L'Avatar di Psyred
 
Iscritto dal: Dec 2004
Messaggi: 15570
Secondo me invece i FEC non rappresentano ritrasmissioni a livello fisico tra CPE e dslam, ma errori corretti dalla Forward Error Correction, oppure i byte usati per quel processo.

Anch'io ho avuto quel dubbio, ma recenti letture sul G.INP e anche il comportamento stesso della connessione mi fanno pensare che le ritrasmissioni siano in numero più limitato di quanto si pensi.

Per esempio, com'è possibile che la latenza aumenti di quei 4 ms e tale rimanga a tempo indeterminato? Addirittura a me succede 9 volte su 10 anche quando riavvio il router, pure quando lo ho sostituito con il nuovo la latenza era aumentata dei consueti +4 ms (per scendere dopo, ma solo per brevi periodi).
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing]
Psyred è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:44   #74907
Psyred
Senior Member
 
L'Avatar di Psyred
 
Iscritto dal: Dec 2004
Messaggi: 15570
Riquoto qui il brano di un articolo che avevo già linkato e citato una settimana fa:

The first layer of G.inp's protection uses a combination of a strong Reed-Solomon Forward Error Correction (FEC) encoding scheme that hardens packets against multiplebit errors and a retransmission scheme to recover packets that are unrecoverable with FEC coding. When a VDSL transceiver encounters persistent, severe impulse noise, interleaving techniques are also employed to further harden the channel against data loss.

http://www.ospmag.com/issue/article/Saving-Coppers-Life

Quindi secondo questo autore in teoria già la FEC dovrebbe essere sufficiente di per sè a salvaguardare l'integrità di buona parte dei pacchetti, ricorrendo limitatamente alla ritrasmissione e in extrema ratio anche a tecniche di interleaving.

Ecco perchè mi torna poco questo discorso dei FEC.
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing]

Ultima modifica di Psyred : 27-08-2016 alle 12:52.
Psyred è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 12:54   #74908
oxidized
Senior Member
 
L'Avatar di oxidized
 
Iscritto dal: Nov 2013
Messaggi: 1455
Quote:
Originariamente inviato da Psyred Guarda i messaggi
Riquoto qui il brano di un articolo che avevo già linkato e citato una settimana fa:

The first layer of G.inp's protection uses a combination of a strong Reed-Solomon Forward Error Correction (FEC) encoding scheme that hardens packets against multiplebit errors and a retransmission scheme to recover packets that are unrecoverable with FEC coding. When a VDSL transceiver encounters persistent, severe impulse noise, interleaving techniques are also employed to further harden the channel against data loss.

http://www.ospmag.com/issue/article/Saving-Coppers-Life

Quindi secondo questo autore in teoria già la FEC dovrebbe essere sufficiente di per sè a salvaguardare l'integrità di buona parte dei pacchetti, ricorrendo limitatamente alla ritrasmissione e in extrema ratio anche a tecniche di interleaving.

Ecco perchè mi torna poco questo discorso dei FEC.
Potrebbe anche essere che questa sia la differenza che usano i vari modelli technicolor (nei vecchi i FEC erano molto maggiori, in quello nuovo sono conteggiati in modo diverso mi sembra?)
oxidized è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 13:02   #74909
Psyred
Senior Member
 
L'Avatar di Psyred
 
Iscritto dal: Dec 2004
Messaggi: 15570
Quote:
Originariamente inviato da oxidized Guarda i messaggi
Potrebbe anche essere che questa sia la differenza che usano i vari modelli technicolor (nei vecchi i FEC erano molto maggiori, in quello nuovo sono conteggiati in modo diverso mi sembra?)
Io a dire il vero ho sempre avuto il "vecchio", il nuovo modello ce l'ho da pochi giorni. A livello di FEC non mi sembra di notare particolari differenze comunque.
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing]
Psyred è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 13:17   #74910
oxidized
Senior Member
 
L'Avatar di oxidized
 
Iscritto dal: Nov 2013
Messaggi: 1455
Quote:
Originariamente inviato da Psyred Guarda i messaggi
Io a dire il vero ho sempre avuto il "vecchio", il nuovo modello ce l'ho da pochi giorni. A livello di FEC non mi sembra di notare particolari differenze comunque.
Boh, io per quei pochi giorni che ho provato il nuovo, m'è sembrato di leggere valori FEC totalmente diversi, probabilmente mi sbaglio, comunque la differenza c'è tra i technicolor e altri (non so quali) modem, a quanto pare i tc conteggiano in un modo particolare, questo è quello che leggevo in questo thread diverse pagine fa
oxidized è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 13:20   #74911
Psyred
Senior Member
 
L'Avatar di Psyred
 
Iscritto dal: Dec 2004
Messaggi: 15570
Quote:
Originariamente inviato da oxidized Guarda i messaggi
Boh, io per quei pochi giorni che ho provato il nuovo, m'è sembrato di leggere valori FEC totalmente diversi, probabilmente mi sbaglio, comunque la differenza c'è tra i technicolor e altri (non so quali) modem, a quanto pare i tc conteggiano in un modo particolare, questo è quello che leggevo in questo thread diverse pagine fa
Io però ho sempre un Technicolor (quello nuovo) con gli altri due è possibilissimo che ci siano differenze. Con uno di quelli anche attenuazione e INP vengono calcolati in modo diverso per esempio.
__________________
WindTre FTTH 1000/200 Mb - ONT Huawei EG8010H - Fritz!Box 7590 [TEST][Latenze/Routing]
Psyred è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 13:25   #74912
oxidized
Senior Member
 
L'Avatar di oxidized
 
Iscritto dal: Nov 2013
Messaggi: 1455
Quote:
Originariamente inviato da Psyred Guarda i messaggi
Io però ho sempre un Technicolor (quello nuovo) con gli altri due è possibilissimo che ci siano differenze. Con uno di quelli anche attenuazione e INP vengono calcolati in modo diverso per esempio.
Io avevo il technicolor più vecchio di tutti, e l'ultimo, m'è sembrato che qualche differenza c'era, ripeto, non sono sicurissimo.
oxidized è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 13:35   #74913
Busone di Higgs
Senior Member
 
L'Avatar di Busone di Higgs
 
Iscritto dal: Jun 2016
Città: PD province
Messaggi: 2160
Secondo un semplice conteggio, sembra che gli errori FEC non richiedano nessuna correzione a meno che falliscano, poi se il modem conti anche quelli falliti non lo so, ma visti i numeri e' ininfluente:
prendo in esame i dati postati di quella linea qualche fa e faccio un calcolo semplicissimo:

Up time: 181395
Total FEC Errors: 127044668

che significa 700.37 fec corretti al secondo

Inronmark infatti riporta che le a 100Mbit/s le DTU sono circa 700/s

Visti i crc, la quantita' di pacchetti che devono essere trasmessi e' pari a 0,385 al secondo, ed ecco che diventa difficile apprezzare delle perdite, e del fatto che la mia e la sua linea si equivalgono in prestazioni.

Fra l'altro vi ringrazio perche' con le informazioni che mi avete fornito comincio a capire l'origine del problema:
nessun pacchetto o raramente i pacchetti arrivano integri, piu' del 99% dei pacchetti viene corrotto ma solo lo 0,05% circa richiede la ritramsissione e quindi anche il suo ping non differisce dal mio.

Dato che tutti i pacchetti vengono danneggiati e son oquasi sempre riparabili devo cercare un'interferenza che genera un impulso molto stretto e a elevata frequenza, lavoro da vent'anni in elettronica e ipotizzo che al 90% c'e' un alimentatore switching senza presa di terra (noncnecessariamente) con il condensatore del circuito primario in perdita e che deve essere collegato nei pressi del cavo direte alimentazione che affianca il doppino.

edit: la correzione dei fec usa l'algoritmo di Reed Solomon, richiede un doppio overhead che puo essere variabile di dimensione, confermato anche da Ironmark qualche post fa, ma la dimensione dei due gruppi ridondanti non e' scritta da nessuna parte, forse viene decisa quando viene creato il profilo; il maggiore indagato all'origine delle interferenze adesso e' un gruppo di continuita' del tipo always-on-line a sinusoide perfetta; questo tipo di gruppo e' sempre attivo nel senso che la tensione viene abbassata e poi rialzata senza mai bypassare il circuito, quindi ha due trasformatori, ma per generare una sinusoide perfetta in uscita pilota un trasformatore da 50hz con un pwm sui 20khz in modo da non generare un fischio udibile, e questo potrebbe essere la fonte di interferenza; in questo caso aiuta la codifica di trellis che sparge i bit secondo un ordinamento preciso, il picco che arriva dal pwm dell'ups ha una certa larghezza e danneggerebbe una serie di bit consecutivi rendendo impossibile la correzione precedente, invece questi bit dopo la ricodifica trellis risultano sparsi e la reed solomon riesce a correggere piu' del 99% come verificato sopra.
Sempre se confermato il meccanismo di funzionamento ovviamente..............

edit: con i nuovi numeri piu' precisi forniti da Ironmark i conti sono tutti da rifare, ma stasere ho la sindrome dello zombie perche' e' l'ultimo giorni di ferie...........

Ultima modifica di Busone di Higgs : 28-08-2016 alle 19:18.
Busone di Higgs è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 14:17   #74914
BIGGlive360
Senior Member
 
L'Avatar di BIGGlive360
 
Iscritto dal: Jul 2009
Messaggi: 739
Quote:
Originariamente inviato da rokis Guarda i messaggi
Ciao ragazzi un'informazione, chi di voi ha la XBOX ONE collegata via LAN?
A quanto scaricate?
Io da speed test su PC faccio 94 95, ma sulla xbox non scarica a più di 50Mbps, lo fa anche a voi?
Ciao e grazie!
ciao io ho la ps4 e leggevo che secondo molti il psn è limitato a 7/7.5 (tradotto in bit 7*8=56 che è poco più dei 50 che dici tu) probabilmente è lo stesso su xbox. niente di ufficiale però per quanto ne so.
probabile che limitano la banda per non intasare i server e consentire a più persone contemporaneamente di usufruire del servizio.

facendo un es. molto semplificato, se il server può erogare 10mb/s loro preferiscono far connettere 10 persone a 1mb/s piuttosto che una sola a 10mb/s. certo a 10mb/s finisci prima e lasci il posto a un altro, ma nel frattempo gli altri 9 restano fermi e allora meglio un servizio limitato a tutti che un servizio ottimo per qualcuno e disservizio agli altri
__________________
[Cooler Master Centurion 5] [Cooler Master B700 V2] [Intel Core i5 750] [AC Freezer Xtreme Rev. 2] [Gigabyte GA-P55M-UD4] [2x2Gb G.Skill Ripjaws 1600Mhz cl9] [Sapphire Ati Radeon HD6870] [Maxtor 320Gb + Seagate 200Gb] [DeLL U2414H] [Enermax Aurora Premium] [Windows 7 Home Premium 64bit] GAMERTAG XBOX360 PSN ID
BIGGlive360 è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 14:19   #74915
Besk
Senior Member
 
L'Avatar di Besk
 
Iscritto dal: Feb 2001
Città: Vicenza
Messaggi: 5240
Io ho questi valori



Cabinet a 500 metri e linea VDSL naked

e da due giorni ho questi errori, come vi sembrano?

__________________
Corsair 4000d Airflow | AMD Ryzen 7 5800x | Asus TUF GAMING B550-PLUS | Corsair iCUE H115i Elite + LCD Upgrade Kit | 32 GB Corsair Vengeance LPX DDR4 3600MHz | nVidia Geforce 3070ti FE | Corsair RM750X | Samsung 980 PRO NVMe M.2 SSD 1 TB + Crucial MX500 1TB | LG 27GL83A | Logitech G915 | Logitech G Pro Wireless + Logitech G440 Gaming Mouse Pad |
Besk è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 15:08   #74916
Barrys
Member
 
Iscritto dal: Aug 2016
Messaggi: 92
Quote:
Originariamente inviato da ironmark99 Guarda i messaggi
Vorrei chiarire un concetto, che forse non è così immediato. La cosa migliore senza dubbio è non avere derivazioni sul proprio cavo. Quindi, nel caso ci si trovi su un doppino che ha una derivazione, se si ha la possibilità di farsi fare un cambio coppia questa è assolutamente la cosa da fare, e farsi migrare su un doppino senza derivazioni. Se non c'è questa possibilità, non vale la pena farsi spostare da un ramo all'altro della biforcazione.

Cioè, in pratica, se arrivati ad un certo punto il proprio doppino di "biforca", non cambia un granché l'essere su un ramo o sull'altro: resta sempre un pezzo di linea morta appesa al nostro collegamento. Le cose possono leggermente cambiare perché i due tratti con buona probabilità, saranno di lunghezze diverse.

Supponiamo che il doppino si biforchi ad un certo punto in due tratte, una lunga 50 metri e l'altra 60 metri. Avere il modem al termine della biforcazione lunga 50 metri significa avere un pezzo di linea lunga 60 metri morta e penzolante sul nulla. Avere il modem al termine della biforcazione lunga 60 metri significa avere un pezzo di linea lunga 50 metri morta e penzolante sul nulla.

Cambierà un po' la frequenza a cui avrò un buco sulla attenuazione (830kHz circa se ho la tratta penzolante lunga 50m, 690 kHz se ho la tratta penzolante lunga 60m) ma sempre un buco nella attenuazione mi becco. Quale delle due situazioni è meglio? Nessuna in particolare. Forse le prestazioni cambiano un po' (ben poco, salvo casi particolari) ma sinceramente sapere se è meglio restare sulla derivazione su cui si è già o farsi spostare sull'altra (sempre sia possibile) dipende da caso per caso e dalle due lunghezze. Anche se le due lunghezze fossero molto diverse, dire a priori se sia meglio avere un pezzo di derivata corto o uno lungo è ben difficile. E comunque un bel degrado resta.

L'unica vera soluzione è farsi rimuovere del tutto la tratta penzolante, intervento che a quanto mi pare di capire TIM non sia disposta a fare.
Sono andato a lurkare il tuo discorso in questo post e quelli precedenti dove spiegavi come funzionano le chiostrine derivate.
Io sono in derivazione secondaria (con 2 pallini in pratica): considerando che il cabinet dalla mia chiostrina dista 250 metri a stare larghi (in linea d'aria saranno 150 metri), io avrò comunque un'attenuazione altissima?
Vale la pena andare in VDSL? ma soprattutto, c'è una qualche correlazione tra come andavo in ADSL e come andrei in VDSL considerando che il problema qui sta in un tratto che non viene modificato?
Barrys è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 15:23   #74917
babene
Senior Member
 
L'Avatar di babene
 
Iscritto dal: Dec 2010
Messaggi: 570
Speriamo che da lunedi riprendono ad aggiornare i file e rendano verde il mio semaforo
__________________
Tim FTTH profilo 1000/300
babene è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 15:27   #74918
diaretto
Senior Member
 
Iscritto dal: Dec 2010
Messaggi: 3362
Quote:
Originariamente inviato da Barrys Guarda i messaggi
Sono andato a lurkare il tuo discorso in questo post e quelli precedenti dove spiegavi come funzionano le chiostrine derivate.
Io sono in derivazione secondaria (con 2 pallini in pratica): considerando che il cabinet dalla mia chiostrina dista 250 metri a stare larghi (in linea d'aria saranno 150 metri), io avrò comunque un'attenuazione altissima?
Vale la pena andare in VDSL? ma soprattutto, c'è una qualche correlazione tra come andavo in ADSL e come andrei in VDSL considerando che il problema qui sta in un tratto che non viene modificato?
No a tutte le tue domande. Tranne che si, certo che vale la pena anche per te la VDSL.

Non avrai un'attenuazione alta per via della derivazione, avrai un buco nell'attenuazione ad una certa frequenza e vari sottobuchi a multipli del primo picco.

Questo ti fa perdere ovviamente Mb di banda rispetto a non avere la derivazione.

No non puoi desumere nulla sulla VDSL partendo dall'ADSL, non c'entra nulla il tratto di derivazione in comune, anche perchè in ADSL essendo frequenze circa 1/8 più basse gli effetti delle derivazioni sono diverse, potresti non "vederla" sulla tua linea una certa derivazione.
__________________
CPU: i5 760 MOBO: P7P55D-Deluxe RAM: Corsair DDR3 Dominator 1600MHz CL7 VGA: Radeon HD 6870 DISSI: Arctic Cooling Freezer Xtreme SSD: Samsung 840 HD: 2x Seagate 280GB RAID 0 ALI: Cooler Master 700W Modulare
diaretto è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 15:36   #74919
zdnko
Senior Member
 
Iscritto dal: Nov 2013
Messaggi: 2486
Quote:
Originariamente inviato da diaretto Guarda i messaggi
Ottimo! Tecnico di sabato per intervento personale mi è nuova, davvero fortunato!
I tecnici sono in turno anche la domenica!
zdnko è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2016, 15:38   #74920
babene
Senior Member
 
L'Avatar di babene
 
Iscritto dal: Dec 2010
Messaggi: 570
Il sabato si, la domenica solo per le emergenze.
__________________
Tim FTTH profilo 1000/300
babene è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
Recensione HONOR Pad 9: ampio display e audio top per il tablet per l'intrattenimento Recensione HONOR Pad 9: ampio display e audio to...
Tutti i dispositivi Ring in offerta: cit...
AI PC, le caratteristiche dietro a una d...
AirPods e iPhone 15 in offerta: modello ...
Offerta Ring Intercom ed Echo Pop: se co...
Tesla bot Optimus: ecco quanto costa il ...
ECOVACS DEEBOT T30 PRO OMNI con sconto d...
Disney+: perché il colosso ha cam...
Prezzo bomba per Google Pixel 8: ora cos...
Google Pixel 9 arriverà in tre ve...
One UI 6.1 con Galaxy AI da oggi, 28 mar...
Ninja, il famoso streamer ha scoperto di...
Xi Jinping: nessuno può fermare i...
Un veicolo elettrico su quattro venduto ...
Super portatile HP a prezzo di svendita:...
Motorola spopola su Amazon: prezzi assur...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 09:53.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www1v