Igår kväll var den uppe och snurrade, men nu för stunden kan jag inte nå den. Den ska vara ”publik” (den dyker upp i sökresultat på ”bahnhof speedtest” men har inte sett den länkad till från Bahnhofs egna sidor) och går att nå även utanför Bahnhofs nät, men står i deras serverhall i Malmö.S sotman skrev:
Det är märkligt att ping ökar. Testa att pinga din närmaste gateway medan du testar. Om den ökar ligger flaskhalsen i din router eller i fibernätet. Ligger ping kvar på stabil nivå är det någonstans på internet som flaskhalsen finns.S sotman skrev:@merbanan Torpet ligger iofs i centrala Nacka i Stockholm, ca 20-minuter med buss från Slussenmen du kan ha rätt ang co-stationen.
Ang resultatet från bytet av kabeln så är jag inte helt övertygad då jag fick lite bättre resultat än med Cat7-kabeln via speedtest.tele2.net med Cat6A-kabeln! What gives?!!
OWC Thunderbolt 3 10G Ethernet säger sig ha stöd för 10GBaseT
- 100 meters using CAT 6A cabling
- 55 meters using CAT 6 cabling
[bild]
Summa summarum: Det borde vara safe att säga att man kan köra både CAT 6A eller CAT6 med tanke på att kabeln ju (som @lars_stefan_axelsson anmärkte) är kort (2m resp 3m).
Så "flaskhalsen" ligger någon annanstans är på min sida.
Jag har köpt 10/10 Gbps av Bahnhof. Tyvärr är min uppkoppling (om än snabbare än de flesta andras) inte i närheten av detta.
Jag jobbar som sagt med stora filer och skulle i alla fall vara nöjd om hastigheten hamnade närmare 10 Gbps än som nu närmare 4 Gbps
Resultat med Cat6A
Fast.com
[bild]
Speedtest.tele2.net
[bild]
Med Cat7
Fast.coms resultat var lite bättre
[bild]
Speednet.tele2.net lite sämre
[bild]
Besserwisser
· Västra Götalands
· 9 833 inlägg
Antagligen "bufferbloat", det ger precis de symptomen.Erik_Hansson skrev:
DSLReports tester kontrollerar bufferbloat under tiden de kör hastighetstestet: https://www.dslreports.com/speedtest?
Precis, en buffer byggs oftast i den enhet (router) som försöker skicka över en långsammare lina än vad den får data ifrån. Tex om stamnätet som 10gbit fibern är anslutet till är tjokat. Då kan trafik från internet buffras när det ska passera detta stamnät. Buffern gör att det tar längre tid för paket att passera. Alltså, även om du har 10gbit så saknas den kapaciteten på vägen.
23ms på 10gbit måste vara en massiv buffer.
Det borde vara i runda slängar 20000 paket eller 30MiB... Här skulle jag klagat ..
Edit: länk till beräkning linehastighet. Med VLAN något lägre pps. https://kb.juniper.net/InfoCenter/index?page=content&id=kb14737
Redigerat av moderator:
Vad har ni med 10gbit fiber för ping?
Själv sitter jag med 100/100 och ligger rätt nära länkens hastighet på ca 2ms, även med viss last.
För 1gbit runt 0.2ms och 10gbit borde den vara 20us, eller tänker jag fel?
Själv sitter jag med 100/100 och ligger rätt nära länkens hastighet på ca 2ms, även med viss last.
För 1gbit runt 0.2ms och 10gbit borde den vara 20us, eller tänker jag fel?
Tror du tänker fel då tiden det tar fram och åter till servern för ett ping paket tar samma tid bara det att du kan köra massa annan trafik samtidigt.Erik_Hansson skrev:
Nu är vi kanske lite off topic, men hur menar du? Om jag bara skickar små ping-paket (typ 64byte) kan man skicka väldigt många fler än om man tankar en fil som kör med 1500byte paket. Om man nu skickar mer än linan klarar (mellan dig och servern du pingar) blir det kö, och då ökar responstiden, dvs pingen...snuttjulle skrev:
Huvudsakligen riktat till @snuttjulle, men utgick från ditt i lägg @Erik_Hansson. För att lägga grunden; med varje ökning i länkhastighet ändras det hur lång tid det tar att överföra samma mängd bytes. En bredare bandbredd innebär inte att du skickar flera bytes parallellt, utan att du skickar flera bytes efter varandra i ett mycket högre tempo.Erik_Hansson skrev:
Således; att pinga någonstans påverkas definitivt av vilken hastighet du har.
Pingar du mellan två noder som är direkt anslutna till varandra så ska skillnaden i ping vara, lite förenklat, direkt kopplade till hastigheten dem emellan. Med andra ord ska skillnaden mellan 1gbit/s och 10gbit/s vara en faktor 10.
Däremot, när du pingar något ute på nätet, så är det bra många fler hopp emellan. Och byter du hastigheten på en av dessa noder är det bara hastigheten för det specifika hoppet som påverkas.
Så, med en enkel räkneövning med tillrättalagda siffror; säg att du för en viss destination har 10 hopp, och varje hopp tar cirka 10mikrosekunder att föra över mängden dara i ditt ping-paket. Du får då en total tid på 100mikrosekunder dit, och 100mikrosekunder tillbaka. Ett av dessa hopp är din utgående länk, från din router till närmsta gateway. Om du gör denna länk 10 gånger snabbare kommer detta hopp bara ta 1mikrosekund istället. Med andra ord kommer tiden för dina tio hopp istället bli 91mikrosekunder dit och lika mycket tillbaka (om vi antar att hastigheten på länken är samma i båda riktningarna).
Ska du lyckas göra hela ping-förfarandet 10ggr snabbare så måste du alltså se till att varenda länk i kedjan blir 10ggr snabbare, och inte endast länken ut ur ditt hus. För hopp inne i ditt hus har du ju lite kontroll över hastigheterna men när du är i Internetleverantörens nät är det inte mycket man kan påverka.
Intressant nog så är det väl lite det som några ”gaming-VPN” leverantörer försökt göra, genom att placera VPN-ändpunkter nära kunderna och sen försöka bygga egna backbone-nät där de placerar noder så nära EA/Blizzard etc. serverhallar som de kan, och på så sätt ta ”genvägar”, med kortare routes (färre hopp) eller högre länkhastighet per hopp än vad din vanliga internetleverantör skulle haft.
Bra förklarat
Besserwisser
· Västra Götalands
· 9 833 inlägg
Ja, så hade det sett ut i teorin!magebarf skrev:
Om det inte var så att vid högre hastigheter så dominerar tiden för processing för ett ping-paket. Dvs det finns ingen som optimerar på att svara snabbt på ett ping vid högre länkhastigheter. Så din pingtid säger mindre och mindre om hur snabb din lina är, ju högre hastighet den har. Detta vid ett hopp då.Vid flera hopp så är det som sagt routing-tiden som dominerar. Dvs ju snabbare linor desto värre är det med ett extra hopp. Jag vet inte hur "gaming VPN"-leverantörer gör, visste inte ens att de fanns
, men vill man se till extremerna så skall man istället titta på "high speed trading"-folket i USA. De har både viljan och pengarna att maxa allt vad det går, eftersom mikrosekunder betyder pengar. Där bygger man bla switchar/routrar som börjar skicka de första bitarna av inkommande ram ut på rätt interface innan de sista bitarna på de inkommande ram är framme. Man bygger dessutom radiolänknät istf. för fiber, eftersom latensen är lägre vid radioöverföring; bitarna kommer fram till slutpunkten snabbare.Och det är ju en sak att ha i åtanke. När vi pratar rundtriptider i fiber så är det fundamentalt begränsade av grupphastigheten, ca 69% av ljushastigheten i vacuum. Även om ditt första hopp vänder första biten utan fördröjning så kan det inte gå snabbare än det. Din bitrate spelar här ingen roll; den reglerar bara hur tätt ljuspulserna kan komma, inte hur snabbt de färdas.
Men vi har som sagt en bit kvar tills dess.
Absolut, går man ner på riktig detaljnivå så finns det massor av saker som sätter käppar i hjulet för det tillrättalagda räkneexemplet som mest var tänkt för att påvisa grunden i vad som är inblandat i ett ping-anrop.Ja, så hade det sett ut i teorin!
Processningstid, vilket i sig är beroende av processorkraft, fysikaliska begränsningar med ljusets hastighet och spridning av signal via elektriska kablar, är bara några av bristerna som skiner igenom snabbt när man börjar detaljgranska.
En annan sak som är av hög relevans är också att ICMP, åtminstone type 8 som används för ping, ganska sällan har högsta prioritet ute i ”vida världen”, så ”riktig” trafik får ofta företräde.
Detta är även lite kopplat till om man gör en regelrätt ping, eller om man kör traceroute där många OS (Windows inte inkluderat sist jag undersökte) kör UDP-paket för utgående trafik istället för ICMP.
Är man nyfiken på detta så gjordes det en bra NANOG-presentation i hur man bäst analyserar resultaten från just traceroute, som också går in på skillnaderna mellan det och ping: https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
Såg även att Richard Steenbergen som höll presentationen själv satt ihop en liten bokversion av presentationen: https://cluepon.net/ras/traceroute.pdf
Bra poänger och konkreta exempel på olika användningsfall och avvikelser @lars_stefan_axelsson!
Kan inte på något annat vis säga att ni räknar bort er på detta med Ping tider mer än mina erfarenheter av Latency tester på Ethernet.
Och från de tester jag gör i jobbet är latency samma på en 2 meg som en 10 gig förbindelse om de går mellan samma punkter.
Och från de tester jag gör i jobbet är latency samma på en 2 meg som en 10 gig förbindelse om de går mellan samma punkter.
M
Marcussjogren
Medlem
· Västra Götaland
· 3 079 inlägg
Marcussjogren
Medlem
- Västra Götaland
- 3 079 inlägg
Jag tror du missuppfattade pingtesternas funktion i detta och under vilka förhållanden de exekverades för att se vart problemet kan ligga.
Sen är det inte supertillförlitligt, men ger ändock en fingervisning.