RBW Skrevet 19. november 2004 Del Skrevet 19. november 2004 Seriell FSB fra Intel? I kampen for stadig høyere ytelse kan ting tyde på at Intel nå ser på mulighetene til å benytte seriell FSB til sine produkter. Les artikkelen her Lenke til kommentar
ahpadt Skrevet 19. november 2004 Del Skrevet 19. november 2004 Interessant ide. Er fremtiden seriell, mon tro? Lenke til kommentar
Simen1 Skrevet 19. november 2004 Del Skrevet 19. november 2004 Det virker lovende. Bl.a Knick knack har pratet om dette i det siste. Jeg har sett noen skisser og tall og er ganske overbevist om at dette er veien å gå. Første steg i serialiseringa er vel FB-DIMM fordi det kreves ekstremt få pinner per modul og dermed sparer man mye dyrebar plass på hovedkortene, eller kan ta det ut ved å øke antall paralelle minnekanaler til f.eks 8. (Noe som dog virker litt mot sin hensikt når man prøver å serialisere) Lenke til kommentar
Boralis Skrevet 19. november 2004 Del Skrevet 19. november 2004 Det virker lovende. Bl.a Knick knack har pratet om dette i det siste. Jeg har sett noen skisser og tall og er ganske overbevist om at dette er veien å gå. Første steg i serialiseringa er vel FB-DIMM fordi det kreves ekstremt få pinner per modul og dermed sparer man mye dyrebar plass på hovedkortene, eller kan ta det ut ved å øke antall paralelle minnekanaler til f.eks 8. (Noe som dog virker litt mot sin hensikt når man prøver å serialisere) Jepp og Knik Knak ser ut til å hvite hva han snakker om Lenke til kommentar
Knick Knack Skrevet 19. november 2004 Del Skrevet 19. november 2004 Interessant ide. Er fremtiden seriell, mon tro? De fleste interchip linker er i ferd med å bli serielle. Det er ingen grunn til at en ikke skulle gjøre det samme med FSB. Så ja, serielle signaler er fremtiden. De muliggjør langt høyere båndbredde per pin. PCIe er et godt eksempel. Den oppererer allerede på 2.5 "GHz". Siden det er 10b/8b koding på linja så må en trekke fra 20% som går til denne paritet sjekken og klokke generering. En fremtidig seriell FSB vil uten problemer kunne kjøre på samme frekvens som PCIe. Antagelig blir den vesentlig høyere. Jeg tipper de lar den kjøre fast på 1x eller 2x CPU klokke. Lenke til kommentar
tbend Skrevet 19. november 2004 Del Skrevet 19. november 2004 Vil frekvensene på selve cpuen klare å komme seg lenger eller vil det bli like høy fsb som klokkehastigheta på cpu! Lenke til kommentar
Knick Knack Skrevet 19. november 2004 Del Skrevet 19. november 2004 (endret) Vil frekvensene på selve cpuen klare å komme seg lenger eller vil det bli like høy fsb som klokkehastigheta på cpu! k8 og Dothan lignende design kommer ikke til å øke mer enn ca 20% i klokkefrekvens fra 90nm til 65nm. Itanium 2 baserte design kommer til å øke litt mer fordi den er effektbegrenset i dagens implementasjon. I tillegg er Itanium 2 fortsatt på 130nm så det gjenstår å se hva den får ut av overgangen til 90nm. Alt i alt ser det ut til at disse tre designene kommer til å ende opp på 2 til 3 GHz på 90nm og 3 til 3.6 GHz på 65nm, med k8 klokket høyest og Itanium lavest. Dothan havner en plass midt i mellom på 90nm og sakker akterut på 65nm. Jokeren er Netburst som kan klokke høyt på 65nm men det er ikke sikkert at slike prosessorer blir produsert. Selv tror jeg ikke 4GHz blir brutt før på 45nm (ca 2008) om Netburst ikke gjør det før den pensjoneres. Når det gjelder de serielle linkene så har Intel nokså nylig uttalt at 10GHz er innen rekkevidde. Det ser altså ut som om FSB kommer til å være klokket høyere enn CPU. Det mulig gjør smalere FSB/CPU-core som igjen mulig gjør billigere hovedkort og Northbridge eventuelt flere CPU-cores koblet direkte til Northbridge. Endret 19. november 2004 av Knick Knack Lenke til kommentar
Simen1 Skrevet 19. november 2004 Del Skrevet 19. november 2004 Knick Knack: Sånn som det er nå så har både intel og AMD-systemer en FSB som en buss mellom CPU og systemenheter som diskkontrollere, nettverkskontrollere, osv. Kunne det vært en ide å fjerne denne bussen som mellomledd og hadd PCI-express kontrolleren direkte på CPU'en? Slik at CPU'en har 3 hovedtyper signaltilkoblinger: PCI-express, minnekanaler (og eventuelle interCPUbusser for flerCPUsystemer) Det vil selvfølgelig si at alle enhetene i systemet må ha kontrollere til PCI-express, men det er vel overkommelig? Lenke til kommentar
Knick Knack Skrevet 19. november 2004 Del Skrevet 19. november 2004 Simen1: Joda det er en glimrende ide så lenge en bare skal ha en eller to slike CPU moduler. Skal du ha flere så blir minnet hengende ytterst i nettverket. Da er det bedre å sentralisere minnet slik at gjennomsnittlig tilgangstid går ned. Da unngår en sammtidig problemer med flaskehalser som lett oppstår hvis en liten del av minnet er veldig "populært" for mange prosessorer/tråder. Lenke til kommentar
Simen1 Skrevet 19. november 2004 Del Skrevet 19. november 2004 Ok. Det var selvfølgelig små systemer jeg tenker på. Først og fremst desktop, men også mindre servere og større clustere med lavt behov for utveksling av data mellom CPU'er. (En skal ikke undervurdere dette markdedet heller) Når det gjelder store tallknusere med ørten noder som utveksler veldig mye data, så kan det vel (avhengig av applikasjon) lønne seg med både en felles minnepool og en lokal. Til dette kan vel en av inter-CPU-linkene fungere som vei til den felles minnepoolen. Selvfølgelig forutsatt at de to minnene (felles og lokal) kan proriteres av programvaren (NUMA). Men tilbake til desktop (1P): Med en CPU med PCI-e kontroller og minnekontroller i kjernen så vil vel det fjerne behovet for et chipsett og således forenkle design av hovedkort betraktelig. Noe som selvfølgelig fører til lavere priser og kanskje også mer kompakte hovedkort. Hovedkortprodusentene vil selvfølgelig kunne velge blandt et utall PCI-e baserte kontrollere for å lage hovedkort med et bestemt feature-set tilpasset markedet de sikter inn på. Noe slikt vil selvfølgelig gjøre at det blir lettere å produsere hovedkort for mindre produsenter. Lenke til kommentar
4WheelDrive Skrevet 19. november 2004 Del Skrevet 19. november 2004 Hva er egentlig problemet med den parallelle varianten? Hvilke begrensninger møter man med en parallell bus som man ikke har med en seriell bus? Ved å overføre data parallelt får man jo flyttet flere bit per klokkepuls enn ved seriell/sekvensiell overføring. Lenke til kommentar
Knick Knack Skrevet 19. november 2004 Del Skrevet 19. november 2004 (endret) Hva er egentlig problemet med den parallelle varianten? Hvilke begrensninger møter man med en parallell bus som man ikke har med en seriell bus? Ved å overføre data parallelt får man jo flyttet flere bit per klokkepuls enn ved seriell/sekvensiell overføring. Les litt og se videoene: (det er 1 FB-DIMM og 4 PCIe videoer) http://www.memforum.org/memorybasics/fb_dimm/ http://www.intel.com/technology/pciexpress/devnet/ Kort fattet: De serielle linkene settes sammen slik at de er like brede som de parallelle linkene. Forskjellen er at serielle linker har egen klokke for hver "lane" (i praksis er 1 bit, som vil si to tråder på hovedkortet siden en bruker balansert overføring). Mens parallelle linker har èn felles klokke. Siden det er små forskjeller i lengden på hver tråd på hovedkortet i en slik parallell link så vil signalene komme frem til litt forskjellig tid. Ettersom frekvensen øker så blir toleransen for lengdeforskjell lavere og en møter til slutt en vegg der en ikke lengre klarer å avgjøre om et bit hører til dette eller forige/neste klokkeslag. Ved å bruke selvklokkede serielle "lanes" unngår en _denne_ veggen. Endret 19. november 2004 av Knick Knack Lenke til kommentar
snorreh Skrevet 19. november 2004 Del Skrevet 19. november 2004 (endret) Denne utviklingen er egentlig ganske naturlig. Den delte bussen (FSB) som Intel benytter i dag begynner å bli ganske utdatert sammenlignet med nesten samtlige konkurrenter, og det er på høy tid at også de tenker nytt her spesielt for å fjerne flaskehalser mht. dual-kjerne prosessorer. Punkt-til-punkt busser a'la HyperTransport og PCI-Express er fremtiden, liten tvil om det. Endret 21. november 2004 av snorreh Lenke til kommentar
Lufen Skrevet 19. november 2004 Del Skrevet 19. november 2004 jeg synes artikkelen var veldig uklar og lurte på om noen kunne komme med en mer detaljtert og forstålig forklaring på hva dette er? Lenke til kommentar
4WheelDrive Skrevet 19. november 2004 Del Skrevet 19. november 2004 ...Siden det er små forskjeller i lengden på hver tråd på hovedkortet i en slik parallell link så vil signalene komme frem til litt forskjellig tid. Ettersom frekvensen øker så blir toleransen for lengdeforskjell lavere og en møter til slutt en vegg der en ikke lengre klarer å avgjøre om et bit hører til dette eller forige/neste klokkeslag. Ved å bruke selvklokkede serielle "lanes" unngår en _denne_ veggen. Dette var interessant. Jeg trodde ikke man ville få dette problemet før ved langt høyere frekvenser (Ikke det at jeg har regnet på det). Hvis jeg husker rett så går vel strøm i kobber med ca. lysets hastighet i vakum, og siden det ikke burde være snakk om mange centimeterne i forskjell på lederne trodde jeg dette problemet så å si var ikke-eksisterende. Ok, la oss regne litt alikevel (for min egen del): strøm-hastighet: 300.000km/s = 30.000.000.000 cm/s Ved en klokke-frekvens på f.eks. 1 Ghz er avstanden i tid mellom to stigende flanker: 1/1.000.000.000Ghz = 0.000000001s (= 1 ns) Fysisk avstand blir da: 30.000.000.000cm/s * 0.000000001s = 30 cm Så det vil altså si at hvis en leder er 30 cm lengre enn en annen, så vil pulstoget på den lengste lederen ligge én klokkepuls etter. Dette problemet gjør seg kanskje gjeldene ved kortere differanser enn 30 cm siden kravet til tidsforskjellen mellom to ledere nok er godt under en halv puls. I tillegg benytter man jo Double Data Rate 1 og 2 som sikkert ikke gjør saken lettere. Ja, da var jeg ferdig med å tenke høyt... Lenke til kommentar
Lufen Skrevet 19. november 2004 Del Skrevet 19. november 2004 *masse tull om lyshastighet og sånt* det verste var at jeg faktisk skjønte noe av det der Lenke til kommentar
4WheelDrive Skrevet 19. november 2004 Del Skrevet 19. november 2004 *masse tull om lyshastighet og sånt* det verste var at jeg faktisk skjønte noe av det der Så flott! Som jeg skrev, jeg tenkte litt høyt... Lenke til kommentar
gastingen Skrevet 19. november 2004 Del Skrevet 19. november 2004 *masse tull om lyshastighet og sånt* det verste var at jeg faktisk skjønte noe av det der Jepp. og ein del av det var feil Lenke til kommentar
Lufen Skrevet 19. november 2004 Del Skrevet 19. november 2004 *masse tull om lyshastighet og sånt* det verste var at jeg faktisk skjønte noe av det der Jepp. og ein del av det var feil hva da? Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå