Speedtest\speedometer hvorfor måles kun i simplex\half duplex?

[Nizzen]

 

Pleier ikke å laste ned piratkopier, problemet i så fall må man over på VPN ellers risiker man bøter\sperring for vet særlig filmbransen er interisert å bøtelegge folk.

 

Så ja da kan det være er grunnen for torrent generielt er tregt.

Er ganske mange år siden jeg brukte pirate bay sist, mest fordi vet det mye virus\dritt derfra at jeg syns det ikke er verdt risikoen.

 

ofte må man laste ned tillegg:

https://malwaretips.com/blogs/ads-by-mixvideoplayer-removal/

 

Da filmene ofte er kryptert, så derfor gidder jeg ikke å bruke tid på det, skal jeg ført ha 4k filmer kunne jeg betalt noen å dele med meg. Da bør de helst ikke være elendig format som mp4.

 

Torrent går jo ikke generelt tregt, det er jo det vi prøver å fortelle deg.

 

Og filmene er da ikke kryptert.

 

Brukerfeil

[Gjest]

Sporer fort av med LMH1 ja....

 

Det vil teoretisk være mulig å teste opp- og nedstrøms samtidig, men for å gi en indikasjon på hva man faktisk har av hastighet testes det hver for seg. Dersom det noe sted mellom maskinen og punktet maskinen er koblet til samt WAN inntak benyttes half-duplex, ja da går trafikk kun en vei med masse overhead og CSDMA/CD, riktig nok på det punktet.

Høyst sannsynlig går nok trafikken på full-duplex.

 

Hvis du ønsker en realistisk test, foreslår jeg at du tester mot en FTP server hvor du får lov til å laste opp samt last ned samtidig

Det burde gi en indikasjon på hva linjen klarer å kjøre igjennom på ditt interne nettverk, merk du kan bli begrenset av ustyr du ikke har kontroll over (ISP, utstyr der FTP maskinen står... osv).

Endret 26. februar 2016 av Gjest

[LMH1]

Grunnen til jeg vil ha tilsvarende speedtest.net er fordi da måler man forventet ytelse.

FTP vil slite hvis harddisken er dårlig gjerne usb 2 eller ligdene. Eller hvis harddisken kun har enkel cpu, da harddisken blir treg med flere en en nedlasting samtidig.

 

Men speedtest.net har vel kun cpuen\nettverkkortet, og WAN linjen som feilkilde.

 

Vet det er mulig å gjøre lik tester på linux:

$ wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod +x speedtest-cli
$ ./speedtest-cli

Men også der er samme problemet.

Så finnes ikke sikker måte å måle dette på.

Endret 26. februar 2016 av LMH1

[xExodusx]

wow....uansett hvor gode råd du får så finner du problemer med det?

[NoTrace]

Hater når harddisken kun har enkel CPU...

[Gjest]

Kremt, de aller fleste private maskiner har bare en CPU på privat markedet, med mindre du er en råtass... Den største årsaken til "bottleneck" eller tregheter på nettverk er faktisk prosessoren som benyttes med nettverkskortet, altså LAG 2 som må lese TCP/IP pakken og prosessere informasjonen og sende videre opp i OSI-modellen.
 
Harddisken påvirker hvor raskt man lagre / sende informasjon, men ikke hvor raskt informasjonen kan flyte på et nettverk...
 
 
Du kan teste hastigheten f.eks slik på Linux på nedstrøms:

wget -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test10.zip

Om jeg ikke tar helt feil i Linux verden burde du ikke bli begrenset av skrive hastigheten på harddisken som sitter i maskinen da det er CPU-en som tar seg av all jobben.

 

For å teste oppstrømshastighet må du uansett ha en fil å laste opp som vil igjen bli begrenset til faktiske lese hastigheten på harddisken. (PS, derfor testes nedstrøm først, den laster ned en fil som du laster opp igjen i samme hastighetstest når den måler oppstrømshastighet)

 

 

EDIT:

La på mer informasjon i første setningen.

Endret 26. februar 2016 av Gjest

[sk0yern]

Grunnen til jeg vil ha tilsvarende speedtest.net er fordi da måler man forventet ytelse.

FTP vil slite hvis harddisken er dårlig gjerne usb 2 eller ligdene. Eller hvis harddisken kun har enkel cpu, da harddisken blir treg med flere en en nedlasting samtidig.

Temmelig overraskende at en bruker av ditt kaliber ikke kjører RAMdisk?

Antar du har minst 128GB minne i maskinen din, så da burde det ikke være noe problem å avse noen GB til en RAMdisk.

[Rusher]

 

Grunnen til jeg vil ha tilsvarende speedtest.net er fordi da måler man forventet ytelse.

FTP vil slite hvis harddisken er dårlig gjerne usb 2 eller ligdene. Eller hvis harddisken kun har enkel cpu, da harddisken blir treg med flere en en nedlasting samtidig.

Temmelig overraskende at en bruker av ditt kaliber ikke kjører RAMdisk?

Antar du har minst 128GB minne i maskinen din, så da burde det ikke være noe problem å avse noen GB til en RAMdisk.

 

Routeren støtter ikke USB 3.1, og det finnes ikke norske ferdig oppsatte ISO filer til hans system. Så det blir nok for vanskelig 

[cable_guy]

Jeg vet det er lenge siden siste post her, men just in case someone is interested...

Hvis du har en server et eller annet sted utenfor ditt lokale nettverk - med god Internet-forbindelse - kan du bruke iperf:

ssh til serveren og kjør:

iperf -s

kjør så følgende på din PC:

iperf -c [ip addresse til serveren]

 

Hvis du vil ha duplex test kan du bruke:

iperf -d -c [ip addresse til serveren]

 

(du må sansynligvis installere iperf først: sudo apt install iperf  (eller tilsvarende om du bruker noe annet enn Debian/Ubuntu))

[LMH1]

Kunne vært greit med noe grafisk gensesnitt?

 

For problemer med fiber\vs coax vs 4g, vs 5g er umulig å måle, men problemet med untakk av fiber så er nok opplastingen elendig.

Fordi brukes en kabel vs 12 bølgelengder på fiber.

 

På 4g\5g brukes vel egen frekvens til oppstream.

[Janvik]

Kunne vært greit med noe grafisk gensesnitt?

 

For problemer med fiber\vs coax vs 4g, vs 5g er umulig å måle, men problemet med untakk av fiber så er nok opplastingen elendig.

Fordi brukes en kabel vs 12 bølgelengder på fiber.

 

På 4g\5g brukes vel egen frekvens til oppstream.

https://netbeez.net/blog/how-to-use-jperf/

 

er ikke såå vanskelig å taste litt på google.

 

Nei, privatkunder på fiber bruker absolutt ikke 12 bølgelengder. 

[Rim]

For ordens skyld så er alle testene du nevner full duplex. Du burde lese deg opp på half/full duplex, og TCP. På TCP bør du lese spesielt om ack/sack flag, window size scaling og hvordan TCP fungerer på usymmetriske linjer. 

Om du tester både ned- og opplastning samtiding så risikerer du at ACK pakkene blir buffra og forsinket (les også om bufferbloat) noe som vil redusere nedlastningshastigheten. Dette vil derfor ikke vise deg nedlastninghastigheten som linja kan klare og man tester derfor én ting om gangen.