Gå til innhold

slacky

Medlemmer
 Vis profil  Se deres aktivitet

  • Innlegg

    882

  • Ble med

  • Besøkte siden sist

 Innholdstype 

Blogginnlegg skrevet av slacky

  1. slacky
    Ping handler om å sende ørsmå datapakker til en enhet over IP (Internet Protocol) for å se om nettverksenheten er tilgjengelig - enheten svarer ved å sende en datapakke tilbake. Det brukes også for å måle rundetiden mellom enhetene - Maskin1 til maskin2, og tilbake. Jeg vil snakke om rundetiden (respons/pingtid).
     
    De aller fleste gamere setter store krav til lav pingtid
    Og ikke uten grunn. Jeg ønsker å dra frem spill som f.eks Counter-Strike (HL1). Dette er et spill som er veldig kravstort når det kommer til responstid, og markant endring i spillopplevelse ved responstid under 25ms, satt opp i mot 50ms eller mer. Nyere og mer moderne spillmotorer som f.eks Frostbite (BF-serien) har ikke like store krav for å få en god spillopplevelse.
     
    Har du noen gang reagert på konstant høy ping?
    Dette skyldes ofte lang, eller dårlig routing. Routing handler om veien kabelen er lagt, avstanden det er mellom deg å serveren, og antall noder på veien. Node er betegnelsen på en enhet i et nettverk. Det er nå snakk om antall "servere" du må gjennom før du når frem til ditt endelige mål, for å så sendes tilbake samme ruten.
     
    Kansje du har forsøkt å spille på naboens server?
    Og opplevde høy responstid. Da tenkte du kansje "hvorfor er det slik? Vi er jo naboer". Så enkelt er det heller ikke. De fleste større ISP-er (Internettleverandører) går sin egen rute. Du er muligens ikke switchet på denne. Dette er en av grunnene til at vi har det som heter for NIX, BIX, eller lignende. Så det som oftest skjer; er at du må routes gjennom Oslo (NIX) bare for å spille på naboens server om dere ikke har samme ISP. Naboen din kan være kunde av NextGenTel, mens du sitter på Telenor - for at dere skal kobles sammen, krever dette at dere switches til hverandre - dette skjer oftest ved NIX.
     
    Tar frem et eksempel for å regne ut teoretisk responstid basert på avstand fra deg til server.

    c / 1.48 ≈ 200,000 km/s (fiberkabel - lys i glass) 630km/200,000*2 = >>> 0.0063 ≈ 6.3ms c=Lyestes hastighet i vacuum (299,792km/s).
     
    Det skal nevnes at jeg ikke har lagt inn noen form for delay - dette kan f.eks være treige noder, trådløst nettverk, et. Avstanden kan variere en del fra f.eks avstanden du trenger å kjøre med bil, da kabelen strekkes diverse omveier. Kan fort bli lagt på 2-6ms. Også bare ved å sitte trådløst kan det øke med et par ms.
     
    Du la muligens merke til at i utregningen over så ble resultatet tilsvarende avstand(km)/100. Så, det kan faktisk gjøres så enkelt, om man ikke er ute etter et helt presist resultat.

    //Forenklet alternativ metode: 630km/100 = >>> 6.3ms (responstid)
     
    Hvordan du kan teste din responstid
    Det er relativt enkelt å teste responstiden mellom deg å en server. Kort fortalt:

    Trykk på: Startmenyen -> Trykk på: Kjør/Run -> Skriv: CMD -> ping www.nix.no Kan også velge annen webside, eller skrive IP-adresse til server.
     
    Resultatet vil ligne på dette:

    Reply from 129.240.13.149: bytes=32 time=17ms TTL=54 Reply from 129.240.13.149: bytes=32 time=18ms TTL=54 Reply from 129.240.13.149: bytes=32 time=17ms TTL=54 Reply from 129.240.13.149: bytes=32 time=17ms TTL=54 Ping statistics for 129.240.13.149: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 17ms, Maximum = 18ms, Average = 17ms
     
    Du kan også teste tilsvarende mot en server for å se hvor mange "hopp" du må gjennom - her bruker vi kommandoen tracert. EG: tracert www.nix.no
     
     
     
    Kort: Ping har ikke noe med hastigheten på linja å gjøre - sett at den ikke er overbelastet. Ping handler bare om hvor lang tid det tar å sende elektroner (kobbernett) eller fotoner (fiber) fra punkt1 til punkt2, og tilbake.
     
    Fotoner (lys) "i glass" flytter seg ved en hastighet på ca 200,000km/s. Elektroner har en hastighet på mer en 0.95 av c, såvidt kabelen ikke er skjermet. Nevneverdig: Coaxialkabel (kabelTV-nett): Elektronet har en hastighet fra 0.66 til 0.9 av c, tilsvarande fiber, dette kan varier fra kabeltype.
  2. slacky
    Etter mye lesing, og mye spekulering på hvorfor Jim Keller valgte i April å returnere til AMD har jeg kommet opp med en teori.
     
    Ikke alle her vet hvem Jim Keller er, men jeg skal gi en kort introduksjon.
    Jim Keller er vel det man kan kalde for en Veteran CPU-arkitekt, han er en av de største moderne CPU-arkitektene.
     
    Keller jobbet hos DEC i mange år, hvor han jobbet med noen av de reskeste Alpha prosessorne ved den tid. Derblandt fant man den første Clustered Integer Core/Clustered Multi-Thread CPU-arkitektur, dette var allerede i 1996.
    Se: Alpha 21264
     
    I 1998 gikk DEC i oppløsning, og Jim Keller endte samme året opp hos AMD, hvor han var medleder (co-author) samt fremste arkitekt bak både AMD K7- og K8-kjernen. Det største han bidro med var at han sto for utviklingen av AMD64 (x86-64), en utvidelse av x86-arkitekturen, som ble introdusert i AMD K8-kjernen (Athlon 64), samt så var medleder i utviklingen av HyperTransport-teknologien.
     
    Han var også lederakritekten bak Apples ARM-SoC, hvor han sto for Apple A4, A5 og A5x.
     
    Nok om hans historien hans.
     
     
    Jeg vil vise noe av det Keller var med å utviklet i 1996, mer spesifikk Alpha 21264-kjernen og sammenhengen med den moderne BULLDOZER-arkitekturen, og kansje litt hvorfor AMD var så gira på å få Jim Keller på laget.
     
    Bulldozer benytter seg nemelig av teknologien som var i 21264-kjernen, altså Cluster Integer Core også omtalt som en modul av AMD.
    Dette er et bilde av 21264-kjernen.
     
    Så slenger vi frem den moderne bulldozer-akritekturen:
    Jeg kan tenke meg at det å få med en av utviklerne bak den orginale Cluster Integer Core-teknologien kan hjelpe bulldozer på bena, iallefall finner jeg det veldig spennende.
     
    Jeg tror det faktum at Jim Keller for 16 år siden var med på utviklingen av denne teknologien gjør han til en sterk kandidat for videre utvikling av den "samme teknologi" bare under AMD denne gang. Dette kan også være mye av grunnen til at han valge å forlate Apple til fordel for AMD.
     
    - Skrivefeil vil bli tatt hånd om ved senere annleding.
×
×
  • Opprett ny...