Visualizzazione Stampabile
-
Citazione:
Originariamente scritto da Riker
Non è cosi' semplice (sarebbe bello :) ).
Tieni presente che c'è da considerare lo "Initialization vector" dell'RC4 (comunque ogni algoritmo di criptazione strong aumenta di un po' la lunghezza del dato), l'incapsulamento dei pacchetti aumentato, l'eventuale scambio di autenticazioni, l'eventuale server per lo scambio delle chiavi...
Insomma un po' di robetta in piu' c'è con la criptazione
:)
Sì, ma tutte queste cose non fanno parte del payload criptato: sono preparazione e impacchettamento dello stesso. Certo, tutte queste cose poi rientrano nel calcolo del traffico dati effettivo: ma proprio per questo, che c'entra con la diminuzione dei dati trasmessi/ricevuti? Giacché questi SONO dati a tutti gli effetti, e non credo che la routine che rileva i dati in entrata nel client faccia discriminazione fra dati "reali" e dati che rientrano nell'uso della crittazione stessa (voglio dire, una pacchetto è un pacchetto, che sia crittato, non crittato, di initialization vector etc).
Se riceve 6Mb/s in pacchetti di dati, poi magari posso anche essere solo 5 di dati "utili", ma la routine cmq deve rilevare 6Mb/s...
-
Citazione:
Originariamente scritto da PynkyZ
Se riceve 6Mb/s in pacchetti di dati, poi magari posso anche essere solo 5 di dati "utili", ma la routine cmq deve rilevare 6Mb/s...
Se consideri il lordo hai ragione, lui trasmette comunque a velocità x che sia criptato o meno.
Solo che se è criptato a questo x va levato y per trovare i byte netti utilizzabili.
La velocità che vedi (poi questo dipende dal produttore/software/etc.) dovrebbe essere quella reale e non il lordo.
Comunque se intendiamo la velocità lorda concordo con te che non cambia, quella netta invece diminuisce (anche se non di tantissimo).
;)
-
Veramente, per quel che so io, dovrebbe essere rilevato il lordo (ovvero il numero totale di pacchetti, indipendentemente dalla "qualità" dei pacchetti). Almeno sotto ambiente Windows...
-
Citazione:
Originariamente scritto da PynkyZ
Veramente, per quel che so io, dovrebbe essere rilevato il lordo (ovvero il numero totale di pacchetti, indipendentemente dalla "qualità" dei pacchetti). Almeno sotto ambiente Windows...
Come numero di pacchetti si, di solito invece come byte sono i byte dati puri.
Poi anche li dipende da chi fa il sum (se la scheda, un driver, l'applicativo), ossia se somma i pacchetti totali arrivati o li distingue per errori, CRC, dropped, retrasmitted, etc...
Se ti da la velocità pura o i byte reali al secondo.
Se sono i byte che legge un applicativo da uno stream (quindi puliti di tutto).
Quello che ho notato statisticamente (poi non è che mi sia mai fermato a fare troppi controlli, solo che a forza di guasti è una cosa che mi è saltata all'occhio. Ma non ho mai cercato prove certe ;) ) è che l'RX byte indica il netto dei byte ricevuti, in TX byte il lordo inviato (del resto non può sapere quali vanno bene e quali no).
Quindi la velocità di DL dovrebbe essere il netto e quella di UP il lordo.
Poi, ripeto, dipende da tantissimi fattori.
:)
-
Allora ragazzi...vi ringrazio per i chiarimenti che sicuramente mi saranno utili in futuro:cool:
Per il mio problema in particolare invece è legato ad un applicativo più che alla rete. Infatti stavo sperimentando per la prima volta eMule Adunanza per vedere se si trovava materiale hdtv scaricabile legalmente (cerco o apro un altra discussione che qui sono auto off-topic) ed è il programma che mi "sega banda" (non ho approfondito la cosa). Chiuso il programma e provato un normale download (xpsp2 con getright) e la velocità è stabile sui 5,65Mb/s.
Cià.
