I dag har jeg et spørgsmål til de ærede læsere, der har mere erfaring med virtuelle servere end jeg selv har.
Er netværk på virtuelle servere efterhånden begyndt at performe hæderligt - eller halter det stadig bagefter?
Forklaring følger.
En hastighedstest er i bund og grund et spørgsmål om elastik i metermål - for hvad er det egentlig, en bruger har købt?
Den knivskarpe, præcise definition er, at brugeren køber et løfte om en given hastighedsprofil på sin last-mile-forbindelse. Det betyder, at internetudbyderen garanterer, at den første del af strækningen fra kundens router til internetudbyderens access-netværk har en hastighed, der ligger inden for et defineret interval - fx mellem 90 og 100 Mbit/s downstream og mellem 20 og 30 Mbit/s upstream.
Fra access-netværket og videre gennem internetudbyderens netværk bliver det mere speget. Alle internetudbydere oversubcriber deres netværk, dvs. sælger mere kapacitet, end de reelt har - og hvis ikke de gjorde det, ville en internetforbindelse koste langt mere end den gør i dag.
Det betyder også, at internetudbyderen gambler med at kunderne ikke bruger al deres kapacitet samtidig - men en hæderligt drevet udbyder vil sørge for at opgradere sit netværk, når tilstrækkelig mange brugere samtidig begynder at udnytte mere af deres kapacitet.
Når trafikken så forlader internetudbyderens netværk og kommer ud på det vilde internet, mister internetudbyderen helt kontrollen over hastigheden.
Som internetudbyder antager man, at andre internetudbydere også sørger for at opgradere deres netværk, så kapaciteten er til stede, når kunderne har brug for det, men man har hverken ret til eller mulighed for at styre det, når først trafikken er ude af netværket.
Og hvad værre er - når vi kommer tilstrækkelig langt væk, begynder fysikkens love at påvirke trafikken, så det kan mærkes.
TCP-protokollens throughput falder nemlig, når latency (forsinkelsen) på forbindelsen bliver tilstrækkelig stor, hvilket den gør som en funktion af den fysiske afstand, trafikken skal sendes over, og UDP-baserede protokoller er følsomme over for pakketab, som også stiger, jo flere routere trafikken skal igennem.
Heldigvis er de store indholdstjenester opmærksomme på dette og sørger for at komme så tæt på brugerne, som det kommercielt kan forsvares.
Det betyder, at Netflix, Youtube/Google og Facebook m.f. opstiller caching-servere lokalt hos mange internetudbydere rundt omkring i verden - som fx herunder hos teleselskabet 3, hvor Netflix har opsat et par Open Connect-servere:
Hvis en Kviknet-bruger skal tilgå www.google.dk, er det derfor overvejende sandsynligt, at han rammer en server, der står i samme bygning som en af vores routere i København, og latency vil derfor være minimal, samtidig med at båndbredden er tæt på at være optimal.
Havde serveren i stedet stået i USA, ville båndbredden være begrænset og latency ville være høj - typisk mellem 100 og 200 ms.
I gamle dage, dvs. for få år siden, var det helt almindeligt, at internetbrugere testede deres hastighed på alle mulige obskure måder.
De hardcore brugere brugte det daværende IT- og Telestyrelsens TPTEST-program, mens de knapt så hardcore brugere insisterede på at bruge TDC's hastighedstest - den virkede nogenlunde op til en vis hastighed.
Der er løbet meget vand i åen siden, og i dag er speedtest.net en af de store spillere inden for hastighedstest. Man kan teste mod en server i de fleste større byer i verden, og inden for en træskolængde eller to viser den et realistisk billede af, hvad man skal forvente af sin internetforbindelse.
Hos Kviknet har vi nu fået vores egen node på speedtest.net. I bund og grund er det en virtuel Ubuntu-server, der er installeret på en VMware ESXi.
Maskinen er forbundet med 2 x 1 Gbit/s links til en switch, der har 10 Gbit/s uplink til vores backbone, og den bør derfor give et revisende billede af den hastighed, vores brugere reelt har fået på deres last-mile-forbindelse.
Opsætningen af de 2 x 1 Gbit/s links indeholder i øvrigt en lille fælde, når vi snakker VMware ESXi - den gratis udgave indeholder tilsyneladende ikke support for LACP, som er den protokol, man normalt bruger, når man skal fordele trafikken over flere forbindelser på layer 2-niveau.
Derfor er vores LAG (Link Aggregation Group) sat op som en statisk trunk, og ESXi-serveren er sat op til at fordele trafikken efter en IP hash-algoritme.
En IP hash-algoritme fordeler trafikken over de to links, så trafik mellem de samme to IP-adresser vil bruge 1 link. Det betyder i praksis, at vores speed test har en indbygget begrænsning på 1 Gbit/s pr. bruger.
På en almindelig Linux-server kan man ud over en simpel IP hash-algoritme også vælge en algoritme, der medtager portnumre (layer 3 + 4), og derved kan man i praksis fordoble kapaciteten mellem to maskiner, så længe der anvendes mere end en enkelt datastream.
Desværre understøtter switchen ikke denne algoritme, og det ser heller ikke ud til at ESXi'en gør - og mon ikke ESXi'en alligevel giver op før man når helt op på 1 Gbit/s?
Jeg har overvejet at bruge KVM i stedet, da det passer rigtig godt ind i vores ønske om at bruge Open Source-produkter, men det er svært at få præcis information om, hvor godt netværksstakken performer på hhv. en KVM- og en ESXi-server.
En ting, der trækker kraftigt ned ved ESXi, er den implicitte forventning om at man skal administrere den gennem en Windows-baseret klient. Der findes et webinterface til den, men det er meget begrænset og tillader f.x. ikke at man sætter IP hashing-algoritmen på et LAG.
Jeg indbyder hermed læserne til at tage en hastighedstest på vores virtuelle server og fortælle, hvor høj en hastighed I opnår, og om det adskiller sig væsentligt fra de andre nodes på speedtest.net. Særligt interessant er det selvfølgelig med brugere, der har 1 Gbit/s fiber til rådighed.
Vores server kan findes her:
Hvis man som undertegnede ikke gider have Flash på maskinen, kan man bruge Ooklas beta-tester i stedet:
http://beta.speedtest.net/server/9891
Del dine resultater i debatten - og lad os høre om dine erfaringer med performance på en virtuel maskine. Skal vi prøve KVM, eller er ESXi det bedste valg?
Hvad skal man trylle med for at få beta siden til at virke? - I Chrome/Firefox/IE/Edge reagerer "Begin test" knappen slet ikke. Man kan fornemme man hover over, men der sker ikke ret meget når man klikker, udover der kommer en havelåge i slutningen af linket.
Ikke helt 1 Gbit, men: Kviknet: http://www.speedtest.net/my-result/5672866230 Dansknet: http://www.speedtest.net/my-result/5672869287
Hvad skal man trylle med for at få beta siden til at virke? - I Chrome/Firefox/IE/Edge reagerer "Begin test" knappen slet ikke. Man kan fornemme man hover over, men der sker ikke ret meget når man klikker, udover der kommer en havelåge i slutningen af linket.
Kører du evt. med adblocker?
Ikke helt 1 Gbit, men: Kviknet: http://www.speedtest.net/my-result/5672866230 Dansknet: http://www.speedtest.net/my-result/5672869287
Tak for testen. Det ser jo ud til at du får ca. samme resultat både hos os og hos Dansk Net - nemlig omkring 470 Mbit/s synkront. Det kunne tyde på en flaskehals enten på din computer eller et sted mellem Nianet og GlobalConnect.
Eller at Dansk Net tilfældigvis også kører deres Speedtest node på en virtuel ESXi præcis magen til vores. Ikke umuligt, men næppe sandsynligt.
Hvor stor er hastigheden på din Nianet-fiber - er det 1 Gbit/s?
I øvrigt super svedigt med en pingtid på 1 ms. Fiber ER bare bedre ;-)
http://www.speedtest.net/my-result/5672950757
Min firewall kører iøvrigt også på en ESXi.
Jeg burde have 250/250, men min forbindelse har været ustabil her på det sidste. http://www.speedtest.net/my-result/a/2253361904
Jeg fik dog en del mindre hos dansk net som også har server i Taastrup: http://www.speedtest.net/my-result/a/2253363551
http://www.speedtest.net/my-result/5673006441
anden udbyder:
http://www.speedtest.net/my-result/5673017946
Virker dog til at download hastighed svinger lidt.
Jeg var noedt til at vente paa at samtlige reklamer loadede (og det tog lidt tid) foer knappen virkede for mig. Med adblocker virkede den ikke selv om jeg ventede et minuts tid.
Dansk Net http://beta.speedtest.net/result/5673042850 Kviknet http://beta.speedtest.net/result/5673038576
Naesten 100% mere download fra Dansk Net end Kviknet.
Testet paa Telias 4G netvaerk fra min pc. Dansk Net testen er udfoert umiddelbart efter Kviknet testen af fuldendt.
Jeg gentog forsoeget ca. 10 minutter senere og oplevede en naesten lige saa stor forskel, dog omvendt denne gang.
Kviknet: http://beta.speedtest.net/result/5673067239 Dansk Net: http://beta.speedtest.net/result/5673069902
Saa lavede jeg samme forsoeg igen, men tog en TDC server med i Tranbjerg: Kviknet: http://beta.speedtest.net/result/5673079172 TDC: http://beta.speedtest.net/result/5673081393 Dansk Net: http://beta.speedtest.net/result/5673084236
Her er der endnu engang stor forskel.
Jeg gaetter paa at det er min baandbredde der svinger meget.
"Jeg har overvejet at bruge KVM i stedet, da det passer rigtig godt ind i vores ønske om at bruge Open Source-produkter, men det er svært at få præcis information om, hvor godt netværksstakken performer på hhv. en KVM- og en ESXi-server."
I kunne prøve at kikke på dette: http://www.proxmox.com (Interface er 100% webbaseret, og virker i alle nyere browsere, og LACP kan konfigureres med xmit_hash 3+4)
Hvad angår netværksperformance er kvm og ESXi ret tæt på hinanden, og med kvm får du også mulighed for openvswitch -> http://openvswitch.org/features/
I kan prøve at sammenligne med http://gigabit.speedtest.net. Den kører på en LXD instans og den fysiske maskine har 10 Gbit/s net. Jeg plejer at sige at det er Danmarks hurtigste speedtest.net server :-).
http://www.ubuntu.com/cloud/lxd
Vores erfaring er at LXD giver samme hastighed som hvis du kører direkte uden virtualisering. Vi har flyttet en af vores Smokeping servere fra KVM til LXD og det vandt den cirka et millisekund på foruden at målingerne blev væsentligt mere stabile.
Fra mine forældres sommerhus hvor de har fiber fra SE (nu Stofa) + måling til en server hos SE i Sønderborg som jeg gætter på er inden for samme netværk
Kviknet http://www.speedtest.net/my-result/5673205702 SE http://www.speedtest.net/my-result/5673213412
Desuden gav jeg den også lige et skud fra min server derhjemme som sidder på en 120/50 på Stofas Coax netværk
Kviknet: http://www.speedtest.net/my-result/5673235746 TDC http://www.speedtest.net/my-result/5673243299
Jeg skal vist lige have snakket med Stofa om hvor min upload bliver af.. Nårh ja og så gad jeg fanme godt have 1ms !
http://www.speedtest.net/my-result/5673006441
anden udbyder:
http://www.speedtest.net/my-result/5673017946
Virker dog til at download hastighed svinger lidt.
698 / 869 Mbit/s - spøjst med forskellen på upstream og downstream. Mon ikke forskellen kan tilskrives at flere brugere deler din internetforbindelse og downloader? Men det er så umiddelbart konstateret, at vi i hvert fald kan opnå 869 Mbit/s på en ESXi.
Her er der endnu engang stor forskel.
Jeg gaetter paa at det er min baandbredde der svinger meget.
Ja, det er nogle ret store udsving procentmæssigt (så vidt jeg kan gennemskue svinger hastigheden mellem ca. 25 Mbit/s og lige knap 50 Mbit/s). Det er nok forventligt på et mobilnetværk hvor mange deles om den samme båndbredde.
I kunne prøve at kikke på dette: http://www.proxmox.com (Interface er 100% webbaseret, og virker i alle nyere browsere, og LACP kan konfigureres med xmit_hash 3+4)
Jeg har set mange tale positivt om proxmox, er jeg helt galt på den, hvis jeg siger, det i bund og grund er en af de bedre frontends til KVM - eller er der andet og mere i det?
Er det nemt at sætte op, sammenlignet med ESXi?
Vores erfaring er at LXD giver samme hastighed som hvis du kører direkte uden virtualisering. Vi har flyttet en af vores Smokeping servere fra KVM til LXD og det vandt den cirka et millisekund på foruden at målingerne blev væsentligt mere stabile.
LXD lyder spændende pga. performance - men er det Ubuntu only, og hvor bøvlet er det at sætte op og vedligeholde, sammenlignet med ESXi og KVM?
Min erfaring begrænser sig desværre til ESXi og hyper-V. Dog er min oplevelse at det meget afhænger af den understøttelse der er af de fysiske netkort.
Kort sagt, alt kan virke så længe du har hardware der er god understøttelse til på den pågældende platform.
Jeg har set mange tale positivt om proxmox, er jeg helt galt på den, hvis jeg siger, det i bund og grund er en af de bedre frontends til KVM - eller er der andet og mere i det?
Det er korrekt. Ud over dette får du også adgang til LXC (LXD i Ubuntu slang) i samme interface.
Er det nemt at sætte op, sammenlignet med ESXi?
IMHO er det væsentligt nemmere, såfremt du anvender deres installationsCD. Alt virker out-of-the-box, men avanceret netopsætning kræver, du kan manøvrere i en terminal. Er du vant til Ubuntu, bør du omgående føle dig hjemme, da det underliggende OS er baseret på Debian.
Virtuel Windows server på HyperV host med 1Gbit kobberkabel i Nianet datacenter i Stilling. http://beta.speedtest.net/result/5673678555
Forbindelsen bliver også brugt til andet - så ren 1Gbit/1Gbit kan nok aldrig lade sig gøre.
Virtuel Windows server på HyperV host med 1Gbit kobberkabel i Nianet datacenter i Stilling. http://beta.speedtest.net/result/5673678555
Forbindelsen bliver også brugt til andet - så ren 1Gbit/1Gbit kan nok aldrig lade sig gøre.
Lige for historikkens skyld: 945 / 705 Mbit/s. Det er bedre end jeg troede kunne lade sig gøre på en virtuel server :-)
IMHO er det væsentligt nemmere, såfremt du anvender deres installationsCD. Alt virker out-of-the-box, men avanceret netopsætning kræver, du kan manøvrere i en terminal. Er du vant til Ubuntu, bør du omgående føle dig hjemme, da det underliggende OS er baseret på Debian.
Det lugter lidt af at jeg skal have det prøvet af.
Hvordan forholder det sig med Windows guests og KVM - er det noget, der kan lade sig gøre, eller skal man løbe skrigende bort?
Ikke at vi skal bruge den slags i decideret produktion, men vores kundeservice kunne godt have glæde af et par virtuelle Windows-maskiner til intern undervisning.
LXD lyder spændende pga. performance - men er det Ubuntu only, og hvor bøvlet er det at sætte op og vedligeholde, sammenlignet med ESXi og KVM?
Hvis du kører Ubuntu 16.04 på din laptop så er det ekstraordinært nemt at teste:
sudo apt install lxd sudo lxd init lxc launch ubuntu: first-machine lxc exec first-machine bash
Du er nu logget ind på din første lxd instans. Prøv at tjekke process listen med ps, netværksopsætningen og filsystemet.
Jeg har kun erfaring med et på Ubuntu men det skulle også være muligt på andre distroer som host og ligeledes med andre som klient. Dog kun Linux klienter da alle kører på den samme kerne.
Det er kernen der laver alt magien. LXC og LXD er bare userland tools til at styre det.
Standard laver de en NAT bridge til host netværket (det er simpelthen bare noget iptables de kører). Den del har jeg slået fra. I stedet laver jeg et dobbelt tagged (q-in-q) vlan interface per VM på hosten. Når VM'en starter forsvinder vlan interfacet fra host maskinen og dukker op som et almindeligt net interface på klientsiden. VM'en bruger herefter DHCP til at hente en netværksopsætning. Yoel kan formodentlig regne ud hvorfor vi har lavet det således...
Jeg har et par enkelte VM'er som ikke er Linux. Til dem bruger jeg KVM. LXD og KVM fungerer fint som kombination på en fælles host maskine. Man kan også vælge at køre KVM inden i en LXD instans.
Jeg har endvidere valgt ZFS som filsystem. Det virker som et ret solidt valg.
Lige for historikkens skyld: 945 / 705 Mbit/s. Det er bedre end jeg troede kunne lade sig gøre på en virtuel server :-)
Umildbart så er det også det højeste jeg får - dvs jeg får ca de samme tal flere steder fra også og nogle er under. Umildbart tror jeg du mister mere i browseren end i virtualiseringen.
På en 1Gbit MPLS forbindelse (GlobalConnect) har jeg fra en windows bærbar i Aarhus til en virtuel windows server i Taastrup på ESXi trukket meget tæt på 100% - har ikke talene, men det var op mod 980 eller sådan noget. Det var før MPLS'en blev taget i drift, så der var intet andet trafik i netværket - bærbaren havde eneste kabel i switchen udover den fiber der selvfølgelig også var sat i og i den anden ende var det kun test serveren som brugte netværk. For at komme helt derop ændrede vi intet i selve netværket ingen jumbo frames eller andet "snyd", men vi brugte iperf på server og bærbar hvor vi prøvede alle mulige settings og det var med et antal samtidige forbindelser det lykkedes.
Derudover er virtuelle forbindelser til virtuelle switche vel også som regel 10Gbit i dag - det er vel fordi hastigheden kan komme over 1Gbit
698 / 869 Mbit/s - spøjst med forskellen på upstream og downstream. Mon ikke forskellen kan tilskrives at flere brugere deler din internetforbindelse og downloader? Men det er så umiddelbart konstateret, at vi i hvert fald kan opnå 869 Mbit/s på en ESXi.
Ja, det er en delt forbindelse. Som sagt var målingen også en anelse svingende. En aftenmåling siger 812/891.
Hvordan forholder det sig med Windows guests og KVM - er det noget, der kan lade sig gøre, eller skal man løbe skrigende bort?
Det er ganske simpelt, og virker bare. Ligesom med VmWare, Virtualbox etc. kræver det drivere for optimal performance. http://www.linux-kvm.org/page/WindowsGuestDrivers
Speedtest.net har givet os adgang til en rapport over de speedtests, der er foretaget. Det undrer mig dog en smule, at jeg ikke kan se nogen IPv6-adresser i rapporten, da serveren kører dual stack og de pågældende hostnavne (ookla1.kviknet.dk og ookla2.kviknet.dk) begge har AAAA records.
Jeg kan dog se i webserver-loggen, at der skam kommer forespørgsler via IPv6 - Baldur, har I IPv6-forespørgsler i jeres rapport fra Speedtest?
Det er fysisk umuligt. Line speed er omkring 940-950 Mbit/s på 1G ethernet ved MTU på 1500 bytes når du har fraregnet overhead til ethernet, IP og TCP header samt obligatorisk afstand mellem pakkerne
Vil da ikke afvise at jeg husker forkert, men det tog i hvert fald lidt tid inden jeg fandt de rette test settings i iperf :-) Og så undervurderer jeg nok også de her ookla speedtest nu jeg lige har fået 945 - det bliver det jo ikke mindre imponerende af :)
Baldur, har I IPv6-forespørgsler i jeres rapport fra Speedtest?
Jeg kan godt huske at der var noget med adgang til noget statistik men jeg har glemt alt om hvordan man finder frem til det. Det er ikke noget jeg følger med i.
Vores motivation for at have en speedtest.net server er at de fleste andre servere ikke ser ud til at levere et stabilt resultat når man tester fra 1G fiber. Kunderne vil rigtig gerne se at de nu også har fået det de har bestilt, så når vi sælger 1000/1000 må vi også sørge for at der er en hastighedstest der virker.
Vi sælger nu også 10G til private og den har jeg ikke noget godt svar på hvordan man tester. Browser baserede test kan bare ikke følge med derop.
Vi sælger nu også 10G til private og den har jeg ikke noget godt svar på hvordan man tester. Browser baserede test kan bare ikke følge med derop.
Måske med http://speedtest.tele2.net/ ?
Speedtest is run on a number of fast servers in locations throughout Europe connected to Tele2's international IP core network with 10GE.
På den server jeg sidder på, får jeg med wget -O /dev/null http://speedtest.tele2.net/10GB.zip får jeg 191 Mbyte/sec= 1528 Mbit/sec.
Jeg er ikke klar over hvilken forbindelse serveren har.
Vi kan da ikke have denne tråd uden at nævne https://fast.com/ fra Netflix.
Den er godtnok kun downstream, men noget kønnere at kigge på.
Og lidt spændende læsning om hvordan det er lavet: http://techblog.netflix.com/2016/08/building-fastcom.html
Og nu tilbage til sagens kerne ;-)
Generelt er der ikke de store issues med at få performance nok på en VM i dag.
http://blogs.vmware.com/performance/files/2015/03/ldvmotion-fig52.png http://blogs.vmware.com/performance/2015/04/network-improvements-vsphere...
Viser hvad netværks stacken i VMware kan.
Den næste flaskehals bliver bussen til netkortet som begynder at mangle kapacitet, de netkort som jeg bruger i dag er PCI-Express x8 for at få kapacitet nok og sikre at deres 4 x 10 Gbit porte kan levere.
På den server jeg sidder på, får jeg med wget -O /dev/null http://speedtest.tele2.net/10GB.zip får jeg 191 Mbyte/sec= 1528 Mbit/sec. Jeg er ikke klar over hvilken forbindelse serveren har.
Jeg får cirka det dobbelte. Men problemet er at jeg får det samme hvis jeg tester mellem to servere der begge hænger på samme fysiske switch begge med 10 Gbit/s intel netkort. Der er ingen tvivl om at du har noget der er væsentligt hurtigere end 1G men det viser på ingen måde linjens egentlige potentiale.
Vi har i øvrigt en tilsvarende fil man kan teste fra således: wget -O /dev/null http://ballerup2.gigabit.dk/10g --report-speed=bits
Det er en sparse fil på serveren og du gemmer til /dev/null, hvilket sikrer ingen harddisk som flaskehals.
Lige nu kalder jeg produktet for 5000/5000 selvom det er en fuld 10G vi leverer. Simpelthen fordi det er hvad jeg kan demonstrere med wget.
Lige for historikkens skyld: 945 / 705 Mbit/s. Det er bedre end jeg troede kunne lade sig gøre på en virtuel server :-)
På den her tid af dagen kunne den også lige presses til 947 / 711 - så umildbart er det nok max på den forbindelse. http://beta.speedtest.net/result/5674740304
Yeps, det er AC WiFi. Jeg sad lige i sofaen og slappede af da jeg læste din artikel.
Jeg tester gerne på kabel når jeg kommer hjem fra arbejde i dag
Jeg har uden de store issues kørt en VMware-maskine med nginx til content delivery, som ramte 6 Gbit/s upstream.
Grunden til den ikke ramte højere, var nok at der ikke var flere besøgende som skulle hente content.
Jeg har arbejdet med xenserver i 8 år og er blevet meget glad for den løsning. I de 8 år har jeg ofte set på esxi for at se hvor den er i sammenligning med xenserver. For det meste har der været for mange begrænsninger i esxi selvom der også var fordele ved esxi. Det har f.eks. Ikke tidligere været muligt at sætte en virtuel Windows op med mere processer kraft end 2 CPU. Det er ikke noget problem i den nyeste version af xenserver i dag der for oplever jeg at den er mere fleksibel og så er den open-source og kan hentes gratis uden support udover forum. Man skal være opmærksom på at klient skal være understøtte da det ikke virker ordentlig uden at installere utility som i øvrigt er nemt installeret. Her har man en løsning de fleste virksomheder sukker efter, med alt hvad man kan ønske sig. I dag har jeg en opsætning med 3 stk server og et San. Og kan live migrer mellem server. Lave virtuelle netværk og bundle netkort. Om det er det du skal bruge ved jeg ikke men det er en anbefaling vær at prøve.
På Hyper-V kan RDMA enabled netkort udsulte PCI-Express bussen.
"Alle internetudbydere oversubcriber deres netværk, dvs. sælger mere kapacitet, end de reelt har - og hvis ikke de gjorde det, ville en internetforbindelse koste langt mere end den gør i dag."
Der står jo heller ikke en ambulance, eller hospital seng klar til alle, men bare ambulancen kommer og der en sengeplads til dig, så er det vel lige godt, om der er en eller 10000 sengepladser.
Men fiber oplever jeg at kunne hente en fuld DVD på typisk 3-8 minutter ved microsoft, og tror det er hullet ud ved dem som angiver hvor hurtigt det går. Når jeg henter større filer ved BT, så bruger jeg typisk ingen begrænsning, med undtagelse af upload nogen gange når jeg spiller. Her ser jeg også typisk at min hastighed stopper ved det jeg har betalt for, og det er 24/7. Så der er ikke meget elastik der, men der er jo også fiber. Mener også min udbyder har netflix server stående hjemme, så dermed spare de nok meget trafik ud af huset.
Glad og tilfreds kunder med det gamle fiber fra Syd Energi, men knap så tilfreds med slag til STOFA, og deres kundesupport, den er i liga med Yousee.
Der står jo heller ikke en ambulance, eller hospital seng klar til alle, men bare ambulancen kommer og der en sengeplads til dig, så er det vel lige godt, om der er en eller 10000 sengepladser.
Den kloge Erlang fra KTAS regnede på den der for over hundrede år siden. Han udviklede matematik der stadig i dag er en af grundstenene i tele og datakommunikation. Der står en fin statue af ham, når man går ind af hoveddøren på Borups Alle. :-)
Vi har i øvrigt en tilsvarende fil man kan teste fra således: wget -O /dev/null http://ballerup2.gigabit.dk/10g --report-speed=bits
Det giver mig langsommere hastighed end for tele2.
--2016-09-30 17:39:05-- http://ballerup2.gigabit.dk/10g Resolving ballerup2.gigabit.dk... 185.24.168.19, 2a00:7660:100:19::1 Connecting to ballerup2.gigabit.dk|185.24.168.19|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10737419264 (10G) [application/octet-stream] Saving to: “/dev/null” 100%[===================================>] 10,737,419,264 114M/s in 82s
Hvilket ser ud til at (din) server sidder på et 1Gbit linje?
tilsvarende:
--2016-09-30 17:40:30-- http://speedtest.tele2.net/10GB.zip Resolving speedtest.tele2.net... 90.130.70.73, 2a00:800:1010::1 Connecting to speedtest.tele2.net|90.130.70.73|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 10737418240 (10G) [application/zip] Saving to: “/dev/null” 100%[===================================>] 10,737,418,240 189M/s in 56s
Til de sjove hastigheder kan en JDSU tester bruges. De findes op til 100 Gbit i skrivende stund.
Jeg testede lige fra min stationære computer med Windows 10. Det ser ud til at du kommer rimeligt tæt på 1 gigabit.
890Mbps / 953Mbps
http://www.speedtest.net/my-result/5677173715
http://www.speedtest.net/my-result/5677164585
/Casper
Tak for det, og alle tiders at se at virtualisering ikke er et issue her.
Virtualisering bør ikke være et issue.....
Det er selvfølgelig klart, som med mange andre ting, klikker man install og next, next, next, så er systemerne på ingen måder optimeret. Min erfaring er at mange virtualiserede systemer på mange måder performer bedre end rene hardware baserede systemer. VMWare har også meldt ud at performance ikke bør være et problem, mht. netværksvirtualisering. Men først skal man sikre sig at man bruger den korrekt netkort adapter. Prøv selv at Google E1000 og VMXNET3 + performance.
Husk i øvrigt at bruge ordentligt hardware. Enhver bør vide i den sammenhæng at Realtek er NO GO....
Som Internetudbyder er der stort set intet mere træls end speedtest. Stort set alle sammen er baseret på Ookla testen. Problemet med den er at den ofte er mere vildledende end vejledende.
For det første, så er den meget afhængig af kundens computer/enhed. For det andet gør den ikke opmærksom på om kunden tester over WiFi eller kabel (Check selv hvad dit WiFi gør mht. latency). For det tredje så er der ekstremt stor forskel på, hvilke forbindelser, serverne sidder på. Det ser vi også af ovenstående, hvor det 1 Gbit/s peering, ser ud til at være begrænsningen (Ikke at ovenstående har noget med Ookla at gøre, men at det selvfølgelig også vil være en flaskehals i den sammenhæng) . Fakta er også at mange af speedtest serverne ikke er installeret på en server der er tunet til opgaven og sidder på en forbindelse med kapacitet >nok< I kraft af at mange får hurtigere og hurtigere forbindelser (> 100 Mbit/s), så kan man hurtigt regne ud at der ikke skal være mange der tester samtidigt på serverne, før det går galt..
En mere reel test vil være f.eks. en FTP download, hvor der automatisk kan aktiveres flere samtidige sessioner. FTP er TCP og det vil give et mere retvisende billede. Igen vil det kun være retningsvisende, da der jo for den enkelte udbyder kan være forskel på den vej trafikken tager hen til serveren.
Som Internetudbyder er der stort set intet mere træls end speedtest. Stort set alle sammen er baseret på Ookla testen. Problemet med den er at den ofte er mere vildledende end vejledende.
Ja, men her har vi faktisk chancen for at gøre den bedre ved at køre vores egen node. Vi kan ikke forhindre kunderne i at tage en test, og så kan vi lige så godt hjælpe dem med at gøre testen så retvisende som muligt.
For det første, så er den meget afhængig af kundens computer/enhed. For det andet gør den ikke opmærksom på om kunden tester over WiFi eller kabel (Check selv hvad dit WiFi gør mht. latency).
Enig, men det gælder også hvis kunden tester mod en anden server end vores. Vi beder altid vores kunder foretage en test via kabel, hvis de oplever problemer med hastigheden.
Det ser vi også af ovenstående, hvor det 1 Gbit/s peering, ser ud til at være begrænsningen (Ikke at ovenstående har noget med Ookla at gøre, men at det selvfølgelig også vil være en flaskehals i den sammenhæng)
En kunde, der har højere hastighed end 1 Gbit/s vil typisk også vide, at han ikke kan udnytte den i alle sammenhænge. Lidt ligesom at køre Tesla i myldretiden. Vores målgruppe her er alle dem, der ligger og svinger mellem 1 og 100 Mbit/s.
En mere reel test vil være f.eks. en FTP download, hvor der automatisk kan aktiveres flere samtidige sessioner. FTP er TCP og det vil give et mere retvisende billede.
Ookla-testen kører allerede på TCP. Desuden har vi oprettet 2 hostnavne til den samme server, så en browser vil kunne oprette flere forbindelser samtidig (det er også indbygget i Ooklas løsning). FTP er næppe det optimale valg for almindelige brugere, da firewall-opsætning m.v. kan give problemer.
Jeg synes, det er fair nok, at brugerne forsøger at verificere kvaliteten af den linie, de har købt. Vores opgave er at hjælpe dem til at få en præcis måling - for vi kan desværre ikke forvente, at de forstår hvordan internettet hænger sammen og derfor kan gennemskue, hvor reel en tilfældig test på internettet er.
FTP er næppe det optimale valg for almindelige brugere, da firewall-opsætning m.v. kan give problemer.
Enig, men en FTP download der igangsætter en masse sessioner presser virkeligt forbindelsen. Man kunne også bruge en Bittorrent klient. Det presser både down/upload, samtidigt, hvis man vælger den rigtige fil....
Da jeg fik min første fiberforbindelse fra SE/ComX havde jeg i øvrigt store problemer med at få data igennem fra en TDC fiber. Det viste sig at TDC cappede forbindelsen, dvs. de tillod åbenbart ikke mere end ca. 2 Mbit/s pr. session. Det var en udfordring for mig dengang, da jeg jo netop havde fået fiber for at forbindelsen ikke skulle være en flaskehals ifbm. overførsel af data på et projekt jeg arbejdede på. Senere, da Internet blev leveret direkte af SE i stedet for gennem ComX, så var hastigheden pr. session steget til omkring 5 Mbit/s. Det snu var at de cappede, så det var pr. session begrænsningen lå. Når jeg i øvrigt testede mellem 2 TDC fiberforbindelser, eller mellem 2 andre leverandørers fiber, f.eks. mellem GC og SE var der ikke nogen problemer....
En af vores backup VM's kører uden de større problemer 8Gbit/s på en ESXi 6, med et enkelt Intel 10Gig NIC.
Vi kører med Ent. Plus licenser, så LACP opsætning på det rigtige web interface er der ingen problemer med, vi har en del ESXi 6 hosts, med 4x10Gbit sat op med LACP det kører uden problemer (C#/Win klienten har ikke været anbefalet længe, og slet ikke hvis man har vcenter kørende ud over ESXi'en).
Men det er helt sikkert ikke den billigste løsning til det her brug, så LXD/KVM er sikkert et meget bedre valg.
Valget af ens netkort har en del at sige, Intel er godt supported de fleste steder, perf kan svinge en del alt efter hvad driver der bruges.
Har kun hørt godt om/haft god erfaring med Chelsio nic's (også dem mange hw appliance bruger), mellanox har været lidt hit or miss her, kører super når firmware og drivere spiller sammen, men har oplevet en del driver crashes på det sidste.
