Új hozzászólás Aktív témák
-
nagyúr
A VMWare problémája az, hogy a 64 magos procikkal megugrott az egy hoston futtatható VM-ek számára kiadott teljesítmény adott licensz esetén. Ilyen szempontból logikus lenne csak a magok alapján számolni, de az sem egyszerű, mert akkor meg egy 2Ghz-es és egy 3Ghz-es mag is más-más történet lenne, vagyis a felé hajtaná a felhasználókat, hogy magasabb frekin járó procik felé forduljanak.
Jó döntés ennél nincs, de a VMWare-nek lépnie kellett, mielőtt elterjednek az új EPYC procik, mert utólag már macerás a licenszeket módosítani.
A VMWare konkurense egyébként az Microsoft Hyper-V, de ott iszonyú nyakatekert dolog a licensz. Vagy felraksz Windows Server 2016, 2019-et, és Hyper-V feladatkört adsz neki, de a VM-ek száma korlátozva lesz, kivéve, ha a datacenter editiont veszed meg. A DE változat 16 magra (Core) szól, tehát ők már nem CPU-ban számolnak, hanem magokban. A csavar ott van, hogy minimum 8 mag per proci és minimum 2 proci, vagyis 16 magra szóló licenszt tudsz venni. Nincs olyan, hogy csak 8 vagy 12 magra veszel.
Van az ingyenes Hyper-V Server, de a Microsoft finoman tol a fizetős verziók felé, például a 2019-esnél nincs GUI, parancssorból tudod csak vezérelni...
Alternatíve Enterprise szinten még a Xen, ami viszont olyasmi, mint a Linux, tehát van az alapján egy pár alternatíva, a legismertebb a Citrix Hypervisor. Ott CPU alapú licensz működik.
Ezek az elterjedt megoldások vannak, amúgy kismillió másik van, Linuxra ott a KVM, van a VirtualBox, stb...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
Idővel majd a VMWare feltehetően át fog térni a mag alapú licenszre, vagy bevezeti a szál (thread) alapú licenszelést. Ahogy a konkurensek is lépni fognak, ha tényleg megjelenik a 4 szál / 1 mag felállás.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Cathulhu #2553 üzenetére
Csakhogy a futó VM-ek száma rugalmasan változhat és változik az igényeknek megfelelően. Ez a fő probléma a VM alapú licencel, hogy nem lehet korrektül követni. Hogy fogod előre megmondani? Na, eddig max. 120 VM-re volt szükségem, szóval veszek 128 licenszt, és elég lesz. Majd bejön, hogy hopp, hirtelen kéne még 60VM egy projektre, egy hétre, és most indulna. Most mi legyen? Vegyenek egy éves VM licenszeket? Mit csinálunk utána, ha nem kell? Vagy mi a kukutyin legyen? A pénzügynek hogy adjuk be, hogy hirtelen ez van?
A CPU alapú számítás előnye volt, hogy relatíve könnyű számolni vele. Van egy szerverparkunk mondjuk 20db szerverrel, egyenként 2db CPU-val, az összesen 40 licensz. Akkor ennyire kell éves licensz, tessék, itt a számla, utaljátok a pénzt.
VM-ekkel számolni irtó macerás...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Petykemano #2563 üzenetére
Ajánlom [Frescho blogbejegyzéseit elolvasni].
Még augusztusban szeretett volna a Zen2-es Epyc-ekből rendelni, végül novemberben sikerült kézhez kapnia egyet. A pletykák szerint az AMD nem tudott szállítani időre, emiatt a nagy partnerek (HPe, Dell, Lenovo) nem tudtak megfelelően felkészülni (tesztelni, szoftverháttért és supportot fejleszteni) a startra, ami miatt nem lehetett még csak rendelni sem októberig. Értelemszerűen a szerverpiacon az a fajta start, amit DIY piacon csinált az AMD a Zen2 platformmal (kvázi bétateszternek használva őket) nem életképes...Szóval nem csoda, hogy 2019-ben az AMD részesedése a szerverpiacon nem ugrott nagyobbat. De erről az AMD tehet...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2566 üzenetére
A ciki inkább az, hogy a VMWare eddig jobban megérte a Hyper-V-vel szemben a nagy magszámú procik használatánál. Most igazából mindkét "nagy" szereplő lábon lőtte magát, az M$ féle 8/16 bázisú core-alapú licensz sem igazán értelmezhető megoldás, a VMWare féle is hasonlóan nyakatekert lett.
Amíg nem lépnek tisztán core, de még inkább thread alapú elszámolásra, addig ez mindenesetre elég kellemetlen helyzet.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Petykemano #2577 üzenetére
Amikor az Intel procik sebezhetősége válaszul jövő tapaszok miatt a HT teljesítménye kvázi eltűnt, akkor meg a Windows vagy Linux rétegeken futó VMware felhasználók hirtelen ott találták magukat, hogy új szervereket kell beállítani, hogy azonos számú virtuális gépet ki tudjanak szolgàlni. Ami persze új licenszeket is követel....
Szóval ez sose volt egyszerű...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Petykemano #2586 üzenetére
Túlkombinálsz. A VMWare egy a virtualizációs megoldások közül (mondjuk Enterprise szinten az elterjedtebbek közül való). Especiel ők még mindig socket alapú licenszt használták, amit most próbálnak core alapú irányba eltolni. A Hyper-V például már core bázison megy, de ott meg 8/16 core-ra épülő csomagok vannak.
Tökéletes megoldás nincs, mert amúgy az Intel Xeon procikban is szaporodnak a magszámok, tehát a socket alapú licenszen való túllépésre az Epyc nélkül is szükség lett volna előbb-utóbb. Szóval ezt nem kellene ennyire az AMD-re kihegyezni...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Petykemano #2588 üzenetére
Én pedig arra próbálok rávilágítani, hogy itt nem a "lábára" lépsz valakinek, hanem inkább az adott piaci szereplőknek (alias VMWare) kell a piaci igényeket lekövetniük. A felhasználóknak jobb, ha több magvas procit vásárolnak, mert a fajlagos költségek csökkenhetnek. Ha ezt nem követi le a VMWare, akkor magával szúr ki, mert kevesebb licenszet tud eladni. Ilyen szempontból a lépésük érthető, és semmi drasztikus nincs benne.
Ráadásul egy sor más tényező is van, ami számít, hiszen egy VM sebességét, illetve a megfelelő sebességgel futtatható VM-ek számát nem csak a CPU határozza meg, hanem a memória (sebessége és mennyisége) és a háttértár (sebessége) illetve egy komolyabb felhőrendszernél a hálózat sebessége és topográfiája.
Szóval önmagában nem fog valaki csak azért Epyc procis gépet venni, mert több mag van benne. Adott esetben lehet, hogy az Intel Optane alkalmazása többet számíthat (pl. e-mail szerverrendszernél a nagy mennyiségű e-mailek cache-elése).
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz #82819712 #2651 üzenetére
Ez tök jó... annak, aki videót renderrel munkaidőben. Vagy nekik sem...
Befizetek egy állóhelyre egy oszlop mögé az olyan megbeszélésekre, ahol a Mac rendszerekre szokott grafikusokat, videószerkesztőket a hardveres szaki megpróbálja rábeszélni egy Threadripper / Windos / (Linux) rendszerre való áttérésről...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
Egyáltalán nem felesleges, mert simán lehetne akkor egy socketes szervert építeni a TR-re, amely ugyanúgy 64 mag / 128 szálas, mint az Epyc 7702, csak éppen a TR-nek nagyobb a boost frekije (3350 Mhz vs. 4300 Mhz) és magasabb az engedélyezett TDP-je, nem is kicsivel (200W vs. 280W). Ráadásul a TR 3990X ára csaknem fele a 7702-nek (kb. a 32/64-es Epyc 7542-el van egy árban)...
Szóval a helyzet az, hogy nagyon is életképes lehetne egy TR szerverkonfig, ami nyilván nem olyan jó az AMD-nek, hiszen nem szeretné a saját üzletét rontani...
A TR és az Epyc közé határozott falakat kell húzni, hogy ne kannibalizálja a saját piacát...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
Nem azt mondtam, hogy minden feladatkörben jó lehet egy TR alapú szerver, hanem azt, hogy bizonyos (nem is olyan kevés) felállásban egy egy socketetes TR 3990X bizony keményen odaverhet akár a két socketes Epyc szervereknek is a RAM korlátozás nélkül, miközben olcsóbb lehet azoknál.
A RAM korlátozással elég sok téren megfogták ezt a lehetőséget, tehát felhúzták azt a falat (vagy kiásták azt az árkot), ami elég hatékonyan elkülöníti a TR-t és az Epycet.
Akinek a felhasználási területhez kellene a Registered ECC RAM (vagy a 256GB-nál több RAM), annak át kell fáradnia az Epyc polchoz...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2661 üzenetére
Nézd meg a TDP-t és a boost frekiket is. A TR megeszi nyers teljesítmény terén a 7702-őt, hogy P vagy normál, e téren mellékes. De ezek mellett még olcsóbb is...
A RAM korlátozás tehát igenis kellett szvsz...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
Az alapvető akadály az APU-k fejlődésében a memória sávszélesség, illetve annak hiánya, valamint, hogy a GPU tápellátása az alaplapokon jelenleg eléggé karcsú.
Őőőő.... Egy APU esetében a CPU foglalatán keresztül tud táplálkozni az integrált GPU.
A 120-160W-os, sőt, 200+W-os CPU-k idejében járunk, szóval bizonyos keretek között, de kivitelezhető lenne ez. Egy 65W-os CPU (Ryzen 5 3600) és 80-100W-os GPU (RX5500) párosítása esetén is elegendő lehet az alaplapi táp.Mindez pedig ma, nem 5 év múlva...
Ez azt jelentené, hogy (elméletben), a klasszikus, AM5-ös APU-k teljesítménye valahol a HD 7870 körül lehetne (+50%), a TRX50-eseké pedig az R9 290 környékén; itt nyilván rendelkezésre állna egy ~120W-os TDP keret is.
Az R9 290 ~ RX480 ~ RX5500.
Egy RX5500 nagyjából 80-100W-ból képes lehet(ne) az R9 290 szintjét hozni.A vicc az, hogy az AMD hosszú ideje beszél a HSA-ról, és a chipletes CPU desing adja magát, hogy a CPU chiplet mellé kerülhetne GPU chiplet. Ha lenne ilyen...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
A jelenlegi 2D tokozás előnye lehet a hűthetőség. Nagyobb méretű a komplett CPU/APU, ezáltal nagyobb a hőátadó réteg mérete, vagyis nagyobb felületen lehet hűteni...
Szóval én inkább várnám azt, hogy nő a CPU-k mérete...Nagyon optimista vagy, hogy 5nm-en egy chiplet lehet 16 magvas. Ez esetben a chiplet mérete fog megnőni, mert a 7nm -> 5nm váltás nem hoz fele akkora mérteket.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2701 üzenetére
SMT4 esetén eleve nem növelnék szerintem a magszámot. Pusztán a plusz 2 szál per mag exponenciálisan jelentene több teljesítményt, ha az SMT skálázódása megfelelő (4 mag / 8 szál -> 4 mag / 16 szál v. 8 mag / 16 szál -> 8 mag / 32 szál).
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
"Most se a cpu mag az ami sok helyet foglal chippen belül, hanem a cache, így "elfér a több mag", ha kap HBM-et a rendszer a cache növelését akkor meg el lehet halasztani."
Pont ezt mondom, hogy a cache-t nem növelve is dupláznád a chiplet tranyószámát, miközben az 5nm nem fog fele akkora effektív terület-hatékonyságot hozni. Csak az marad, hogy csökkented akkor a cache mennyiségét.
A Zen2 esetében a három cache:
L1: 32kB és 4 cikluson belül elérhető
L2: 512kB és 12 cikluson belül elérhető
L3: 16MB és 40 cikluson belül elérhetőAz L3 az I/O modulon van, és per CCX vonatkozik, tehát nem közös L3-at látnak a CCX-ek, hanem minden CCX-nek van egy 16MB-os L3 egysége az I/O modulon belül.
Na most ebből könnyen kitalálható, hogy ha kevesebb cache-t akarsz adni a magoknak, hogy elférj a CCX-en, akkor az L1 és L2 cache-t tudod csökkenteni. Ez a Zen1 óta ennyi, szóval ha csökkented, akkor esélyesen bukni fog a teljesítmény. Ugye emlékszünk, hogy a Zen is első sorban szerverbe szánt chiplet, ami amúgy a desktopokra is jó, szóval neked figyelembe kell venni, hogy mivel jár ez. A szerverekben mutatott teljesítményben pedig sokat számít a cache méret.
Szóval hiába lesz neked akár 4GB-os vagy 8GB-os L3 vagy L4 HBM alapú cache-ed, az esélyesen nem kevesebb, mint 80 cikluson belül lesz elérhető (erős tipp, de biztosan több, mint az I/O és a chiplet közötti elérés). Ezen javíthat, ha a HBM modulok az I/O chipre lesznek felstackelve, így könnyebben és gyorsabban elérné, mintha mellette lenne és interposeren keresztül csatlakozik csak. De nem tudja kiváltani a kisebb L1 és/vagy L2 okozta sebességvesztést. Egy szerverben (is) használt chipletnél ez nem fér bele, pont, hogy inkább növelni szokták a cache méretet...
Ez a logika az, ami miatt kétlem, hogy az 5nm-en a 16 magvas chiplet esélyes. Még az SMT4 esetén is húzós lesz elférni nagyjából azonos alapterületen...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
-
nagyúr
válasz S_x96x_S #2716 üzenetére
Állítólag az "Unreal Engine" - kapott egy kis optimalizációt
...a kódfordító motorhoz (compiling), és nem a játékengine-hez magához.
de ezen kívül tud valaki még valamit, hogy az UE - mennyire támogatott több core -on ?
Úgy tudom 64 szálig skálázódik. *Doppergés* függően attól, milyen jellegű terhelést kap.
Ez a fő probléma a fejlesztés terén: bizonyos dolgokat tök szépen lekezel az UE, de nagy általánosságban nehéz a párhuzamos multi-thread megfelelő leprogramozása. Szóval az UE motoros játékok többsége jelenleg jobban szereti a magas IPC-t, mint a több szálat.
Nézd meg az SW: Jedi Fallen CPU teszteket, az i3-8100 (4 mag / 4 szál) kb. olyan teljesítményt nyújt, mint a Ryzen 5 3600 (6 mag / 12 szál). Az i5-8400 (6 mag / 6 szál) pedig lelépi az R9 3950X-et is...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2745 üzenetére
A specifikáció lezárása egy dolog, a piacra kerülés egy másik. 2021-ben örülhetünk, ha a 2019-ben lezárt PCI-Express 5.0 megérkezik. Ugyebár a lezárt specifikációkat még be kell építeni a jelenleg fejlesztés alatt lévő CPU-kba, SKU-kba...
Röviden egyébként a "szokásos" előrelépés, vagyis duplázódik a sávszélesség a PCI-Express 5.0-hoz képest és alacsonyabb válaszidő.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2750 üzenetére
A fő kérdés, hogy ki merre indul el és mennyire sikerül az adott technológiát elterjeszteni. Tök jó, hogy az Epyc tudja a PCI-Express 4.0-át, de ahhoz hardverek is kellenek. Mondjuk jönnek is, lassan, de jönnek. Csakhogy a CCIX és a Gen-Z pont azért kezdett el formálódni, mert a PCI-Express lemaradt, nem kicsit, nagyon. A felhő alapú számításnál pedig hátrányba került az, akinek nincs saját külső interconnectje (az nVidia itt gurított az nVLinkkel, a 2.0 már kint van két éve, 200Gb/s sebességgel, full duplex).
Az Intel kicsit elaludt, mivel a PCI-Express 3.0 vonallal tökön lőtte magát, mert ott például 8Gb/s per lane van, ami 16x csatinál = 128Gb/s. Közben meg jönnek már a 200Gb/s és készülnek a 400Gb/s hálózati csatik. Igény lenne rá, mert iszonyatos pazarlás, hogy a 16x PCI-Express csatikat hálókártyákkal tömjék meg, csak ugye az Epyc esetében is 256Gb/s az elméleti csúcs, és várják sokan a PCI-Express 5.0-át (elméleti határ: 512Gb/s). Ezért kell a CCIX (25Gb/s * 16 = 400Gb/s) és brutálisan erős opció a Gen-Z (itt még az alap 16Gb/s per lane is elégséges lehet, ha kihasználód a 256 sávot = 4096Gb/s elméleti határ, és a szkenárióban ott van az 56Gb/s per lane...). A
Miután az AMD túl kis szereplő (jelenleg), hogy maga határozza meg a "merre" vonalat, ezért kénytelen minél többet támogatni, hogy legalább a rugalmassága miatt opció legyen az asztalon.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
Ez politikai projekt. Hiába nem versenyképes a csúcs Intel és AMD szerverekkel, erre rá lehet mondani, hogy saját. Ha esetleg gazdaságilag elszigetelik Kínát (ahogy tették az Iránnal), akkor is képes lesz egy viszonylag modern processzort teljesen házilag gyártani, illetve adott esetben képes lehet az alapjain egy komplett családot fejleszteni.
Minket ez nem hat meg, csak vakarjuk a fejünket, hogy hát ez miért érte meg Kínának. De ha Kínai szemszögből nézzük, ez egy arany biztonsági tartalék. Igazából még Oroszország sem rendelkezik ilyennel. Stratégiai szempontból hozott politikai döntés...
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
-
-
nagyúr
válasz Petykemano #2854 üzenetére
Nem is, mert az van rászitázva, hogy B550M...
Azért tetszenek a VC ilyen beszólásai: Well, to be precise, the B450 already supported it but AMD in their infinite wisdom removed this option with the AGESA update.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz Petykemano #2863 üzenetére
Az otthoni felhasználók döntő többsége a PCI-Express 4.0 kihasználására vár, jelenleg csak a kevesebb memóriával szerelt kártyáknál (RX5500XT 4GB) jelent érzékelhető előnyt. Jövőállóság szempontjából ettől függetlenül nem hülyeség számolni vele.
Szervereknél a PCI-Express 5.0 önmagában lemaradásban van a konkurens megoldásokkal (CCIX, Gen-Z, CXL) mert azok alacsonyabb késleltetést és memóriakoherens megoldásokat is kínálnak. Pont azért jelentek meg ezek a megoldások, mert a PCI-Express 4.0 túl sokáig húzódott...
Szvsz a PCI-Express 5.0 a szervereknál már elkésett, ott mire kijön, már mindenki a CCIX, CXL és a Gen-Z megoldásokra épít.
Az otthoni felhasználók pedig még 2021-ben se lesznek rászorulva a PCI-Express 5.0-ra, simán lehet, hogy a piaci ugrás a 6.0-ra fog bekövetkezni.
Szóval kettő közé, a padba esik várhatóan az 5.0-ás szabvány...[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
nagyúr
válasz S_x96x_S #2879 üzenetére
Ahogy nézem a legtöbbeknek (nekem is) az Ice Lake-SP szerver CPU sorozat kaszája jutott az eszébe. Elviekben 2020 Q3 volt a tervezett megjelenési dátuma.
Mondjuk ez meglepő annak fényében, hogy a korábban kiszivárgott hírek szerint az Ice Lake-SP 14c/28t szerverprocija meglepően erős volt a SiSoft Sandra tesztben.
Ugyanakkor az Ice Lake-SP a Copper Lake-SP vonal mellett jelent volna meg, kizárólag a két utas szerverekben, tehát valójában egy extra párhuzamos sorozat lett volna, magasabb IPC-vel, feltehetően magasabb áron. Mivel eleve 2020 Q3-ban már a Zen3-as Epyc Milan-al kellene versenyeznie (ha az AMD tényleg kihozza azt nyáron), ez egy teljesen felesleges termékvonal, akár hogy is nézzük.
Ezen a képen (tavaly nyári szivárgás) még 2020 Q2 volt a megjelenés dátuma, ez tavaly év végén egy negyedévet csúszott.
Ha valóban ez következik, ugyanakkor nem akkora világvége, ahogy beharangozzák a SemiAccurate-nál. Ha ugyanis a Sapphire Rapids-SP / Eagle Stream nem csúszik, akkor az Ice Lake-SP amúgy is mindössze három negyedévet élt volna mindössze úgy, hogy 2021 Q1-be már jönne a sokkal fejlettebb Sapphire Rapids-SP.
Ismét ha valóban ez a helyzet, akkor az Intel egy teljesen logikus döntést hozott: nem fog egy újabb termékcsaládot a piacra dobni, mert sose fogja az árát visszahozni, feltehetően a nagy partnerek sem fognak két kézzel kapni utána, és párhuzamosan foglalkozni a Copper Lake-SP-vel és az Ice Lake-SP-vel. Szóval egyszerűsítették a megjelenési terveket, és inkább a Sapphire Rapids-SP-re koncentrálnak, hogy minél hamarabb kijöjjön...
[ Szerkesztve ]
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
-
-
nagyúr
válasz -vitya- #2884 üzenetére
A tervek már tavaly év végén felborultak, mikor a 2020 Q2-ből Q3 lett hirtelen az Ice Lake-SP kapcsán.
A fő probléma szerintem a PCI-Express 4.0 kérdésköre. Pár napos info, hogy a szerverpiacon két eltérő alaplap megoldás jött volna idén, a Whitley lett volna a 2 foglaltos megoldás a Copper Lake-SP és Ice Lake-SP mellé, 8 memóriafoglalat per socket kiosztással, míg a Cedar Island lett volna a 4 foglalatos megoldás, csak Copper Lake-SP procikhoz, 6 csatornás memóriával.
Ha nem lesz Ice Lake-SP, akkor az azt jelenti, hogy a Sapphire Rapids jól halad, és 2021 Q1-ben talán ki tudják hozni. Ezzel újra felvehetik a kesztyűt. Ha így van.
Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.
Új hozzászólás Aktív témák
- Anglia - élmények, tapasztalatok
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Microsoft Excel topic
- Fujifilm X
- További aktív témák...
- 1151 V2 CPU-k / I5-8500 / I5-8400 / BESZÁMÍTOK!
- Intel i5-10400 hatmagos processzor + doboz + gyári új hűtő
- Nintendo Switch játékok (ง '-' )ง Budapest Nyugatinál
- Fekete Sony PlayStation 5 Cover (Lemezes változat)
- Samsung Galaxy S23 Ultra 5G 256GB Dual SIM Phantom Black Gyárilag független Csere/beszámítás is!