Perché la discrepanza tra Speedtest e Wget?


18

Il mio cliente si lamenta delle basse velocità di Internet. Se misurato con Speedtest.net, le velocità sono accettabili. I download misurati periodici vanno dal 10% al 30% della velocità nominale. Non posso spiegarlo.

Qualche sfondo. La problematica connessione si trova in una di quelle soleggiate isole dei Caraibi dove Internet veloce non è la risorsa migliore. Ultimamente la velocità di Internet è diventata decente, fino a 200 Mbps. Ma il ping round trip per (diciamo) Amsterdam è di circa 180 ms.

Il cliente ha una connessione in fibra a 100 Mbps. Quando si esegue uno speedtest su un computer Windows (speedtest.net) all'ISP CO, si ottengono 95 Mbps. Quando si utilizza lo stesso test di velocità per Amsterdam, si raggiungono 60-70 Mbs. Pienamente accettabile

Qualche tempo fa ho installato un RasPi che periodicamente guadagna un file da uno dei miei server di Amsterdam. In un datacenter, che è direttamente collegato a AMS-IX. Usando questo comando:

wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt

Il file .txt è 23 MB di numeri. (In realtà è l'unico ma il più grande Mersenne Prime, 23e6 cifre)

Quando scarico quel file sulla rete problematica, wget segnala questo:

dev/null 100%[====================================================================>]  22.81M  11.6Mb/s   in 17s    

2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]

Questo è allo stesso tempo speedtest.net riporta 60-70 Mbps.

So che il Raspi ha i suoi limiti. Ma questa velocità varia selvaggiamente. Una volta il RasPi riporta questo 11 Mbps, la volta successiva 22 Mbps. Ma a volte fino a 1,5 Mbps.

inserisci qui la descrizione dell'immagine

Quando eseguo questo test con un laptop davvero potente, le velocità massime sono leggermente più alte (fino a 30 Mbps), ma mostrano anche gli stessi bassi. Quindi indica una limitazione RasPi nella parte alta, ma non i 10 Mbps nella parte bassa.

Ho emesso esattamente lo stesso comando da un server a München, in Germania, in un datacenter. Velocità 96 Mbps.

Quindi da una connessione in fibra di consumo da 100 Mbps nei Paesi Bassi: 65 Mbps.

Quindi, a casa mia che ha un ADSL a 10 Mbps nominali. Speedtest mostra 10 Mbps. Wget fornisce 8,5 Mbps. Che è uguale nel mio libro.

Ciò preclude qualsiasi limitazione sul server che funge da host per il download del file.

Non mi aspetto che qualcuno possa segnalare la causa della lentezza della connessione presso la sede del cliente. Qualcuno può spiegare la discrepanza tra speedtest.net e wget?

C'è qualcosa che lo speedtest ignora o misura solo i picchi? O wget è seriamente influenzato da lunghi tempi di ping?

Sento che il test wget fornisce la velocità reale ed effettiva, mentre lo speedtest serve principalmente a mostrare la velocità pubblicizzata.


Un altro modo per verificare la velocità è quello di farlo ssh personal-server cat /dev/zero | pv > /dev/null, su un server personale che sai non è limitato a essere più lento della velocità che ti aspetti.
JoL

Ho scremato la tua domanda. E sembra che tu abbia una grande larghezza di banda e forse uno scenario di ritardo di andata e ritorno significativo noto anche come "rete long fat". Ho sperimentato personalmente questo genere di cose e l'ho risolto aprendo molte connessioni (ho usato rsync). Puoi provare ad aprire molte istanze di wget (prova 5, 10, 20)? La pagina Wikipedia è: prodotto di ritardo di larghezza di banda.
Trevor Boyd Smith,

Wget riporta di default i byte: [james @ lamia root] $ wget -O / dev / null 10.32.48.1/t1 / dev / null 100% [================= ====>] 100,00 MB 112 MB / s in 0,9s [james @ lamia root] $ wget --report-speed = bit -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100,00 M 932 Mb / s in 0,9s
james

Prendi in considerazione l'esecuzione di un server iperf per tcp e un secondo per udp sul tuo computer host DC. Quindi, come parte del lavoro cron, chiama un test dal tuo client e vedi come le velocità si confrontano con quelle ottenute da http.
Criggie,

Che tipo di file è comunque? È comprimibile e il server supporta la compressione http? Sebbene non sia possibile risolvere i problemi di larghezza di banda, è possibile ridurre le dimensioni del file.
Salman,

Risposte:


16

Oltre agli altri motivi pubblicati, le connessioni TCP non funzionano bene con file di grandi dimensioni quando il prodotto con ritardo di larghezza di banda diventa grande.

Come su una connessione altrimenti veloce con un'isola.

Vedi la voce di Wikipedia sull'ottimizzazione TCP .

Quindi Speedtest può scaricare un piccolo file attraverso la connessione a 95 mb / sec, ma wgetpuò ottenere solo 10 mb / sec su un file da 20 MB.


2
Questa è una nuova conoscenza per me. Molto buona. In effetti, il prodotto con ritardo di larghezza di banda è elevato (2,25 MB se calcolato correttamente). Una rapida occhiata ha mostrato un buffer predefinito di 87kB e un massimo di 3,5 MB. (Suppongo che Byte non bit). Devo approfondire questo aspetto per valutarlo meglio. Se, in combinazione, speedtest scarica molti file di piccole dimensioni e registra la velocità massima, ciò spiega molto.
Hans Linkels,

21

Gli ISP spesso danno la priorità al traffico su speedtest.net in modo che possano vantarsi della velocità con cui le loro connessioni sono, mentre in realtà non forniscono molta larghezza di banda. Sono perfettamente consapevoli del fatto che la maggior parte degli utenti controllerà tale sito solo per conferma.

È inoltre necessario tenere presente che la velocità di trasferimento dipende sia dal client che dal server. Nel mondo di oggi la maggior parte dei server rallenta in un modo o nell'altro.

Infine, è inutile aspettarsi una larghezza di banda stabile per le connessioni all'estero. Non c'è proprio niente del genere. Deve passare attraverso un numero infinito di switch, fibre, datacenter per raggiungere la posizione finale. E tutto ciò che serve è solo una parte in movimento per rallentare.


Comprendo le tue dichiarazioni, ad eccezione della limitazione sul lato server. È il mio server e quando il client si trova in un data center diverso (a circa 1200 km di distanza) la velocità è costantemente di 95 Mbps. Anche se il client è su una connessione consumer a 100 Mb, è di 65 Mbps.
Hans Linkels,

9
Puoi documentare la tua richiesta? "Gli ISP spesso danno la priorità al traffico su speedtest.net"
Soleil,

1
@Soleil Non ci è voluto troppo googling: myce.com/news/…
MonkeyZeus

6
Un ISP che assegna la priorità al traffico più veloce è tanto probabile quanto un importante costruttore di autoveicoli che simula i test delle emissioni.
Barmar,

3
Aneddoticamente, una volta sono stato in grado di "riparare" un flusso di Super Bowl balbettante inviando ripetutamente il traffico a speedtest.net da un Raspberry Pi. Sembrava che avessero dato la priorità a tutta la mia connessione purché fosse presente il traffico più veloce - differenza di giorno e di notte. Non sono molte prove che gli ISP facciano cose losche, ma è qualcosa.
Annulla il

7

wgetdare una buona misura pratica della velocità. I test di Speedtest probabilmente includono un tipo di parallelismo che può spiegare numeri più alti.

Per un buon test di velocità media penso che il tempo per il download dovrebbe essere di almeno 90-120 secondi (per ottenere una buona media)


Sto lavorando per installare un computer di registrazione più potente e per aumentare le dimensioni del file.
Hans Linkels,

Puoi sviluppare un "tipo di parallelismo"? Non vedo alcun modo / ragione poiché esiste una connessione a priori 1.
Soleil,

1
@Soleil, IMHO scaricano pochi file, non solo uno. Puoi provarlo eseguendo pochi wgete sommando la velocità
Romeo Ninov

1
Potrei parallelizzare la mia misurazione, ma qual è il vantaggio? Ho già dimostrato che altri clienti raggiungono la massima velocità. La differenza è che la connessione problematica ha una latenza di 180 ms. Le connessioni veloci <10 ms. Parallelamente ridurrebbe gli effetti di latenza? Solo per chiedere.
Hans Linkels,

1
@RomeoNinov Ho controllato, non esiste un parallelismo del genere (speedtest.net). Un file per upload e uno per download ([1-2] MB ciascuno).
Soleil,

3

Un motivo potrebbe essere che spesso la massima velocità non può essere raggiunta da una sola connessione TCP.

Speedtest.net ha recentemente introdotto una modalità di connessione singola. Prova questo e vedi se fa la differenza.

Quindi, per il download, utilizzare ad esempio aria2 con parametri per utilizzare più connessioni e confrontare. per esempioaria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt


2

Usa Fast.com Internet Speed ​​Test , questo è un test di velocità basato su Netflix che significa che non può essere differenziato dagli ISP dallo stesso Netflix.

Questo è un test più accurato rispetto a qualsiasi altro test in generale. Le persone non si preoccuperanno della velocità con cui una pagina Web viene caricata, ma piuttosto della rapidità di buffer dei video a causa della maggiore larghezza di banda necessaria per visualizzare un video.

Gli ISP aumentano spesso la velocità in base al dominio a cui si sta connettendo qualcuno se si tratta di un test di velocità o se utilizza la porta 8080. Considerando che Netflix utilizza la porta 80, una porta più lenta quando viene data la priorità.


1
"nel senso che non può essere differenziato dagli ISP da Netflix stesso" - Il che è falso, l'ISP può sicuramente vedere sia la richiesta DNS che l'SNI sulla connessione HTTPS.
Kevin,

@Kevin fast.com contatta i server netflix da cui scaricare, il che significa che emula i video dallo stesso netflix. Anche se ti garantirò che gli ISP potrebbero capire che la connessione a quel sito specifico che successivamente contatta i server basati su Netflix richiede una priorità simile a speedtest.net
Jonathan

Non è esattamente scienza missilistica. Tutto quello che devono fare è sbloccare Netflix per alcuni minuti o ore dopo aver visto una connessione fast.com. Il lato positivo, ovviamente, è che puoi andare su fast.com per non essere limitato, quindi chiudere la scheda e guardare Netflix davvero.
Kevin,

Personalmente sospetto che si tratti di informatica o almeno correlata ad essa piuttosto che alla scienza missilistica. Sembra che alcuni degli ISP più grandi (ad esempio Bell) non siano entrati in fast.com negli ultimi anni. In entrambi i casi l'esecuzione di uno script sul tuo computer che si collega a fast.com per aumentare la velocità di download ogni tanto, se la limitazione è abbastanza grave sarebbe praticabile.
Jonathan,

0

Sono solo io o nessuno ha notato che ha detto Mbps e l'elenco dei comandi di wget "MB / s".

60mbp / se effettivamente ottenere 11.2 Mb è normale.

Mbps e MB / s sono due velocità diverse.

"un Megabit è grande 1/8 di un Megabyte, il che significa che per scaricare un file da 1 MB in 1 secondo è necessaria una connessione di 8 Mbps." Quindi 11mbx8 = 88mbps ... 11.2Mb è effettivamente buono per un rapporto di connessione 60-70mbps.

Le persone che hanno memoria perdono questa tendenza. Non otterrai mai 70 mb / s con una velocità di 70 Mbps


L'output di wgetè Mb / s che si traduce in Megabit / s . MB / s si tradurrebbe in MegaBytes / s . Basta eseguire il proprio wgetcomando e verificare il risultato.
Thomas,

1
@james: Sì per impostazione predefinita, ma in OP il wgetcomando include i --report-speed=bitsrisultati in Mb/scui si trova Mbit/s. Correre senza --report-speed=bitsdare MB/sche si traduce in MByte/s. Nota il be B.
Thomas,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.