- Kiszivárgott a Pixel 10 Pro
- iPhone topik
- Honor 400 Pro - gép a képben
- Eurós árlista a Google Pixel 10 telefonokhoz
- Huawei P20 Pro - profit csinál minden fotósból
- Légies iPhone halvány színei
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Egyesíti a Google az Android és a ChromeOS rendszereket
- Megjelent a Poco F7, eurós ára is van már
- Itt az igazság a Samsung állítólagos Android Auto alternatívájáról
Új hozzászólás Aktív témák
-
P.H.
senior tag
Én kimértem a 7790-emen BRP5-tel:
- 8x PCI-E1-be téve 4 egyszerre futtatott csomaggal 12 és fél óra alatt végzett (2100 MHz-es CPU-val)
- 16x PCI-E1-es slotban 4 egyszerre futtatott csomaggal 10 és fél óra alatt végzett (2100 MHz-es CPU-val)
- 8x PCI-E2-ben 4 párhuzamos csomag ugyancsak 10 és fél óra alatt fut le (1700 MHz-es CPU-val)
- az A6-6400K 192 egységes 800 MHz-es VLIW4 IGP-jén (1600 MHz DDR3-mal) 1 csomag 9 és fél óra alatt végez, pedig messze-messze nincs 1/4 olyan erős, mint a 896 GCN-shaderes 1.075 GHz-es GDDR5-ös 7790A PCI-E3-nál még kisebb a késleltetés és nagyobb a sávszélesség, de egyszerűen sok ahhoz képest, amit az APU-k kínálnak a CPU<->GPU oda-vissza adatpingpongban. Nem sok helyen látható egyelőre az APU-k és a közös CPU-GPU memória mantrájának előnye, de itt megvillan.
-
P.H.
senior tag
Igen, ez jelenleg normális: "- OpenCL versions for AMD, NVidia and Intel GPUs. As we did with the first BRP GPU apps, so far only the FFT will run on the GPU, the rest of the computation (which is still a lot) is done on the CPU. As the application develops, more and more computation will be shifted to the GPU." A későbbi verziókkal majd egyre több és több munka fog átkerülni a GPU-ra.
Ha közel 100%-os GPU-kihasználtságot szeretnél, akkor BRP5-öt érdemes futtatnod annyi példányban egyszerre, ahányszor 256 MB VRAM van a HD5800-on. (Vagy APU-n kell futtatni BRP5-öt, ott mivel nincs közbülső PCI-Express, egyetlen példány is maximumon használja az IGP-t.)
-
P.H.
senior tag
válasz
coyote55
#5058
üzenetére
Megnéztem közben, a HD4xxx sorozat lekerült az OpenCL-támogatási listáról. (Vagy rajta sem volt; GPU-Z-ben az OpenCL ki van pipálva? Úgy rémlik, hogy a régi ATI-s alkalmazások Stream SDK-val készültek; mindenesetre a Seti Top GPU models listáján szerepel HD4xxx modell.)
Ha az __app_info.xml-t visszanevezed app_info.xml-re, akkor visszaáll a régi rend. A Seti forrádkódjai nyíltak, a hivatalos marad mindig hivatalos (és lassú), a többi pedig felkerül ide. Erre írtam akkor, hogy "Ha ezt vállalod és így működik, akkor szerintem lesz megoldás arra, hogy csak a CPU-programot visszacseréld a Raimster-félére."
-
P.H.
senior tag
Abszolút igazad van, én kettő(+1) ok miatt indultam el más úton:
- nem a rendszerpartíción tartom a BOINC mappát, így OS(verzió)/hardver csere után is elég egy BOINC reinstall ugyanoda, és folytatódik minden szinte ugyanonnan; ilyenkor nem járható út az opt. uninstall.
- pár hónapja a Lunatics teljes Download szekciója le volt tiltva a project kérésére problémák miatt (most ránéztem, él megint), akkor az install-csomag sem volt elérhető.
- a problémák hasonló gyökerűek is lehettek, mint most az Collatz OpenCL-részénél: a legfrissebb AMD driverekkel hibázik a számítás (a hibás számítások pedig tovább növelik a szerver-terhelést, ami a Seti-nél eléggé kritikus kérdés):
"A number of people have complained to AMD that the exact same code no longer runs on the new drivers even though it runs on Intel OpenCL, nVidia OpenCL, and previous AMD OpenCL drivers. The in the 13.x versions, AMD tried to better optimize the code. They succeeded in a couple areas but broke others. Some have complained that even simple addition caused a failure in their code depending upon the number of variables, etc. On the up side, AMD says they are working on it. On the down side, that could be 2-3 months away."
A CUDA-nál jobban figyelnek ilyesmire, az AMD-nél kevésbé, ezzel együtt kell élni. -
P.H.
senior tag
válasz
coyote55
#5049
üzenetére
Ez azt jelenti - ahogy a Server Statusnál is láttam - egyelőre, hogy nálad minden rendben, csak épp nincs olyan feladata a Seti@Home-nak, amit ATI GPU-n tudna számoltatni (ezért is hagytam abba a setit, szokása kifogyni a munkából).
A 2. magot visszakapcsolhatod, és hagyd így hétfő-keddig, én is figyelem addig, hogy van-e ATI-s task (úgy látom, a PH!-csapatban mindenki más NV/CUDA-val számol). Érdemes néha egy-egy Update-et nyomni addig, amikor eszedbe jut. -
P.H.
senior tag
válasz
coyote55
#5047
üzenetére
Ha nyomsz egy Update-et a Seti@Home-ra, akkor látsz ehhez hasonló sorokat az Event Logban?
Sending scheduler request: To fetch work.
Requesting new tasks for ATI
Scheduler request completed: got 0 new tasksRequesting new tasks for ATI
Scheduler request completed: got 0 new tasks
Project has no tasks available -
P.H.
senior tag
válasz
coyote55
#5045
üzenetére
1. lépj ki a BOINC Managerból teljesen
2. nevezd át az adatkönyvtár (valahol BOINCdata/Projects/setiathome.berkeley.edu mappa) alatti app_info.xml file-t mondjuk __app_info.xml-re (ha majd visszanevezed, visszaáll a mostani állapot)
3. indítsd el a BOINC Manager-t
4. A Seti@Home-ra állva kattints rá a Project Reset-re (aztán erősítsd meg, hogy tényleg akarod)
5. lesd az Advanced/Event Log alatti üzeneteket és másold be ide, ha hibát jelez még mindig -
P.H.
senior tag
válasz
coyote55
#5042
üzenetére
Setit nem futtatok egy ideje, de megkerestelek a csapatban, a hibás feladataidnál ez szerepel, ismételve több tucatszor:
Number of period iterations for PulseFind setted to:20
Number of app instances per device setted to:1
Running on device number: 0
Priority of worker thread raised successfully
Priority of process adjusted successfully, below normal priority class used
OpenCL platform detected: Advanced Micro Devices, Inc.
ERROR: clGetDeviceIDs: -1
ERROR: No devices found.Úgy látom a gépeden a friss driver van. A feladataid melletti "SETI@home Enhanced Névtelen platform (ATI GPU)" arra utal, hogy optimalizált programcsomagod van fenn, nem a hivatalos alkalmazások, aminek a GPU-része nem megy a VGA-ddal (nekem akkor történt hasonló, amikor az AMD-re cseréltem az NV-t, de NV-re való opt. alkalmazáscsomag volt telepítve). Egy project reset és az app_info.xml törlése megoldhatja, de ekkor CPU-n számoló programod is visszaáll a hivatalosra.
Ha ezt vállalod és így működik, akkor szerintem lesz megoldás arra, hogy csak a CPU-programot visszacseréld a Raimster-félére. -
P.H.
senior tag
válasz
coyote55
#5040
üzenetére
Sejtem, mire gondolsz: azoknál a GPU-s taskoknál, amikhez kell CPU-erős is, 0.5 vagy 1.0 CPU-t szoktak megadni; 0.01 vagy 0.05 CPU-s mehet full CPU-számoltatás közben is. Nálam is így megy Einstein+Collatz párosítás.
Mi a hibaüzenet a hibás taskokhoz? (Advanced/Event Log)
-
P.H.
senior tag
válasz
#95904256
#4806
üzenetére
Érdemes hozzátenni ezt és ezt is.
(Kiss Lászlónál hallgattam anno egy félév csillagászatot egyetemen, rendkívül jó előadó és kimondott célja a csillagászat érthető népszerűsítése laikus körökben; 3-4 éve az exobolygók felé fordult a figyelme, amikor még kevesbé volt népszerű a téma; nem lennék meglepve, ha a tudósító a jelenlegi csapatából került volna ki).Ha azt vesszük, hogy a Kepler meghosszabbításának - nemhivatalos - bejelentése legalább két évet jelent (ami máris 5 év fölé viszi az üzemidejét), és mivel a ráirányuló médiafigyelem is jót tesz a NASA-nak, akkor majdani következő meghosszabbítása - ha maga az eszköz is bírja - megint legalább két évet fog jelenteni, akkor már a 7 évet is eléri; ráadásul kiépül a megfelelő földi ellenőrző infrastruktúra is mellé.
Ez így megfelelően olcsó is lenne, mivel ok (legalábbis publikus ok) egyelőre nincs a lecserélésére, mivel az látszik, hogy a továbbfejlesztése ill. utóda kifejlesztése helyett inkább a minél tovább üzembentartása is elérheti a kitűzött célt.
-
P.H.
senior tag
Ha pénzzel nem is, de számolnivalóval bőségesen el lesz látva a Seti@Home.
-
P.H.
senior tag
Nem mindegy, néhány CUDA-project csak 260.00 verziójú utáni driver mellett tölt le feladatot (CUDA 3+, ~Fermi-only).
Viszont néhány project-nek vannak cuda23 megoldásai, azok legalább 9xxx VGA-kon biztosan mennek, bár 8400GS legjobb esetben is csak egy-két CPU-mag teljesítményére lesz képes. De ezt ki kell tapasztalni, project-enként változó; én 9500GT-vel kezdtem.
-
P.H.
senior tag
válasz
Peter80v
#4618
üzenetére
Grobber: Az Einsten CUDA-megoldása ilyen, nagy része CPU-n fut, kicsit rásegítget menet közben a GPU.
Peter80v: várj vele hétvégéig, a Seti szerverei amúgy is mindig tervezetten elérhetetlenek kedd délutántól péntek délutánig; most épp nem előre látható okok miatt nem elérhetőek vasárnap este óta.
-
P.H.
senior tag
"bár elvileg most van elég"
Az Astopulse eléggé mostohagyerek.A csomagküldés most eléggé kiszámíthatatlan, épp nem most van az ideje változtatni a beállításokon vagy utolsó esélyt adni.
Rengeteg (túl)húzott* NV-kártya van most a SETI szolgálatában, amik az Enhanced-re a hibás eredményeket perces gyakorisággal produkálták, ezt nem bírták a szerverek; ehhez hozzájárul, hogy egy opt. CUDA-app nem mindig adja pontosan ugyanazt az eredményt, mint egy 6.03-as CPU-s; ezért most eléggé belassították a project mozgásterét.
A legjobb most megvárni, amíg véget ér ez a heti 3 napos "scientific and development" leállási időszak, mert ez elég zűrös.
Májusban lecserélték a validate és a pre-estimate algoritmusokat; az előbbi velejárója a 20-25%-kal nagyobb (és egyben egyelőre - CUDA-n legalábbis - átláthatatlan) értékelési rendszer lett; az utóbbi először pár másodperces futási időt becsült, amivel "szerencsésen" leterhelték a download server-eket, ennek következtében bevezették a napi max. 20 csomag/gép elvet. A múlt héten megint lecserélték a pre-estimate rendszert, ekkor meg a fél órás CUDA-csomagokra 7 órát jósol(t), kiürült majdnem az egész client-park cache-e.
Most kb. normális a rendszer, de megint péntekig nem lesz nagy mozgás (download/upload).Nekem 8 napra van beállítva a cache, ez tavaly óta elég (akkor 7 napos cache-el kifutottam egyszer a feladatokból). Mondjun Astropulse-t nem számolok.
*(túl)húzott: nálam a DDR3 1GB-os GT220 hivatalos 800 MHz-es gyári órejelén rontja a csomagokat (végigszámolja, de folyamatos validation inconclusive), ezért megvétele óta 733 MHz-es memóriával használom; a shader-eket és a magórajelet akárhova húzhatom, előbb fagy a teljes rendszer, minthogy hibás csomagot számolna.
A korábbi GDDR3 256 MB-os passzív GT 9500-zal sosem volt ilyen probléma, azt 800-ról 1000-1050-re állíthattam általában. -
P.H.
senior tag
Az "Anonymous platform" alkalmazások innen származnak.
Az (NVIDIA GPU) azt jelenti, hogy a SETI@home Enhanced csomagokra CUDA-alkalmazás fut a CPU-s helyett. Ebből van hivatalos is (SETI@home Enhanced v6.09 cuda23), viszont a linken levő továbbfejlesztett verzió ~ 2/3 - 3/4 idő alatt végez.
Astropulse-ra hivatalosan csak CPU-s app van, ATI GPU-s alkalmazás letölthető a fenti linkről. -
P.H.
senior tag
válasz
Malachi
#4409
üzenetére
Egy-egy project annyira állítja be a letöltési tárat, hogy az előre megadott napra legyen dolga (ha két project megy, akkor annak felére). A Seti párhuzamosan küldi az Astropulse (CPU) és a cuda (GPU) csomagokat; ha úgy számolja, hogy pár napig lesz mit csinálnod, akkor nem küld újat. Tehát, ha véli, hogy van a CPU-nak munkája pár napra, akkor nem jön újabb GPU-csomag, legalábbis eddig így tapasztaltam (és eddig mindkét GPU-s project a szükséges CPU-időből indul ki).
Fogyasztás: nálam az a gép megy folyamatosan 24/7 (napi legalább 8 órát azért előtte ülök én is, viszont nem játszok rajta sosem
), amit az adatlapomon olvashatsz; kb. egy évig csak Einstein-t futtattam (ennek jelenleg is jobb a CPU-kihasználása, kb. 1-1.2 IPC folyamatosan, a gyári SETI Astropulse 0.7-0.9 IPC között van, az SSE3-ast még nem néztem, tehát Einstein mellett elég magas a fogyasztás), így havi 8K-t evett a gép, két 68W-os F2 Opteron-nal, semmilyen vga-val. Most a héten vettem egy 50W-os passzív 9500GT-t, én ennél többet nem szánok a GPU-számításokra.
Szvsz ha naponta csak 8 órát megy a géped, akkor kb. ez a 8K-nak kb. 2/3-a vagy 3/4-e lehet jó kiindulópont az adataidnál szereplő gépre (5200+, 8800 GT) 24/7-ben. Ennél lehet több is, kevesebb is. -
-
P.H.
senior tag
válasz
#95904256
#4338
üzenetére
Ez egy első stepping-es Nehalem Xeon + az AAJ68 jelzésű bug, 5570 és - a Core i7 topikban említett - 5560 típusok ismertek.
AAJ68 CPUID Instruction Returns Incorrect Brand String
When a CPUID instruction is executed with EAX = 80000002H, 80000003H and 80000004H, the return values contain the brand string Intel(R) Core(TM) CPU when it should have Intel(R) Core(TM) i7 CPU. In addition, the processor number will be incorrect. The return value will be will have have an additional zero between the processor number and the @ symbol (for example: Intel(R) Core(TM) CPU nnn0 @ x.xx GHz where nnn is a processor number and x.xx is the frequency).
-
P.H.
senior tag
válasz
#95904256
#4262
üzenetére
Seti-től kaptam most 20 új csomagot, úgy néz ki, megvan a vésztartalék szűkösebb időkre
Lehet pár gyors kérdésem?
1. Az Einstein-könyvtáram 600 MB-os, gyanítom, nem törli a korábbi grid file-okat (évek óta és több újratelepítés után is ez a munkamappa, pl. h1_1066.05_S5R3 és l1_0377.40_S5R2 típusú ~3 MB file-okkal van tele. Fogja ezeket automatikusan törölni valaha, vagy kézzel kellene?
2. A BOINC (6.2.14 x64) Messages szerint:
Processor features: fpu tsc pae nx sse sse2
Tehát SSE3-at nem lát (innen van a Seti kliens, az eredményekből úgy tűnik, ez viszont használja). Van vagy lesz ebből a későbbiekben hátrányom, ha a BOINC nem jól detektálja az utasításkészletet? (Erre utalva)3. Task Manager szerint az Einstein-kliensek induláskor egy ideje 700 MB, mostmár kb. 1 GB adatot olvasnak be (I/O Read Bytes, ez elméletileg a process readfile() hívásainak méretparamétereit összegzi). Ennek mi a magyarázata?
-
P.H.
senior tag
válasz
#95904256
#4260
üzenetére
Ha van valami módszered arra, hogyan lehet visszaállítani angolra, írd le pls. Falra mászok a magyar szövegektől, és a magyarításoktól úgy általában, de ez a vegyes angol-magyar még rosszabb
Szerencsére ma jött megint pár napnyi csomag (látom, neked is), de tegnap este kifogytam, tehát újra megy a Seti is, amíg nem rendeződik a helyzet.
Illetve menne, de "Scheduler request succeeded: got 0 new tasks" van ott is, szinte folyamatosan (összesen 8 csomagot kaptam ma napközben). Ez normális? -
P.H.
senior tag
válasz
#95904256
#4223
üzenetére
Ha csak a 4.36-os app van a könyvtárban, akkor elég az appinfo.xml-t törölni, vagy inkább Reset Project kellene, hogy automatice letöltse majd az első S5R4-es csomagokhoz azt, ami kell?
Fog párhuzamosan menni az S5R3 és S5R4 csomagok küldése, vagy most teljesen kifut először az S5R3?
Csütörtöktől vasárnapig nem leszek itthon, ezért kérdem. -
P.H.
senior tag
válasz
#95904256
#4019
üzenetére
Adatbázis-jellegű hiba, a főoldalon is kinn van már, majdnem az összes server áll du. 4 óra óta, (ottani) 21:00-ra ígérik a 'rendet'.
Már onnan is gyanús volt, hogy a majd 3 hete validált S5R2 csomagjaim ugyanúgy validate error-osak, mint a délelőtti csomagjaim, amiket még senki sem számolt ki, sőt, meg sem kapott rajtam kívül.
(Amúgy is zűrös volt az átállás az S5R3-ra, legalábbis nálam nem volt zökkenőmentes.)
-
P.H.
senior tag
válasz
westlake
#3878
üzenetére
SZVSZ project-enként változik. SETI egy sima hálókártya-csere után új computer ID-t ad, tehát MAC szerint ellenőrzi a gépeket. Pl. Einstein esetében pedig nem, két és fél éve csatlakoztam hozzá, ez alatt 3 gépem volt (egyszerre mindig egy) és 4 különféle MAC-címem, és még mindig ugyanaz a computer ID-m (82284), és összegződtek a creditek.
Újratelepítés és gépváltás esetén is mindig azt csinálom, hogy a teljes BOINC mappát lementem, visszamásolom, majd a BOINC telepítőt lefuttatom arra a mappára, így a workunit-okat folytatja tovább.
[Szerkesztve] -
#3842
P.H.
senior tag
concret_hp
#3840
P.H.
senior tag
válasz
concret_hp
#3840
üzenetére
Ha nem használod ezt a szolgáltatást amúgy a Skype-ban, akkor futtasd le újta a Skype installer-t, telepítés közben rákérdez, hogy aktiválja-e ezt a IE-plugint/szolgáltatást, ott biztosan ki lehet le lehet tiltani.
Nekem alapból nincs feltelepítve a plugin, nem tudom megmondani, hogy programon belül hol lehet kapcsolgatni. A Skype-topikot érdemes még megnézni.
[Szerkesztve] -
#3766
P.H.
senior tag
concret_hp
#3765
P.H.
senior tag
válasz
concret_hp
#3765
üzenetére
Annak, amelyik az Einstein@Home-ot csinálja, lásd pl. [link]. Ők azok: [link]
akosf: Egyáltalán nem RAC felől közelítem meg a dolgot. Tudtam, hogy ez a válasz a kérdésemre, logikusan nem lehet kölün saját és outsider kliens (pedig volt már olyan eredményem, ami mellett a másik kettő workunit-adatok alapján 4.18 és 4.20-as klienssel született, az enyém természetesen invalid lett), mégis azért tettem fel, mert elgondolkodtam, hogy hogy is áll most az S5R2. Kapkodósan született meg, és nem is teljesít egyelőre jól. Korábban levezetted, hogy a saját gépbázis mellett jelenleg (még talán fejlesztési szakaszban) nem elemi érdekük, hogy minél többen a project mellett maradjanak,
Viszont az, hogy ekkora 'baki' lehetséges, az érdekes. Ha tudták, hogy az Intel-kód nem AMD-barát (miért is lenne az), ami a saját gépállományuk teljesítményét is erőteljesen visszaveti (ha hihető a 35%), akkor úgy érzem, nem is olyan fontos jelenleg, hogy eredmények szülessenek. Ha pedig nem tudták, hogy milyen jellegű külső kódbázisra építkeznek, az elég nagy tervezési/programozói hiba.
[Szerkesztve] -
P.H.
senior tag
Kliensfrissítés történt az Einstein-nél, most látom, hogy ma kora délután letöltötte a BOINC a v4.17 S5R2-es .exe-t és .pdb-t. A főoldalon nem találtam még infót róla, kíváncsi leszek, mennyivel lesz stabilabb.
Nagyon sok client error-t látok a 4.13-mal mindenfelé, az eddigi csomagjaim legalább felénél kettő helyett 3 vagy 4 gép kapta meg a csomagot client error miatt (4, 8, 16 magos gépek is hibáznak), megértem, hogy optimalizáció eddig szóba sem került. Lekopogom, nálam eddig minden csomag lefutott hiba nélkül.
[Szerkesztve] -
P.H.
senior tag
Most ránéztem egy kicsit jobban, nálam 10 másodpercenként ugrik 0.01%-ot a feldolgozás, Feladatkezelő szerint 1,5-2 másodpercenként pontosan 3 MB-nyi laphibát generál (mindig pontosan ugyanannyit, 4KB-os lapokkal számolva), ekkor ebben a fél másodpercben pontosan 3 MB-tal megnő a memóriahasználat, majd visszaesik, ez egyértelmű memóriafoglalás.
Tehát egy ciklus lefutása alatt 15-20 MB-nyi új memóriát allokál (ez sok
). Lehetséges, hogy ide-oda ''másolgatja'' a 3 MB-nyi feldolgozott adatot, lehetséges, hogy a 3 MB-ok ideiglenes területek, de mindkét esetben sokkal jobb lett volna előre lefoglalt fix pufferelést használni. (Előbbi esetben, ha nem lehet helyben feldolgozni, akkor egy dual-buffer megoldás már elég lehet, utóbbi esetben egy quad- vagy nyolcas pufferrendszer non-temporal store-okkal. Legjobb persze a helyben feldolgozás lenne. Vagy az, hogy az egyszerre letöltött nagyméretű adatot - legalább részben - 512 KB cache-re optimalizálva 256 KB-os chunk-okban dolgozza fel, de ennek megoldhatósága algoritmusfüggő).
Kész lett az első két csomagom, 23 óra 4x perces feldolgozással, csomagonként 256.53 credit-ért... Egyelőre 200 MHz-es memóriák alatt reménytelen belekezdeni.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3705
üzenetére
Page Fault azt jelenti, hogy a lapozófile-hoz kell nyúlni, mert a virtuális->lineáris címhez tartozó lap nincs a fizikai memóriában. Vagy akkor jelentkezik, ha a process inaktív volt egy ideje, és lapjainak többsége kiíródott pagefile-ba (ez nem lehet itt értelemszerűen), vagy nincs annyi fizikai memória, amennyi kellene egyszerre, és cserélődnek a lapok folyamatosan (ez sem lehet, mert 1.5GB-om van, több, mint 1GB-os a system cache).
Marad az, hogy folyamatosan új, ideiglenesen használt memóriaterületeket foglal a process, vagy folyamatosan növel valamilyen lefoglalt dinamikus memóriaterületet, esetleg GMEM_MOVABLE-ként foglal le, amit minden hozzáférés előtt lock-olni kell, hogy a kézben legyen a virtuális cím, ez, mivel movable, akár mindig más lapokra mutathat. Akármelyik is, ezeket az új lapokat első használatkor ''be kell lapozni'', hiszen allokálásnál kapott virtuális cím általában a pagefile-ra mutat, ezeket NT alatt a nullázás, átméretezésnél/reallokálásnál/lockoláskor pedig a másolás lapozza be automatice. Ezzel elég sok idő is elmegy, és a memória-sebességre is elég érzékeny lesz a process. Plusz minden lapozás/pagefault egy OS-szintű megszakítás-beolvasás(-esetleg kiírás-), és általában 4 KB-onként (gondolom, nem 4 MB-osak ezek a lapok Einstein esetében).
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3702
üzenetére
Nálam is már S5R2-csomagok futnak. Látom, Te is csak azt a két workunit-ot küldted vissza hajnal óta. Nálam most 7:38:50 után 31,4%, illetve 6:23:40 után 25,6%, mindezek mellett mindnél 12 millió feletti page fault-nál tartok - 4 másodpercenként 2300 körüli növekmény -, ez elég ''dinamikus'' memóriafoglalást jelenthet, S5R1 és S5RI mellett indulás után nem volt page fault). A Tieiden kívül nem láttam még S5R2-es visszaküldött csomagokat, most még nem tudom elképzelni sem a napi 2 WU utáni credit-értéket.
Mindenesetre érdekes lesz.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3641
üzenetére
Egy kicsit tovább számolva:
-a Core2 konfigod (laptop?) ma eddig 22 WU-t csinált meg, eszerint 2,86*22*30=1887 Ft lenne havonta.
- a 3600+ X2 konfigod tegnap 18 WU-t csinált meg, ez 1544 Ft lenne, /hó.
Nem tudom, melyikből számoltad, (AM2 3600+ TDP-je 65W, Core2 talán valamivel kevesebb max-on), teljes konfigot hozzávéve nem olcsó mulatság, ha komolyan csinálja valaki. ...ha nem számoltam el. És kevésbé új technológiákon előfordulhat ennél jócskán magasabb /WU-költség is.
[Szerkesztve] -
P.H.
senior tag
Jó nagy zagyvaság lett a vége, szóval
- ...nem biztos, hogy az FPU műveleteknek van jövője...
- add és sub esetében .... a gyorsulás kétszeres + pár még százalékos lehet
Viszont on is leszek: ma beindult az Einstein validálása. Felugrott a RAC mindenkinél, nekem perpillanat 992-re (egyéni csúcs). Ez megerősített abban a sejtésemben, hogy a RAC súlyozott átlag (legalábbis az utolsó nap »sokkal« erősebb), nem pedig az elmúlt pár nap/hét általános napi eredményének átlaga. -
P.H.
senior tag
válasz
#95904256
#3620
üzenetére
No, most van időm válaszolni, és korábban talán szűkszavúan fogalmaztam. Ami bántotta a szemem, és most is bántja, az a ''Egy jól megírt 64 bites kódnak kb. 2-szer gyorsabbnak kell lennie mint egy jól megírt 32 bitesnek.'', illetve ''max. 64 / 32 = 2-szeres gyorsulást feltételez az ember''
Az eredmények nem lepnek meg. Közben megnéztem, mi is az ABC@Home lényege, és t''udom, hogy Te 64 bit-nél is sokkal nagyobb adatokon dolgozol általában'' (a prímkeresés miatt, teszem hozzá). Mindkét témára azt kell mondanom (megint), ezt nem SIMD, ahol ténylegesen kimondható a x-szeres gyorsulás várható.
Registerszélesség-növelés akkor hoz a konyhára, ha általa sokkal kevesebb »utasításra«, mint elemi egységre van szükség (itt most darabszámra gondolok,) az eredmény kiszámításához. 16->32 váltásnál ez mindennapi probléma lett akkoriban, mert pl. egy 65535 byte-nál nagyobb tömb megfelelő elemének címzésekor már további shift és and utasításokra volt szükség a címzésnél, amik között ráadásul erőteljes függőség is fennállt, tehát a váltás a ''napi életre'' (=szinte minden programra) hatással volt. 32 biten ez (továbbra is fenntartom) egyedi esetekben jön elő, a hétköznapi életben alig van 32 bitnél (pl. 4 GB-nél) nagyobb számítási érték, amit egész értékben számít. (FPU-ra, SSEx-re nincs hatással a 64 bites architecture - hacsak abban nem, hogy az AMD már megszellőztette, hogy nem biztos, hogy az FPU-műveleteknek nincs jövője: ''In general, 64-bit operating systems support the x87 and 3DNow! instructions in 32-bit threads; however, 64-bit operating systems may not support x87 and 3DNow!
instructions in 64-bit threads. To make it easier to later migrate from 32-bit to 64-bit code, you may want to avoid x87 and 3DNow! instructions altogether and use only SSE and SSE2 instructions when writing new 32-bit code'' Ami pedig ''may'', az a közeljövőben ''must'' szokott lenni.
Az általad használt alkalmazásokban (ABC@Home-ban és feltételezem, a Te prím-projectedben is) ''valóban 64-es adatokra van szükség'', mert annál is sokkal nagyobb egész adatokon dolgoznak. Ezesetben tartom, hogy ''viszont több, mint kétszeresen''gyorsul a feldolgozás, de nézzük részletesebben:
- add, sub esetében igaz, hogy feleannyi add és adc kell (''a plusz köztes átvitelek kezelése miatt''), de ha nem volt nagyon nyomorult a kód, akkor az adc az add után már egy másik utasítással párhuzamosan futott le, tehát itt a gyorsulás pár százalákos.
- 64 bites szorzás 32 bitben: gyors közelítésben (ESI és EDI, illetve RSI és RDI mutat a szorzóra és szorzandóra):
..mov edx,[esi+04h]
..mov ecx,[edi+04h]
..or edx,ecx
..mov edx,[edi+00h]
..mov eax,[esi+00h]
..jnz twomul
..mul edx
..jmp @continue
@twomul:
..imul edx,[esi+04h]
..imul ecx,eax
..add ecx,edx
..mul dword ptr [edi+04h]
..add edx,ecx
@continue:
- 64 bites szorzás 64 bitben:
..mov rax,[rsi]
..imul qword ptr [rdi]
Ez nem feleannyi múvelet (még ha a felső, 32 bites teszteléstől el is tekintünk), és figyelembe véve, hogy a 64 bites szorzás latency-je több, mint a 32 bitesé, akkor is több, mint háromszoros gyorsulás számítható. AMD reference szerint két 1024 bites szám szorzásához negyedannyi utasításra van szükség (256 mul, 509 adc, 255 add vs 64 mul,125 adc, 63 add), a négyszeres érték ilyen nagyságrendben konkrétan realizálható). Osztásról ne is beszéljünk.
- hozzá kell tenni, orthogonális művelet esetén 64 bites cím +4 byte, 64 bites azonnali érték +5 byte növekményt jelent az utasítás hosszában, ez itt viszont már erőteljes szávszél-csökkenést jelenthet.
''erre a Microsoft is rádobott egy lapáttal 64 biten'' Ez mit takar?
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3616
üzenetére
A legfrissebbre/legújabbra nem pályázok sosem, ez is nagyjából másfél éve lett összerakva, amikor a lap+2CPU+másfél kiló réz (hűtés gyanánt) kevesebben volt, mint egy 3800+ X2 önmagában.
A CPU-k így sincsenek messze a fejenkénti 100W-tól (vcore: 1.78V), és a monitorom se keveset fogyaszt napi 16-18 óra használattal, de a lélektani havi 10K áramszámlát én sem szeretném túllépni.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3614
üzenetére
Én erősen gondolkodok egy 2x dualcore Opteron konfigon, a memóriák már majdnem megvannak (eddig 3 db 512-es 400 MHz regECC Corsair sorakozik a gépben, ebből kettő egyforma), ''matched pair Opteron 275'' kb. 50K Ft+posta lenne tengerentúli ebay-ről, a lap kérdéses még.
Illetve inkább az kérdéses, hogy normális dolog-e itthon ilyen gépet nevelni, ezen filozofálok már egy ideje, meg azon, hogy ez a mostani gépem annyira unikum, és annyira megszerettem, hogy nem tudok megválni tőle. Pedig a 64 bit terjedése miatt pár éven belül kevés dologra lesz jó. . -
P.H.
senior tag
válasz
#95904256
#3611
üzenetére
Csak én szoktam napi rendszerességgel nézni, hogy a csapat és a tagok hogy állnak (results, géppark, aktivitás, stb)?
Van még előnyöd bőven, majd ősszel visszatérünk a témára. (Ha most megállnál, kb. 120 nap alatt ledolgoznám, 24/7 miatt.) Amúgy megint bejöttek olyan grid-ek, amik csomagjainak végrehajtása 8-10%-kal gyorsabb, azonos creditérték mellett (10K vs 8x00 másodperc)).
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3608
üzenetére
Ez ''remek''
Jelenlegi pending credit-em pontosan 7000, ebből kb. 6700 vár csak validate-ra, naponta csordogál 200-300 credit nagy nehezen, már két hete.
Nem gondoltam volna, hogy a 200K creditet úgy fogom elérni (már csak 220 hiányzik), hogy ''elméletben'' már 210K meglesz... -
P.H.
senior tag
válasz
#95904256
#3593
üzenetére
Ha jól sejtem, ez csak 32 biten el nem férő egészaritmetikánál érdekes. (Ezzel eddig, megvallom, lemezterület-számításnál találkoztam, de persze nem magamból kell kiindulni.) Általános felhasználásban ha egy adott eredmény tudottan 32 bit-en elfér, akkor a 64 bit nem gyorsít (persze nem is lassít), ez pedig még ma is ritka. Tudom, hogy Te 64 bit-nél is sokkal nagyobb adatokon dolgozol általában, de ismereteim szerint a 64 bit akkor tud gyorsítani, ha valóban 64-es adatokra van szükség (akkor viszont több, mint kétszeresen), illetve a kétszer több (közvetlenül nevezhető) register miatt a registernyomás csökkenése által (JPEG, movie-decoding, hasonlók esetén) monduk 1x %-kal (mivel az adat már az L1-ben van amúgy is).
(Ez a ''kétszeres gyorsulás'' mindig emlékeztet az Intel Pentium 4 doksi HT&MP fejezetére, amiben aztán a bevezetőben kimutatja, hogy ha az eljárás félig párhuzamosítható, akkor a gyorsulás 33%-os lesz)
[Szerkesztve] -
P.H.
senior tag
válasz
Csapi007
#3560
üzenetére
Mondhatnám, hogy...
de inkább nem mondom.
Nagy túlzással arra, hogy össze lehessen hasonlítani, hogy ki mennyi részt vállalt be eddig az egyes project-ekben, illetve mennyi számítási kapacitást adott a project-ekbe összesen.
(De ez ilyen formában nem igaz, mivel minden project a saját szája íze szerint osztja a krediteket. Egy elvégzett munkára ''kérsz'' valamennyi kreditet (claimed credits) és kapsz (granted credits), utóbbi a fontos, így lehet vezetni statitsztikákat, hogy ki mennyit, mikor, mennyire.)
[Szerkesztve] -
P.H.
senior tag
Csütörtökön figyelmeztetett a BOINC, hogy az Einstein app_info.xml-jét távolítsam el, mert új klienst akar letölteni hozzá (még 4.24-es kliens eredeti bétája volt fenn). Ez meg is történt, azóta újfajta csomagokon dolgozok. A változás onnan észrevehető, hogy a csomagnevekben
h1_0424.0_S5R1__3046_S5RIa_x szerepel (tehát I a korábbi 1-es helyett).
A csomagok feldolgozási ideje nálam 2000 mp-ről 10000 mp-re növekedett, a kapott kredit elég rapszodikusan alakul, egy grid-re 5x (ami elég kevés), más grid-re 8x körül vannak a csomagok, ami viszont sok, tekintve, hogy a feldolgozási idejük kb. azonos, és ötszörösre nőtt a 12.xx-es csomagokhoz képest.
Ahogy látom, a csapat több tagja is megkapta már az új csomagokat.
A magyarázat tegnap megjelent az Einstein főoldalán is: a hierarchikus kereső elkészültéig meghosszabbítják az R1 szakaszt.
Viszont továbbra is hardware-problémákkal küszködnek.
[Szerkesztve] -
P.H.
senior tag
11-én dobtam fel, hogy leállás van a levegőben Einstein-nél, a netes oldal (kisebb megszakításokkal) azóta is megy, a csomagküldés azóta is akadozik (a feltöltés simán megy, viszont a reporting és új csomag csak kézi Update-re, egy napja az sem), viszont 11-e óta a főoldal Server Status linkje folyamatosan egy
''The server status page has temporarily been taken offline due to database problems'' üzenetre mutat. Csak nincs komolyabb gond... -
#3519
P.H.
senior tag
concret_hp
#3513
P.H.
senior tag
válasz
concret_hp
#3513
üzenetére
''1 unit mondjuk 12. akkor az 80 unit, azaz óránként több mint 3 ha egész nap megy a gép.''
(AMD-s gépeken) pontosan, ahogy leírtad, plusz 2400 MHz körüli Bartonon, A64-en, Opteronon vagy X2-magon is fél óra körül van egy csomag. Onnantól azon múlik, mennyi van ezekből (egy gépben).
Hajnal fél 3 óta megint bizonytalan az Einstein, fél 6-kor sikerült először kapcsolatba lépni vele, azóta sem. Újabb leállás van a levegőben.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3508
üzenetére
Hát igen, mióta ráállítottam a teljes gépet, pörög rendesen...
Az idei két leállás ellenére eddig 7000 credit összejött a 9 nap alatt, a BOINCStats szerint. Vajon a S5R1 vége előtt bekerülök a top10K-ba? Most 13232. vagyok.
A jelenlegi server status szerint még 18.8 nap van (8,3xx%) hátra.
[mod]: ha már a KB/MB/GB -> KiB/MiB/GiB hülyeséget átvitte valaki, akkor a legkevesebb ez a megegyezés...
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3491
üzenetére
Tudom, hogy a csomagok között vannak eltérések, egy grid-en belül is.
Én erre céloztam: [link]. Biztos vagyok benne, hogy azonos kredit fog járni a megjelölt csomagokra (majd meglátjuk, ha végre...). És ezt bármikor meg tudom ismételni (pontosabban jelen pillanatban sajnos nem, érthető okok miatt ), kis és nagy csomagokkal egyaránt, egy tizenegynéhány tab-es Opera mellett mindig megnő a feldolgozáshoz szükséges idő, konstans kreditszám mellett.
Más programnál még nem vettem észre ilyen mértékű növekedést, pedig az Opera is úgy van beállítva, hogy csak olyan oldalon legyen mozgó/aminált elem, ahol én akarom.
''a cache memória tartalmának változása alig zavarja''
Az elmélet és a gyakorlat elméletileg nem különbözik. Gyakorlatban viszont igen. -
#3484
P.H.
senior tag
concret_hp
#3483
P.H.
senior tag
válasz
concret_hp
#3483
üzenetére
Az Einstein elég érzékeny arra, hogy mi fut mellette (vagy esetedben a háttérben. Val'szeg egy reinstall után kevesebb dolog).
Én pl. ha Operát indítok, akkor kb. ennyivel (~10%) lassabban lesznek készen a csomagok, pedig egy böngésző tényleg nem használ túl sok erőforrást. Viszont a folyamatos 6-8%-os CPU-időt foglaló TV-tuner-t meg sem érzi.
[mod] Illetve az sem mindegy, hogy milyen xxxx értékű h1_xxxx.0_S5R1... (vagy l1_xxxx.0_S5R1...) menetet futtatsz éppen, azok között is vannak eltérések, időbeli és kreditbeli egyaránt.
[Szerkesztve] -
P.H.
senior tag
A egyik telepítéskori beállítás befolyásolja, hogy automatikusan tálcán induljon, én is szenvedtem egyszer ezzel, utólagos beállításra nem találtam lehetőséget. Hacsak az nem, hogy az Start menü/Indítópultban a cél
''C:\Program Files\BOINC\boincmgr.exe'' /s
legyen, így, /s-sel a végén. Ha ez is stimmel, akkor futtasd le a BOINC telepítőjét mégegyszer, ugyanoda, csak állítsd be assz'em azt, hogy automatikusan induljon a Windows-szal együtt, ott a Single user/Advanced user/Service mode környékén/után kérdez rá.
(Val'szeg az install után ugyanonnan fogja folytatni a csomagokat, nem kell kifuttatni őket, legalábbis verziót simán lehet így frissíteni.)
[Szerkesztve] -
P.H.
senior tag
Ilyenkor szoktál egy Advanced/Retry Communications-t vagy csak simán egy Update-et nyomni az Einstein-re (vagy bármely project-re)? Van a Boinc-nak egy ilyen hülyesége, hogy ha nem tud kapcsolódni egy projecthez, akkor egyre hosszabb idő múlva próbálja automatikusan újra. Ha egy napig nem sikerül, akkor már egy hét múlva próbálkozik újra. És ez restart-tól független, ha újraindítod a géped, vagy a BOINC-ot, akkor is emlékszik arra, hogy mennyi időt akar várni.
-
P.H.
senior tag
válasz
BlacKSouL
#3339
üzenetére
Nekem kb. havonta egy-két ilyen csomagom van. Vagy átviteli, vagy splitter hiba lehet (sokszor az ilyenek client error-ral leállnak minden feldolgozónál), illetve ilyenkor szokott eszembejutni, hogy ebben a csomagban van valami, és inkább majd ők maguk dolgozzák fel.
[Szerkesztve] -
P.H.
senior tag
Én ezt úgy szoktam megoldani, hogy reinstall előtt leállítom a BOINC-ot (futás közben pár file-t fog, nem lehet olvasni/betömöríteni sem őket), bezippelem a Program Files\BOINC könyvtárat, felteszem a Windows-t, feltelepítem a BOINC-ot, majd mielőtt elindítanám, a ZIP-ből visszaállítom/felülírom a Program Files\BOINC könyvtár tartalmát.
Elindítás után ugyanonnan folytatja.
[mod]: no finished file, ahogy figyeltem, a BOINC átmeneti hibája (is) lehet, mert nekem egyszerre szokta jelezni SETI-re és Einstein-re.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3277
üzenetére
Disassemblernek a PE Explorer a legjobb választás szerintem is, bár most agyalok egy saját fejlesztésen, ami jobban megfelel az igényeimnek, esetlegesen kibővítve a későbbiekben egy (vissza)fordítóval. A másik két felsoroltat nem ismerem. Én visszafordításra egy (nem vicces
) Delphi (prancssoros) fordítóval számolnék: bár nem láttam még olyan gépet, amin az IDE-t ne fogná meg már egy 20 000 soros assembly+comment project, de kevesebb, mint egy másodperc alatt fordítja, látható erőlködés nélkül (erre utalt a fenti ''kis bevezető munka'' kifejezés is, kivenni a visszafajtett startup kódot, a resource-kat, stb).
A Einsteni így, csak kívülről nézve azért tűnt összeszedettebbnek, mert
- kisebb a memóriahasználata, sokkal
- nincs folyamatos memória-újrafoglalás (512 MB RAM mellett sem használtam swap-et, és ha lement 50-60 körülire a szabad méret, azonnal leállt, hogy nincs elég memória, Einstein 1 MB szabad RAM-mal is futott tovább)
- az Einstein-t futtató procim mindig 1-2 fokkal melegebb, mint a Seti-t futtató (utóbbi eléggé szenved 133+ FSB-n). Itt azért már elképzelhető egy valamelyest optimális L2-cache-kihasználtság is. -
P.H.
senior tag
válasz
#95904256
#3275
üzenetére
Valamikor anno, amikor elkezdtem Seti-zni, akkor nekem is volt ilyen gondolatom, hogy rászánok valamennyi időt, és átírogatom assembly-be (végülis majdnem ezt csinálom főállásban is), bele is néztem a C forrásba, de kilátástalannak tűnt erre elindulni, a forrás miatt is, és amiatt is, hogy a kliensek változnak időnként, és akkor elölről kell kezdeni az egészet.
Ha nekifognék, és lenne rá időm, én disassembly felé indulnék el, assembly -> assembly lényegesen egyszerűbb (szinte gépiesen optimalizálhatók kisebb kódrészek, egyszerűbb, mint először felfogni a teljes kód értelmét; nem kell a spec. VC++ rutinokhoz kapcsolódni, stb.), és a kliens-változások is jobban következők lennének ilyen szinten (pl. írni egy kis progit, ami két disass' kódból kijelöli a változatlan kódrészeket), és egy kis bevezető munka után a teljes átírás bármikor fordítható lesz, nem kell megvárni a teszteléssel az első teljes átírást. Mindemellett egy ilyen magas szintű fordítóval fordított kódból (ha külön nem figyelnek oda erre) egy jó disass'-szel szinte csak a kommenteket nem tudod visszaszedni.
[mod]: ezért kértem fentebb az Einstein-forrást is, hogy belenézzek, bár az jóval összeszedettebbnek tűnik, a program teljesítménye alapján. Azt nem tudtam, hogy az nem nyilvános. De egyszer, ha lesz valamennyi szabadidőm (bár lenne...), egy disass'-nyi időt rászánok.
[Szerkesztve] -
P.H.
senior tag
-
#3200
P.H.
senior tag
(Kolombusz)
#3199
P.H.
senior tag
válasz
(Kolombusz)
#3199
üzenetére
Low priority-re állítja be magát, szóval ha kell a CPU másra, akkor leáll.
Tehát gyakorlatilag a háttérban fut, a kihasználatlan időben, ne félj tőle.
[Szerkesztve] -
P.H.
senior tag
Vasárnap hajnal óta (3 napja, nem sokkal kovido után) csak S5 csomagjaim vannak, eddig több, mint 60 csomag lement. Mindegyik csomag kb. azonos méretű, 58-65 perc alatt vannak kész, mindegyikre 19.78 a claimed és a granted credit (az eddigi 3 óra 45 perces átlag és 45-50 claimed credit helyett), és mindegyik neve h1_0333.0_S5R1__-gyel kezdődik.
Furcsa. Se nagyobb, se más nevű csomagot nem kaptam eddig. Mindenesetre elég nagy RAC-blast-ot okozott, 2 nap alatt több, mint 25%-os emelkedés. -
P.H.
senior tag
Bár én nem Roland vagyok, de:
- BOINC-ban klikk a ''Your Account''-ra
- a lapon Einstein@Home preferences mellett klikk a View or edit-re
Középen van a ''Should Einstein@Home show your computers on its web site?'' kérdés, ami ha minden igaz, neked no-ra van állítva. Az ''Edit Einstein@Home preferences''-re kattintva át tudod írni yes-re.
), amit az adatlapomon olvashatsz; kb. egy évig csak Einstein-t futtattam (ennek jelenleg is jobb a CPU-kihasználása, kb. 1-1.2 IPC folyamatosan, a gyári SETI Astropulse 0.7-0.9 IPC között van, az SSE3-ast még nem néztem, tehát Einstein mellett elég magas a fogyasztás), így havi 8K-t evett a gép, két 68W-os F2 Opteron-nal, semmilyen vga-val. Most a héten vettem egy 50W-os passzív 9500GT-t, én ennél többet nem szánok a GPU-számításokra.
). Lehetséges, hogy ide-oda ''másolgatja'' a 3 MB-nyi feldolgozott adatot, lehetséges, hogy a 3 MB-ok ideiglenes területek, de mindkét esetben sokkal jobb lett volna előre lefoglalt fix pufferelést használni. (Előbbi esetben, ha nem lehet helyben feldolgozni, akkor egy dual-buffer megoldás már elég lehet, utóbbi esetben egy quad- vagy nyolcas pufferrendszer non-temporal store-okkal. Legjobb persze a helyben feldolgozás lenne. Vagy az, hogy az egyszerre letöltött nagyméretű adatot - legalább részben - 512 KB cache-re optimalizálva 256 KB-os chunk-okban dolgozza fel, de ennek megoldhatósága algoritmusfüggő).
Új hozzászólás Aktív témák
Hirdetés
- OLED TV topic
- Kiszivárgott a Pixel 10 Pro
- A fociról könnyedén, egy baráti társaságban
- Milyen belső merevlemezt vegyek?
- World of Tanks - MMO
- iPhone topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Háztartási gépek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- További aktív témák...
- Assassin's Creed Shadows Collector's Edition PC
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Bomba ár! Lenovo IdeaPad 330S-15IKB - i5-8G I 8GB I 256SSD I 15,6" FHD I HDMI I Cam I W11 I Gari!
- Telefon felvásárlás!! Honor Magic6 Lite, Honor Magic6 Pro, Honor Magic7 Lite, Honor Magic7 Pro
- Azonnali készpénzes AMD Radeon RX 5000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Csere-Beszámítás! RTX Számítógép PC Játékra! R5 8400F / RTX 3070Ti / 32GB DDR5 / 1TB SSD
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest