mboost-dp1
Flickr - skreuzer
Tjah... det er vel kun et problem hvis bredbåndsmarkedet ikke udvikler sig over de næste 3 år?
Det virker sådan lidt "hvad nu hvis al udvikling gik i stå, i Danmark"-agtigt... som jo er højest urealistisk.
Det skal lige siges at jeg ikke har læst selve nyheden, kun resumeet her på newz.dk
Det virker sådan lidt "hvad nu hvis al udvikling gik i stå, i Danmark"-agtigt... som jo er højest urealistisk.
Det skal lige siges at jeg ikke har læst selve nyheden, kun resumeet her på newz.dk
Men de er da bare vildt langsomme til det.Denn (2) skrev:Hvad er problemet lige? - Energi selskaberne ruller jo netop fiber ud nu, så det er da realistisk at vi er med når det bliver aktuelt.
Som det er nu ligger der faktisk gode fiber linjer der ikke bliver brugt. I flere byer har energi selskaberne lagt fiber ud som de af forskellige årsager ikke må leje ud til ISPerne (oftest noget kommunen har bestemt)
Hvis der blev åbnet op for dem og man gjorde det interressant at investere i den slags (også i de små byer) så ville vi hurtigt have et ganske fremtidssikret net til rådighed.
Fiber har den fordel at kablerne ikke længere er flaskehalsen men at udstyret i enderne og samlingerne bare kan opgraderes
Det er ret tåbeligt at vi som et land der proklamere vi vil leve på vores viden stadig pumper dobbelt så mange penge i landbruget som vi går i IT sektoren. At bruge et par milliarder på at få fiber ud i de største byer burde være noget vi som "et førende IT nation" burde prioriterer højere end Skattelettelser og lavere benzin priser.
Fair nok vi ikke gør det og prioritrer noget andet højere men så kan man bare ikke have "Førende IT nation" som overordnet mål for Danmark da vi bliver overhalet inden om i så fald.
Hvis der blev åbnet op for dem og man gjorde det interressant at investere i den slags (også i de små byer) så ville vi hurtigt have et ganske fremtidssikret net til rådighed.
Fiber har den fordel at kablerne ikke længere er flaskehalsen men at udstyret i enderne og samlingerne bare kan opgraderes
Det er ret tåbeligt at vi som et land der proklamere vi vil leve på vores viden stadig pumper dobbelt så mange penge i landbruget som vi går i IT sektoren. At bruge et par milliarder på at få fiber ud i de største byer burde være noget vi som "et førende IT nation" burde prioriterer højere end Skattelettelser og lavere benzin priser.
Fair nok vi ikke gør det og prioritrer noget andet højere men så kan man bare ikke have "Førende IT nation" som overordnet mål for Danmark da vi bliver overhalet inden om i så fald.
Bare fordi de ruller fiber ud til alle hustande, betyder det jo ikke at vores infrastruktur bliver bedre.
#7 Det tænkte jeg også. Overskrifterne hos newz og kilden Comon er ikke dækkende, da Ciscos undersøgelse også omfatter andet end video. Fx internetappliaktioner og tjenester som gaming og Virtual Reality hvor lav latency er et must. Pga. den fundamentale forskel mellem båndbredde og latency giver det ikke meget mening at sammefatte begge i en score, som rapporten gør.
#4 Enig i at kommunerne/staten burde investere i de virtuelle veje ligesom man gør i de fysiske veje.
Trådløs er en joker som jeg ser det. Hvis udviklingen fortsætter, så bliver der måske ikke brug for faste forbindelser ud til husstandende.
#4 Enig i at kommunerne/staten burde investere i de virtuelle veje ligesom man gør i de fysiske veje.
Trådløs er en joker som jeg ser det. Hvis udviklingen fortsætter, så bliver der måske ikke brug for faste forbindelser ud til husstandende.
Denn (2) skrev:Hvad er problemet lige? - Energi selskaberne ruller jo netop fiber ud nu, så det er da realistisk at vi er med når det bliver aktuelt.
Nu ved jeg ikke hvordan siturationen er i Danmark. Men i andre lande er det ikke unormalt at trafikken mellem to udbydere bliver routed gennem en tredje udbyder på et andet kontinent... Som ISP vil man jo meget nødigt udveksle trafik med sine konkurrenter... :)
Psykocyber (3) skrev:Men de er da bare vildt langsomme til det.
Ahh...Det er måske lige over grænsen...Hvis du har fulgt med de seneste par dage, har der været nyheder om at det er os der er for langsomme til at tage teknologien til os. Elselskaberne har masser af linjer som ikke bliver brugt, enten pga de ikke må, ellers fordi at brugerne ikke rigtig forstår hvorfor de burde skifte!
#10
Jeg forstår udemærket hvorfor jeg skal skifte til fiber, det gør min pengepung derimod ikke...
Jeg forstår udemærket hvorfor jeg skal skifte til fiber, det gør min pengepung derimod ikke...
jopsen (9) skrev:Som ISP vil man jo meget nødigt udveksle trafik med sine konkurrenter... :)
Der er da vidst noget du har misforstået, som ISP vil man netop gerne udveksle data med de andre, og gerne "lokalt". Hvorfor tror du eller vi har Dixen i DK, og her i Irland har vi INEX, det er netop der hvor man peerer med de andre ISP'er.
#11: Jeg ved ikke hvor du bor, men på Falster (Guldborgsund Kommune) kan man via SEAS-NVE, få 25/25, med mails, hjemmeside plads og alt det der, samt fri telefoni og viasat guldpakke til 600 ,- om måneden. En 20/1 (hvor du får 14/0,75) fra TDC koster 429 ,-
Derudover får du ikke de mails, hjemmesideplads, extra services, fri telefoni, fjernsyn i fantasisk kvalitet osv osv osv...
Derudover får du ikke de mails, hjemmesideplads, extra services, fri telefoni, fjernsyn i fantasisk kvalitet osv osv osv...
#8 Trådløst er meget fint til almindelig surf m.m. Elsker mit 3 modem. Men det er voldsomt irriterende fx at benytte SSH fordi latency er så høj. Et radiosignal er langsommere end lysets hastighed (fiber). Dermed vil trådløst aldrig kunne erstatte kablede forbindelser. Ligesom trådløst aldrig nogensinde vil være stabilt nok til en virksomhed.
#15 Hvor står det i artiklen?
Kunne det tænkes at Cisco havde interesse i at vide hvad kravene i fremtiden var. Hvilke lande der var længst fra og hvad de mangler for at opfylde kravene så de kan prioritere deres R&D?
#15 Hvor står det i artiklen?
Kunne det tænkes at Cisco havde interesse i at vide hvad kravene i fremtiden var. Hvilke lande der var længst fra og hvad de mangler for at opfylde kravene så de kan prioritere deres R&D?
#7
En af faktorerne når man har med bl.a. telefoni og video telefoni at gøre er at der ikke må være mere end en vis forsinkelse før det bliver meget svært at følge med i samtalen. Kan ikke huske de helt præcise tal for det, men på den anden side så regner jeg heller ikke med vi løber ind i en mur lige foreløbig med hvad det angår. I hvert fald ikke hvis vi antager at det danske marked kommer fortsætter med at udvikle sig som det gør nu (langsomt).
For mig at se er det her bare endnu en dommedagsnyhed om at verden går under hvis der ikke kommer mere internet på markedet, men så længe markederne er så lang tid om at udvikle sig, så hjælper det ikke at blive ved med at lave sådan nogle undersøgelser.
Det har altid været sådan at der først er blevet sat skub i udviklingen når vi ligesom har stået med problemet i hånden, frem for når problemet ligger lige bag horisonten. Der er altid lige noget de lige kan nå først, inden det rammer dem i ansigtet.
En af faktorerne når man har med bl.a. telefoni og video telefoni at gøre er at der ikke må være mere end en vis forsinkelse før det bliver meget svært at følge med i samtalen. Kan ikke huske de helt præcise tal for det, men på den anden side så regner jeg heller ikke med vi løber ind i en mur lige foreløbig med hvad det angår. I hvert fald ikke hvis vi antager at det danske marked kommer fortsætter med at udvikle sig som det gør nu (langsomt).
For mig at se er det her bare endnu en dommedagsnyhed om at verden går under hvis der ikke kommer mere internet på markedet, men så længe markederne er så lang tid om at udvikle sig, så hjælper det ikke at blive ved med at lave sådan nogle undersøgelser.
Det har altid været sådan at der først er blevet sat skub i udviklingen når vi ligesom har stået med problemet i hånden, frem for når problemet ligger lige bag horisonten. Der er altid lige noget de lige kan nå først, inden det rammer dem i ansigtet.
#16, Et radiosignal er nøjagtig lige så hurtigt som lysets hastighed (der er bare en anden bølgelængde). Faktisk er det en smule hurtigere gennem luften end lys er gennem fiber.
Optimalt kan en trådløs forbindelse være mere stabil end en kablet da der ikke kan ske fysiske skader på forbindelsen på samme måde. Dog skal du sikre dig at det ikke jamme signalet, og du skal være sikker på at der ikke er nogen der kan opsnappe noget data, men det problem har man jo også nu om dage hvor mange virksomheder er dækket af et trådløst netværk indenfor.
Optimalt kan en trådløs forbindelse være mere stabil end en kablet da der ikke kan ske fysiske skader på forbindelsen på samme måde. Dog skal du sikre dig at det ikke jamme signalet, og du skal være sikker på at der ikke er nogen der kan opsnappe noget data, men det problem har man jo også nu om dage hvor mange virksomheder er dækket af et trådløst netværk indenfor.
Regus (7) skrev:jeg kan ikke rigtigt forstå hvor "lav ventetid" (går ud fra det er en dansk version af latency) kommer ind i billedet... de kan da være et fedt om videoen starter 10 ms eller 1s efter man har åbnet afspilleren...
Latency gør en KÆMPE forskel i overførelse af data på nettet. Mange ved det bare ikke.
Forestil dig du skulle overføre en 100MB fil på nettet og du har en 10Mbit/s forbindelse. Uden latency for at regne teoretisk, skulle du kunne overføre filen på 2 med lidt overhead (100MB * 8 / 10Mbit/s = 80 sekunder)
Hvis vi så forestiller os vi har en latency på 100ms (da det er nemt at regne med), tcp protokollen sender som default pakker med en størrelse på 1500bytes på en broadband forbindelse. Derfor sendes der en 1500byte pakke med et latency på 100ms, så bliver der svaret tilbage og spurgt efter den næste pakke, igen et latency på 100ms og så videre med alle andre pakker.
Oven i de 80 sekunder skal vi derfor lægge 200ms til for hver 1500bytes sendt (pga. latency tur-retur) Det bliver ca. (100MB / (1500bytes / 1024 / 1024)) * 0,2 sekunder = 13981 sekunder. Det giver 3,8 time lagt oven i de 80 sekunder.
Det er simpelt at regne ud med forskellige pakke størrelser og latency's.. Altså er båndbrede ikke ALT, at nedsætte latency er også nødvendig for at nedsætte den tid det tager at overføre data.
#24
Du er lidt galt ude der..
<lang forklaring>
Har for nyligt taget kursus i Netteknologi A på DTU der omhandler dette emne specifikt.
Du antager at en 100ms latency vil lægge 100ms til for hver 1500 byte (1 pakke).. dette er er kun tilfældet så fremt modtager og afsender har en meget primitiv implementation af TCP protokollen (vil ikke tro man kan kalde det tcp hvis den ikke omfylder en række krav.. men der er mange ting der skal gå galt før den lægger 100ms til pr pakke)
Først så ser vi at en 100MB fil..~= 838860800 bit hvilket bliver til ~69906 Pakker @ 1500 byte
en 10Mbps forbindelse kan håndtere 10485760 bit i sekundet
~874 pakker/sekundet @ 1500 byte pr pakke.
hvilket som du pænt har sagt det giver 80 sekunder for at overføre filen.
Her er så hvor du begår fejlen.. du antager at der er 200ms (100ms ud 100ms hjem?) pr pakke..
Når du overføre filer i tcp modtager du jævnligt pakker tilbage fra modtageren med et header flag kalder "ACK" eller ackknowledge.. og et byte antal der hentyder til hvor mange konsekutive bytes modtageren har modtaget. for at din antagelse om 200ms latency mellem hver pakke skal holde stik skal man antage at afsenderen venter på at modtage en ACK for hver pakke inden han sender den næste
dette er ikke tilfældet i tcp (eller udp for den sags skyld).. afsenderen bliver ved med at sende pakker indtil modtagerens Modtagervindue (læs: recievebuffer) er fyldt op, dette betyder at afsenderen ikke behøver vente på at modtageren har modtaget og kvitteret for pakken før han sender den næste..
Modtageren kan kvittere asynkront såfremt kommunikationen den anden vej.. fra modtageren af filen til afsenderen af filen ikke er hindret af anden trafik.
dvs pakkerne sendes med forbindelses max hastighed hvilket er de for vores optænkte forbindelse 874 pakker @ 1500 byte i sekundet.. og ikke de ca. 4-5 pakker du kommer frem til med dit regnestykke.
Der er 2 ting der kan forsinke overførselshastigheden (1) er pakketab.. pakketab kan medføre delays i størrelsesorden 50-200ms før afsender finder ud af at pakken er gået tabt og enten gensender den enkelte pakke og forsætter hvor han slap.. eller genoptager fra den pakke der var tabt og fremad.
(2) resourcemangel på et eller flere steder på netværket eller hos modtager/afsender..
</lang forklaring>
<kort forklaring>
.. så for at opsummere.. selvom hver pakke er 100ms om at finde vej fra afsender til modtager så afsendes de stadigvæk med 874 pakker i sekunder dvs. 1.144ms mellemrum fra afsenderen og dukker op 100ms senere.. der kan sagtens være mange pakker undervejs til modtageren samtidigt.
</kort forklaring>
Så næste gang du udtaler dig om noget du kun har en svag anelse om hvordan fungere så lad venligst værre.. din forklaring er misvisende og ikke informativ som nogen har voted den.
Latency har netop meget lidt at gøre med filoverførsler..
Latency er et større problem for andre protokoller end lige dem brugt til filoverførsel, da tcp-filoverførsel hovedsagligt er 1 vejs kommunikation med en smule asynkront ackknowledgement af modtaget data for at undgå datatab. og udp-filoverførsel eller streaming er ren 1-vejskommunikation
Derimod er protokoller der er afhængig af synkron 2 vejs kommunikation med flere states meget mere udsat. fx. er de fleste multiplayer spil afhængig af latency for at kunne synkronisere states mellem de forskellige clients og serveren.
Og fx. halvdelen af ftp-protokollen (den der har med control-messages at gøre.. ikke data overførslen)
Du er lidt galt ude der..
<lang forklaring>
Har for nyligt taget kursus i Netteknologi A på DTU der omhandler dette emne specifikt.
Du antager at en 100ms latency vil lægge 100ms til for hver 1500 byte (1 pakke).. dette er er kun tilfældet så fremt modtager og afsender har en meget primitiv implementation af TCP protokollen (vil ikke tro man kan kalde det tcp hvis den ikke omfylder en række krav.. men der er mange ting der skal gå galt før den lægger 100ms til pr pakke)
Først så ser vi at en 100MB fil..~= 838860800 bit hvilket bliver til ~69906 Pakker @ 1500 byte
en 10Mbps forbindelse kan håndtere 10485760 bit i sekundet
~874 pakker/sekundet @ 1500 byte pr pakke.
hvilket som du pænt har sagt det giver 80 sekunder for at overføre filen.
Her er så hvor du begår fejlen.. du antager at der er 200ms (100ms ud 100ms hjem?) pr pakke..
Når du overføre filer i tcp modtager du jævnligt pakker tilbage fra modtageren med et header flag kalder "ACK" eller ackknowledge.. og et byte antal der hentyder til hvor mange konsekutive bytes modtageren har modtaget. for at din antagelse om 200ms latency mellem hver pakke skal holde stik skal man antage at afsenderen venter på at modtage en ACK for hver pakke inden han sender den næste
dette er ikke tilfældet i tcp (eller udp for den sags skyld).. afsenderen bliver ved med at sende pakker indtil modtagerens Modtagervindue (læs: recievebuffer) er fyldt op, dette betyder at afsenderen ikke behøver vente på at modtageren har modtaget og kvitteret for pakken før han sender den næste..
Modtageren kan kvittere asynkront såfremt kommunikationen den anden vej.. fra modtageren af filen til afsenderen af filen ikke er hindret af anden trafik.
dvs pakkerne sendes med forbindelses max hastighed hvilket er de for vores optænkte forbindelse 874 pakker @ 1500 byte i sekundet.. og ikke de ca. 4-5 pakker du kommer frem til med dit regnestykke.
Der er 2 ting der kan forsinke overførselshastigheden (1) er pakketab.. pakketab kan medføre delays i størrelsesorden 50-200ms før afsender finder ud af at pakken er gået tabt og enten gensender den enkelte pakke og forsætter hvor han slap.. eller genoptager fra den pakke der var tabt og fremad.
(2) resourcemangel på et eller flere steder på netværket eller hos modtager/afsender..
</lang forklaring>
<kort forklaring>
.. så for at opsummere.. selvom hver pakke er 100ms om at finde vej fra afsender til modtager så afsendes de stadigvæk med 874 pakker i sekunder dvs. 1.144ms mellemrum fra afsenderen og dukker op 100ms senere.. der kan sagtens være mange pakker undervejs til modtageren samtidigt.
</kort forklaring>
Så næste gang du udtaler dig om noget du kun har en svag anelse om hvordan fungere så lad venligst værre.. din forklaring er misvisende og ikke informativ som nogen har voted den.
Latency har netop meget lidt at gøre med filoverførsler..
Latency er et større problem for andre protokoller end lige dem brugt til filoverførsel, da tcp-filoverførsel hovedsagligt er 1 vejs kommunikation med en smule asynkront ackknowledgement af modtaget data for at undgå datatab. og udp-filoverførsel eller streaming er ren 1-vejskommunikation
Derimod er protokoller der er afhængig af synkron 2 vejs kommunikation med flere states meget mere udsat. fx. er de fleste multiplayer spil afhængig af latency for at kunne synkronisere states mellem de forskellige clients og serveren.
Og fx. halvdelen af ftp-protokollen (den der har med control-messages at gøre.. ikke data overførslen)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund