Sipas përkufizimit zyrtar të propozuar nga OSHWA.org: “Zgjidhjet e hapura harduerike janë zgjidhje, dizajni i të cilave është i disponueshëm publikisht dhe i hapur për studim, modifikim, shpërndarje, shitje. Kjo vlen si për vetë zgjidhjen ashtu edhe për derivatet dhe përbërësit e saj. Të dhënat fillestare të projektit dhe përbërësve të tij duhet të paraqiten në një format që lejon modifikimin e mëtejshëm të tyre. Në mënyrë ideale, hardueri me burim të hapur shfrytëzon mjetet dhe materialet lehtësisht të disponueshme, proceset standarde, infrastrukturën e hapur, përmbajtjen falas dhe mjetet e zhvillimit me burim të hapur për t'u dhënë përdoruesve lirinë maksimale për ta përdorur atë.

Vlen të përmendet këtu se platformat harduerike me burim të hapur nuk kërkohet të ofrojnë mjete zhvillimi falas. Mjetet e zhvillimit i referohen një game të gjerë mjetesh projektimi dhe korrigjimi, duke filluar nga instrumentet (multimetra, oshiloskopë) dhe mjediset e integruara (IDE) deri te shërbimet e bazuara në ueb që ofrojnë menaxhim funksional të projektit. Është e rëndësishme të theksohet se shumë nga platformat e njohura me burim të hapur si Arduino, LaunchPad, BeagleBone dhe STM Nucleo ofrojnë biblioteka softuerësh falas, mostra kodesh dhe madje edhe korniza të tëra si Arduino IDE ose mbed.org.

Disa mjete zhvillimi janë vetë platforma me burim të hapur, duke i bërë ato mjaft të përballueshme për shkak të kostos së tyre relativisht të ulët. Një shembull është bordi i gjithanshëm i matjes i Red Pitaya që drejton Linux. Në fakt, Red Pitaya është një kompleks matës që zëvendëson pajisjet laboratorike që janë të paarritshme për përdoruesit e zakonshëm për shkak të çmimit të lartë. Red Pitaya u ofron zhvilluesve hyrje analoge me një shkallë matjeje deri në 125 MSPS dhe dalje me një shkallë matjeje prej 100 KSPS. Ky instrument matës i gjithanshëm mund të veprojë si një shumëllojshmëri instrumentesh standarde, të tilla si: një oshiloskop me një gjerësi brezi prej rreth 50 MHz, një analizues spektri, një matës i rezistencës LCR, një analizues Bode, një teslametër, një gjenerator funksioni me rezolucion 14-bit. , duke përfshirë të përshtatshme për audio, etj. Për të shfaqur rezultatet e matjes, Red Pitaya lidhet me një tablet, PC ose smartphone. Shtoni modulin e zgjerimit të sensorit dhe mund të lidhni Red Pitaya me bordet Arduino dhe sensorët SEEED Studio Grove, duke zgjeruar më tej funksionalitetin e këtij kompleksi matës.

Oriz. 1. Sistemi Universal i Matjes Red Pitaya është një shembull i një platforme të hapur harduerike dhe është jashtëzakonisht i përballueshëm. Red Pitaya ka funksionalitetin e një oshiloskopi, analizuesi i spektrit, matësi i rezistencës, analizuesi i sinjalit, testametri, si gjenerator funksioni, etj.

Bordi Red Pitaya u prezantua në platformën e internetit Kickstarter në 2013. Ai u bë një spin-off për një kompani që zhvillon instrumente për përshpejtuesit e grimcave. Si i tillë, Red Pitaya është një mjet matjeje dhe kontrolli me burim të hapur me mbështetje programimi vizual. Red Pitaya mbështetet nga Matlab, LabView, Python dhe Scilab. Falë kodit të tij me burim të hapur, Red Pitaya mund të zgjerohet me veçori dhe shërbime shtesë të krijuara nga përdoruesit.

Shumë platforma me burim të hapur mund të shndërrohen gjithashtu në mjete zhvillimi. Për shembull, mund të krijoni një analizues logjik dixhital duke përdorur Arduino UNO. Megjithatë, duhet theksuar se ky nuk është funksioni kryesor i platformave të tilla. Në fakt, shumica e zgjidhjeve me burim të hapur janë krijuar për t'ju ndihmuar të testoni, korrigjoni dhe zgjidhni problemet. Në këtë rast, edhe bordi më i mirë i korrigjimit është i padobishëm nëse nuk ka dokumentacion të plotë dhe të detajuar për të.

Le të hedhim një vështrim në mjetet më të zakonshme të përdorura kur punoni me platforma harduerike me burim të hapur.

1. Mjeti i parë i projektimit është ndoshta më i rëndësishmi dhe më pak "teknik". Ky është një laps i zakonshëm. Është lapsi që ju lejon të "mishëroni" menjëherë idetë e konceptuara në letër, të shënoni rezultatet e testit dhe të rregulloni ndryshimet në mënyrë që të rivendosni më tej tërë pamjen e projektit muaj apo edhe vite më vonë.
2. Pajisjet. Kjo përfshin një gamë të gjerë mjetesh, duke filluar nga instrumentet matëse (multimetra, oshiloskopë) deri te organizatorët për ruajtjen e komponentëve elektronikë. Fatkeqësisht, pajisja nuk është aspak e lirë, por nëse jeni afër komunitetit të zhvilluesve, huazimi i një ose një tjetër pajisjeje matëse nuk do të jetë problem. Përveç kësaj, shumë mjete tani janë në dispozicion përmes blerjeve online dhe shiten me çmime shumë të ulëta.
3. Programimi në kodin e makinës nuk është i lehtë, kështu që përpiluesit dhe interpretuesit përdoren për të krijuar softuer të integruar për t'u mundësuar zhvilluesve të shkruajnë programe duke përdorur gjuhë të nivelit të lartë apo edhe të bëjnë programim grafik.

Një mjet tjetër për zhvillimin e softuerit të integruar janë mjediset e integruara (IDE). IDE-të janë platforma softuerike që integrojnë një redaktues burimi, përpilues / interpretues, korrigjues, mjet automatizimi ndërtimi dhe ndonjëherë mjete testimi. Shumë korniza ju lejojnë të korrigjoni kodin tuaj dhe të analizoni se si funksionon në pajisjet reale. Ka mjete për të ndihmuar në vizualizimin e performancës së pajisjes dhe kryerjen e simulimeve përpara se të ndërtohet një prototip i vërtetë. IDE-të thjeshtojnë dhe shpejtojnë shumë procesin e zhvillimit.

Mjetet e zhvillimit dhe redaktimit të softuerit zakonisht krijohen për bërthama të veçanta të procesorit. Për shumicën e pllakave, prodhuesit specifikojnë se cilin mjedis zhvillimi duhet të përdorin.

Le të shohim llojet kryesore të IDE-ve të përdorura për të krijuar softuer të integruar:

1. Mjedise zhvillimi të integruara falas (IDE) si Arduino IDE, Energia IDE për TI LaunchPads, të cilat mund të shkarkohen lirisht nga faqja e internetit e prodhuesit dhe të instalohen në kompjuterin tuaj.
2. IDE-të në internet që nuk kërkojnë instalim në një kompjuter, por kanë nevojë për qasje në internet. Përparësitë e tyre janë se nuk kërkojnë përditësime dhe nuk zënë hapësirë ​​në hard diskun tuaj. Një shembull i programeve të tilla është Mbed.org.
3. Mjedise zhvillimi me pagesë. Siç u përmend më lart, përpiluesit ju lejojnë të punoni me një lloj të caktuar të bërthamave të procesorit, ose për të qenë të saktë, me një grup të caktuar të procesorëve / mikrokontrolluesve të veçantë. Për shembull, nëse jeni duke përdorur një palë procesorë me një bërthamë ARM ® Cortex ® -M4, atëherë është shumë e mundur që një procesor të mbështetet nga IDE, dhe tjetri jo. Prandaj, përpara se të blini një IDE, duhet të kontrolloni që procesori i synuar është në listën e pajisjeve të mbështetura. Shembuj të mjediseve të zhvillimit me pagesë janë Keil nga ARM dhe IAR Embedded Workbench nga IAR Systems.
4. Provat falas të kufizuara në kohë të mjediseve me pagesë. Shumë IDE, si IAR dhe Keil, kanë prova falas me një periudhë prove të kufizuar falas. Pas përfundimit të periudhës së provës, programi bllokohet dhe kërkon blerjen e një licence.
5. Versione falas të mjediseve me pagesë me funksionalitet të kufizuar. Ekzistojnë versione të kufizuara të mjediseve me pagesë me funksionalitet të reduktuar. Një shembull i një mjedisi të tillë është montimi Keil për mikrokontrolluesit STM32L0 me një madhësi të kufizuar kodi.
6. Mjedise falas me burim të hapur si zgjidhje të ndryshme GNU. Eclipse IDE është një shembull i një mjedisi të lirë. Eclipse IDE ju lejon të shtoni shtojca për të mbështetur gjuhë të ndryshme programimi si C ++ ose Python. Duhet të theksohet se në shumicën e rasteve përpiluesit e lirë janë inferiorë ndaj homologëve të tyre komercialë për sa i përket cilësisë së optimizimit të kodit. Megjithatë, me kalimin e kohës, kjo vonesë po ngushtohet.
7. Mikrokontrolluesit vijnë nga prodhuesi në një formë të paprogramuar. Për "firmware" fizik të programeve, kërkohet një pajisje e veçantë - një programues. Përjashtim bëjnë mikrokontrolluesit që kanë një ngarkues të integruar (bootloader). Bootloader është një program i vogël i integruar që ju lejon të programoni mikrokontrolluesit duke përdorur një nga ndërfaqet e njohura USB, UART, CAN, etj.

Le të shqyrtojmë opsionet për programimin e mikrokontrolluesve pa një ngarkues të integruar.

• Shumë borde të njohura (si LaunchPad dhe Nucleo) kanë programues të integruar. Kjo i lejon ata të lidhen me një kompjuter përmes USB dhe programimit.
• Për bordet që nuk kanë një programues të integruar, duhet të përdorni programimin në sistem (ISP). Kjo kërkon një programues të jashtëm. Zakonisht programuesi lidhet me një PC nëpërmjet USB-së ose portit COM, dhe me mikrokontrolluesin përmes një ndërfaqe të veçantë programimi (SWIM, JTAG, SPI, UART, etj.). Shembujt përfshijnë programues ST-LINK / V2-1 për mikrokontrolluesit STM32 / STM8 nga STMicroelectronics, programuesit nga Atmel për mikrokontrolluesit AVR, programuesit nga Microchip për mikrokontrolluesit e familjes PIC.

Oriz. 2. STM32 Nucleo është një shembull kryesor i një platforme të hapur. Pllakat nukleo vijnë me një korrigjues të integruar ST-LINK / V2-1 (i theksuar me të kuqe)

1. Debugers. Një korrigjues është një koleksion mjetesh që i lejon programuesit të gjurmojnë ekzekutimin e programit dhe të identifikojnë gabimet në kodin e tyre. Një korrigjues përbëhet nga tre pjesë kryesore: një pjesë softuerike që funksionon në IDE, një pjesë harduerike që zbatohet në një mikrokontrollues dhe një pjesë harduerike që zbatohet në një pajisje të veçantë të quajtur gjithashtu korrigjues. Vlen të përmendet këtu se për të gjithë mikrokontrolluesit modernë, programuesi dhe debugger-i përfaqësojnë të njëjtën pajisje. Prandaj, për shembull, për programimin dhe korrigjimin e STM32 / STM8, programuesi / korrigjuesi ST-LINK / V2-1 do të jetë i mjaftueshëm.

Le të hedhim një vështrim në disa nga elementët dhe mjetet kryesore të përdorura gjatë korrigjimit të sistemeve të integruara:

• GDB ose GNU Debugger janë korrigjues të njohur të softuerit që përdoren për të punuar me gjuhë të ndryshme programimi. Shumë prej tyre mbështesin "modalitetin e largët", i cili ju lejon të kontrolloni pajisjen që korrigjohet duke përdorur një aplikacion që funksionon në kompjuterin tuaj.
• JTAG është një ndërfaqe që fillimisht u zhvillua për testimin e sistemeve të integruara, por më vonë "de fakto" u bë një standard i industrisë. JTAG përdoret gjerësisht sot, duke përfshirë në platformat e hapura.
• Pikat e ndërprerjes përdoren për të ndërprerë ekzekutimin e programeve në vendet e duhura. Ky funksion është i nevojshëm për shqyrtimin e detajuar të kontekstit, për shembull, gjendjen e porteve I/O, përmbajtjen e regjistrave, etj. Një veçori tjetër e dobishme e korrigjuesve është aftësia për të korrigjuar hap pas hapi një program.
• Open OCD (Open On-Chip Debugger) është një paketë me burim të hapur që ofron korrigjimin e integruar, programim në çip dhe testim për një larmi të madhe platformash, duke e bërë OCD të hapur tërheqëse për shumë prodhues të çipave. OCD e hapur mbështet shumë korrigjues, duke përfshirë JTAG.

1. Mjetet e gjurmimit të gabimeve dhe kontrollit të versionit

• Të kesh një mjet për gjurmimin e gabimeve është një domosdoshmëri për platformat me burim të hapur, pavarësisht nga numri i zhvilluesve dhe përdoruesve. Ka shumë mjete të disponueshme për gjurmimin e gabimeve. Për shembull, Bugzilla ose Mantis BT mund të shkarkohen dhe instalohen në serverë falas, dhe ka shërbime që mund të ofrojnë pritje për një tarifë nominale.
• Sistemet e kontrollit të versioneve janë një mjet tjetër që është kritik për platformat e hapura, veçanërisht pasi platformat e hapura përfshijnë shumë përdorues dhe zhvillues që punojnë së bashku. Mjetet si Git dhe Subversion janë sisteme të njohura të kontrollit të burimit dhe përmbajtjes. Shërbime të ngjashme me GitHub ofrojnë pritje të përmbajtjes së projektit, gjurmim të gabimeve dhe rishikime të kodit bashkëpunues.

Platformat e hapura të harduerit ndihmojnë për të thjeshtuar procesin e zhvillimit dhe për të ulur ndjeshëm koston e tij. Në të njëjtën kohë, platforma duhet të ketë mjete zhvillimi dhe korrigjimi të besueshme dhe të lira, përndryshe nuk ka gjasa të ngjall interes tek përdoruesit.

Në vend të një përfundimi, u mendua edhe një

Shumë shpesh, zhvilluesit kufizohen të bëhen specialistë brenda një procesori të vetëm ose mikrokontrollues. Sigurisht, një studim i plotë i të gjithë regjistrave dhe veçorive të bërthamës së procesorit është një plus i madh për një projekt specifik. Sidoqoftë, vlen të përmendet se teknologjia nuk qëndron ende, dhe aftësia për t'u përshtatur shpejt me platforma të ndryshme është një aftësi shumë më e vlefshme sesa njohja e të gjitha ndërlikimeve të një zgjidhjeje të vetme. Projektet me burim të hapur thjeshtojnë shumë të mësuarit në shkallë të gjerë duke ulur koston dhe kohën. Mundohuni të merrni pak përvojë me Arduino, vendosni duart në mikrokontrolluesit PIC, punoni me një programues të jashtëm! Ky proces vetë-edukimi mund të ndihmojë edhe studentët pa përvojë të gjejnë një punë, për shembull, nëse "ndizen" në ndonjë forum. Zotërimi i zgjidhjeve dhe arkitekturave të ndryshme do të përmirësojë aftësitë tuaja të vetë-studimit, gjë që do të çojë në një karrierë të gjatë dhe të suksesshme.

Përgatitja paraprake

- Të gjithë, ju lutemi, respektoni rripin e sigurimit dhe nuk janë ndezur tabelat e pirjes së duhanit. Uluni dhe shijoni udhëtimin tuaj.

Pra, në rregull.
Testimi kryhet në të gjitha fazat e jetës së pajisjes. Testimi mund të jetë testimi fillestar (bringup), komponenti, funksional, ngarkesa, prodhimi dhe madje edhe testimi i klientit.

Edhe në fazën e zhvillimit të pajisjeve, inxhinieri mendon se si do të ringjallë mendjen e tij. Pllakat janë të spërkatura me pika testimi, lidhës korrigjimi, kërcyes, gjurmë për pjesë rezervë dhe të ngjashme. Kompleti i aftësive të testimit të integruara në pajisje quhet DFT (Design for Testability). Një tabelë e lëshuar në fazën DFT mund të përmbajë dy herë më shumë komponentë sesa një tabelë e lëshuar në prodhim. Natyrisht, duke ndjekur parimin "funksionon - mos e prek", atëherë askush nuk e ribërë, dhe konsumatori përfundimtar habitet nga vendet bosh në motherboard nga dyqani, duke dalë me teori të ndryshme konspirative për qëllimin e tyre.

Pra, ata na morën bordin nga fabrika - çfarë të bëjmë më pas? Epo, sigurisht - futeni në një prizë dhe lëshoni të gjithë tymin e bardhë prej tij.

- Të gjithë bien herën e parë.

Foto nga interneti, ne nuk kishim asnjë dërrasë të djegur, por rrëfej - ndonjëherë kjo bëhet. Në kujtesën time ka një histori të gjatë, kur një arkitekt kurioz sistemi u ul dhe zgjidhte rastësisht se cilët lidhës do të futte fazën, neutralin dhe tokën (epo, ai nuk kishte kohë të shikonte në qark), dhe zhvilluesi u ul. pranë tij dhe e kapi atë të zbehtë.

Por zakonisht ndodh ndryshe. Faza e parë e testimit është ringjallja (popullorisht "ringjall").

Rivitalizimi Lindja

- Zgjohu, Neo...

Për një sjellje, zakonisht bëhen 3-5 mostra (duke supozuar se të paktën dy do të shkatërrohen në delirin e korrigjimit). Nëse pajisja përmban çipa të shtrenjta, ato nuk janë instaluar në një nga mostrat. Fab mund t'ju ofrojë të kurseni në ar - MOS PAJTOHNI NË ASNJË RAST (epo, thjesht duhet të lidhni shumë dhe shpesh).

Një dërrasë pa çip është kandidati i parë për therje. Ai kontrollon sekuencën e ngritjes së energjisë, rivendosjen, vlerësimet e tensionit dhe të ngjashme. Atëherë një tarifë e tillë është një dhurues organesh dhe/ose një terren testimi për testimin e të gjitha llojeve të hipotezave. Gjithashtu, përpara se të ndizni diçka, duhet:

• telefononi furnizimin me energji në tokë, shpesh ka një qark të shkurtër;
• inspektoni vizualisht tabelën - polariteti i kondensatorëve ngatërrohet lehtësisht atje, çipat janë me kokë poshtë, ka patate të skuqura, mund të gjeni lehtësisht përbërës pasivë që janë grisur;
• studioni veçmas - dhe a nuk i keni vendosur në tabelë përbërësit që keni kërkuar të mos instaloni (hack jetësor: mos bëni një maskë të zezë në mostrat e para - nuk është e dukshme nëse janë instaluar ose jo rezistorë çipi mbi të).

Luajtë mjaftueshëm me viktimën e parë - le të shkojmë të fryjmë tym nga bordi luftarak. Në këtë rast, duhet të rezervoni një pilot me një buton të ndërprerjes së energjisë dhe një imazher termik. Piloti duhet të vendoset nën këmbën e tij, në rast se 220 V do t'i godasë duart (mirë, ose thjesht duart do të jenë të zëna), dhe një qark i shkurtër mund të shihet në imazherin termik.

Por në përgjithësi, në ndezjen e parë, zakonisht nuk mund të kesh frikë - me shumë mundësi nuk do të ndizet, pasi me siguri keni harruar të bashkoni përbërësit, këmbët e të cilëve janë të përziera në dizajn:

Dhe bashkoni disa tela të tjerë:

Ngjitësi i nxehtë është gjithçka jonë, miku më i mirë i zhvilluesit, pothuajse si shirit ngjitës në jetën e përditshme.
Menjëherë pas Dremel:

Dhe çekiçi, i cili duhet të vendosë lidhjet në tabelë, nuk del gjithmonë mjeshtërisht.

Ndonjëherë është e nevojshme t'i bëhet pacientit një radiografi ose tomografi. Duket kështu:

Rezulton se nuk është shumë e lehtë të skanosh filmin. E hoqën me telefon para dritares.

Konkretisht, asgjë nuk është e dukshme në këtë foto - mos u shoqëroni. Por në përgjithësi, në rreze X mund të shihni papërshkueshmëri, çarje dhe të ngjashme.

Duhet të themi edhe për ngritjen e pllakave amë, sepse bëhet në një mënyrë tjetër. Mostrat DFT të nënave zakonisht porositen në shumë - rreth 20 copë. Kushton shumë, ndaj ka strategjinë e vet.

Zhvilluesit merren dhe dërgohen në fabrikë. Mblidhen rreth 5 dërrasa dhe transportuesi ndalon. Pastaj zhvilluesit kanë rreth 30 minuta për të ndezur tabelën (për sistemet x86, kriteri i suksesit është të ngarkoni BIOS-in). Nëse të gjithë janë me fat, pjesa tjetër e mostrave mblidhet. Nëse jo, prodhimi anulohet dhe zhvilluesit shkojnë në shtëpi për të menduar. Paratë e shpenzuara për PCB humbasin, por komponentët janë duke pritur në magazinë për përpjekjen e radhës.

Ok - ne lançuam bordin tonë dhe madje lançuam të tjerë që duhet të punojnë me të. Ç'pritet më tej? Montimi i stendës.
Dhe atëherë me siguri prisni ta shihni këtë?

E gjithë kjo është veshje e dritares për zëvendësministrat. Një stendë e vërtetë duhet të bëhet me shkopinj dhe lisa, dhe duket kështu:

- Nuk thashë se do të ishte e lehtë, Neo, thjesht thashë se do të ishte e vërteta.
(një gotë për një kundërpeshë, një stilolaps me majë - në mënyrë që radiatori të ulet vnatyag - është i lidhur atje me një tel)

Hordhia e mëposhtme është paketuar në laborator:

Dhe të gjithë fillojnë të garojnë për të qepur firmware-in, programet e tyre dhe të hedhin një oshiloskop kudo.
Ndonjëherë, gjatë procesit, ka një kërkesë të sjellshme herë pas here: "I dashur koleg, të lutem hiqe hekurin nga dora - është shumë nxehtë" ose "Ji kaq i sjellshëm - mos e ndiz më furnizimin me energji elektrike kur Unë e vidhos tabelën në shasi."

Në rastin tonë të veçantë, qëllimi kryesor i kontrollit të funksionimit të përbashkët të disa pajisjeve është të zbuloni nëse PCI Express funksionon, nëse përputhet me standardin. Thjesht mund të jetosh pa gjithçka tjetër. Zakonisht funksionaliteti i integruar në pjesën e harduerit është i tepërt. Tonelatat e kunjave GPIO, autobusët I2C / SPI, sensorët termikë, akulli dhe të tjera, si rregull, mbeten të pa kërkuara, pasi korrigjimi i tyre shtyhet deri në momentin e fundit, i cili nuk vjen kurrë.

Natyrisht, ne nuk kemi pajisje matëse për çdo rast të jetës për disa milion rubla - kjo është për të dobëtit. Softueri i testimit nga prodhuesit e komponentëve është me nxitim për të na ndihmuar. Pothuajse të gjithë çipat modern me ndërfaqe me shpejtësi të lartë kanë një oshiloskop dixhital brenda. Ai mbështetet në softuer të specializuar që ju lejon të lexoni leximet e tij. Nisni dhe shikoni diagramet e syrit. Ne e shohim këtë:

Ndonjëherë shohim një shikim të rrezikshëm:

Dhe ndonjëherë ne kapim kallamar:

Kallamarët janë më të rrezikshmit. Këto janë shtrembërime jolineare dhe barazuesit e integruar nuk janë veçanërisht në gjendje të merren me këtë. Kallamarët nënkuptojnë që diku në kanalin e komunikimit ka diçka shumë të keqe - një via shumë e gjatë, një rënie e konsiderueshme e rezistencës, një lloj pabarazie në 1/4 ose 1/2 e gjatësisë valore të disa harmonikave në brezin e dobishëm, etj. si ajo.

Dikush mund të vërehet se kallamari është pak i ngjashëm me atë që bën me sinjalin e marrë DFE në EQ të marrësit PCIe. Por në këtë rast, është ende një kallamar, dhe jo rezultat i punës së DFE-së (vetëm softueri që përdorim nuk mund të shfaqë rezultatin e punës së DFE).

Më vete, duhet të them për softuerin e testimit, i cili gjithashtu mund të jetë jashtëzakonisht i fshehtë. Për shembull, për të marrë diagramet e syve, ne përdorim dy versione të të njëjtit program - një version vizaton fotografi, por nuk shkruan vlerën e hapjes së syve, i dyti - përkundrazi.

Epo dhe po - nëse planifikoni të gjuani sytë mbi I2C - harroni se do të jetë shumë shumë e ngadaltë. Vetëm brenda brezit. Problemi është se për marrjen brenda brezit, pajisja juaj duhet të ketë një lidhje PCIe që funksionon me kompjuterin ku funksionon softueri i testimit, gjë që është shumë problematike kur hardueri juaj nuk është i instaluar në një slot standard PCIe. Dhe gjëja më qesharake është se tashmë duhet të keni të paktën një lidhje pune disi në kanalin që po korrigjoni, dhe në atë modalitet (gen2 / 3) në të cilin ju nevojitet (sepse në mënyra të ndryshme sy dhe barazues të ndryshëm funksionojnë ndryshe). Pa këmbë, pa karikatura me lidhje, pa sy - thjesht bëjeni ashtu siç dëshironi.

Rreth asaj se si të dilni nga PCIe - kam shkruar një të veçantë më herët.

Në përgjithësi, kur zhvilloni një server, natyrisht, mbështetja nga prodhuesit e komponentëve të përdorur është shumë e rëndësishme, pasi sot kompleksiteti i çipave edhe relativisht të thjeshtë është i tillë që pa përdorimin e gjërave të testimit të integruar, vështirë se është e mundur. për të kontrolluar dhe korrigjuar plotësisht sistemin. Gjeneratorët e orës, rregullatorët e tensionit, kontrollorët e rrjetit, çelsat PCI Express, ridriverët - e gjithë kjo ka mjete të integruara për konfigurimin, diagnostikimin dhe ka nevojë për një grup të caktuar programesh dhe kabllosh për lidhje për konfigurimin dhe testimin e plotë, pa të cilat zhvillimi bëhet thjesht i pamundur. .

Në procesin e kryerjes së inspektimeve, ndonjëherë rezulton se diçka nuk është në rregull diku. Dhe pastaj fillon procesi emocionues i lokalizimit të gabimit në mënyrë që të mund të rregullohet në rishikimin e ardhshëm. Dhe është mirë nëse kjo "jo kështu" përsëritet vazhdimisht - atëherë zakonisht nuk është e vështirë të zbulosh se cili është saktësisht shkaku i gabimit. Por ndonjëherë gjërat janë shumë më keq. Për shembull, në disa PCB, gjatë një testi të gjatë, shfaqen gabime të vetme të pakorrigjueshme në autobus (të cilat nuk duhet të jenë fare). Dhe këtu shpesh është e nevojshme të përdoret metoda e shikimit - domethënë, thjesht uleni, duke parë hipotetikisht diagramin, mendoni se cila mund të jetë saktësisht arsyeja, përpiquni ta eliminoni këtë arsye hipotetike në diagram dhe përdorni teste për të kontrolluar nëse e kemi marrë me mend atë apo jo.

Ne e hasëm këtë disa vite më parë, kur testet NVIDIA (po, shumë prodhues ofrojnë paketa specifike testimi që na lejojnë të kontrollojmë gjërat që nuk janë të disponueshme në mënyrë programore kur përdorim shërbimet standarde) dhanë gabime të rralla të vetme gjatë ekzekutimeve të gjata (ditore ose më shumë) në disa motherboard... Atëherë e gjithë gjëja doli të ishte një gjurmë e pasuksesshme e orës referuese (100 MHz) - megjithëse para se të arrinim në këtë, u kontrolluan shumë gjithçka, nga cilësia e furnizimit me energji elektrike deri te diagramet e syrit përgjatë të gjitha linjave.

Dhe meqë ra fjala, kjo është mirë. Makthi më i madh i zhvilluesve është kur gjithçka funksionon menjëherë. Kjo do të thotë vetëm një gjë - një minierë është varrosur diku, e cila do të fiket pas dërgesës së 100.500 pjesëve të pajisjeve te klienti. Fakti është se në procesin e kërkimit të shkakut të një problemi global, testohen disa hipoteza dhe, si rregull, zbulohen shumë keqfunksionime të vogla që nuk lidhen me problemin që ka lindur. Asnjë problem i madh - nuk do të gjeni të vogla. Klientët tuaj do t'i gjejnë ato për ju.

Kontrolli i listës

- Gjithçka që bëj është ajo që më thotë të bëj.

Pas përfundimit të testeve të komponentëve, fillon testimi funksional - kontrollimi i funksionalitetit të kompleksit në tërësi dhe funksionimi i saktë i të gjitha funksioneve të integruara. Kjo zakonisht bëhet nga QA. Shtrirja e krijimtarisë këtu, natyrisht, është shumë e gjerë, por në përgjithësi, theksi kryesor është në funksionimin e saktë të sistemit kur luani skenarë të përdorimit standard. Këtu, gabimet e gjetura tashmë mund të jenë të natyrës harduerike dhe softuerike, kështu që para së gjithash është e rëndësishme të zbuloni se çfarë e shkaktoi saktësisht gabimin. Shpesh, supozimet e para mund të jenë mashtruese, domethënë, një problem në dukje i harduerit në shikim të parë mund të shkaktohet nga funksionimi i gabuar i firmuerit. Një pjesë e rëndësishme e testimit funksional është e zënë duke kontrolluar se si sistemi trajton gabimet e ndryshme që mund të lindin gjatë funksionimit. Mjetet moderne të korrigjimit lejojnë injektimin artificial të gabimeve në ndërfaqet standarde të procesorit, sepse në nivelin e harduerit është mjaft problematike të krijohen shumë prej tyre me qëllim (epo, mos i grisni çipat e memories në fluturim ose linjat e autobusëve PCI Express me qark të shkurtër) .

Ah… nuk thashë që testimi funksional nuk do të thotë një sistem i përgatitur për të luftuar. Edhe këtu jo gjithçka shkon mirë. Në një moment, doli që ne nuk kishim kabllo OcuLink të gjatësisë së kërkuar në magazinë dhe serveri mori guxim.

Dhe për disa arsye, në një konfigurim të tillë, gjatë provës së ngarkesës, gjithçka filloi të mbinxehet. Ne ende pyesim veten pse. Me sa duket, kabllot po ngroheshin.

A mund të mbani dy shalqinj në secilën dorë?

- Ti "je më i shpejtë se kaq. Mos mendo se je, dije se je...

Në një moment, paralelisht me testimin funksional, fillon testimi i ngarkesës - është e rëndësishme të siguroheni që serveri të vazhdojë të funksionojë siç duhet në mënyrat maksimale të funksionimit. Për më tepër, testet e stresit kryhen si në lidhje me nënsistemet individuale (disqe, memorie, procesorë, hyrje-dalje), dhe në të gjithë sistemin në tërësi. Si rregull, testet e lokalizuara lejojnë më shumë ngarkesë në një modul specifik sesa mund të bëhet me ngarkesën maksimale në të gjithë sistemin.

Për më tepër, mjetet e korrigjimit nga prodhuesi i platformës harduerike (për shembull, Hardware Tests Executive nga IBM) ndihmojnë këtu. Kështu, ju mund ta drejtoni procesorin në mënyra krejtësisht ekstreme, të cilat janë thelbësisht të paarritshme kur ekzekutoni aplikacione reale. Problemet kryesore të zbuluara gjatë testimit të ngarkesës janë mbinxehja, paqëndrueshmëria e energjisë ose mbingarkesa mbi rrymën maksimale, gabimet gjatë punës aktive me ndërfaqet I / O.

Standardet gjithashtu vijnë në shpëtim. Sepse kur vlerat reale të standardeve janë shumë të ndryshme nga ato të parashikuara, do të thotë se diçka shkoi keq. Një arsye e mirë për të shkuar dhe për të shpuar dërrasën me një shkop.

Në fazën e testimit, ne kryesisht përdorim mikrobenchmarks:
Për procesorët, këto janë zakonisht ngarkesa me një fije, si p.sh spec2006(tani tashmë speccpu2017), parsec, por në përgjithësi ka një numër të madh të tyre nga ndërtimi i kernelit linux dhe kompresimi ( lzma, gzip), përpara shumëzimit të matricës dhe llogaritjes së transformimit të shpejtë Furier ( fftw).
Për kujtesë, asgjë nuk ka ndryshuar për shumë vite: TRAJNIM,RAM shpejtësi SMP, lmbench.

Për disqet: fio, joozoni.

Nëse të gjitha testet funksionale dhe të ngarkesës janë kaluar me sukses, ka ende një sërë gjërash që duhet të kontrollohen - stabiliteti i funksionimit në të gjithë gamën e temperaturës, rezistenca ndaj dridhjeve, verifikimi i përputhshmërisë me një grup të caktuar përbërësish standardë (memorie, disqe, kontrollues PCI Express).

PS: Pasi kontrolluam gjithçka në testet funksionale të rishikimit të parë të serverit dhe ishim të lumtur, tre serverë u rrëzuan papritmas në laboratorin tonë. Ne filluam të kontrollonim furnizimin me energji elektrike dhe në linjën 1.2V (furnizimi me energji elektrike i autobusit të procesorëve PCIe) pamë këtë:

Unë do të doja të tërhiqja vëmendjen tuaj në një qelizë prej 500 mV. Vlera nominale është 1.2 V. Rezistenca u gabua në qarkun e kompensimit të njërit prej VRM-ve. Me këtë lloj furnizimi me energji elektrike, të gjitha testet e ngarkesës, standardet, pjekjet dhe kështu me radhë u kaluan me sukses, dhe dizajni shkoi për fat të mirë në rishikimin e dytë.
Pra, kur një ekran i vdekjes shfaqet papritmas në kompjuterin tuaj komod të shtëpisë të një marke të famshme, nuk duhet të mendoni se ai me siguri do të "gaboi Windows".

Teknologjitë e virtualizimit përdoren tani në shumë fusha të IT-së, si në mjedisin e prodhimit ashtu edhe nga të apasionuarit dhe përdoruesit e shtëpisë për një sërë detyrash. Disa sisteme virtuale që funksionojnë njëkohësisht në të njëjtën makinë fizike rrisin ndjeshëm fleksibilitetin e infrastrukturës së TI-së dhe rrisin efikasitetin e përdorimit të burimeve harduerike. Testimi i softuerit është një nga rastet më të zakonshme të përdorimit për platformat e virtualizimit. Nuk është për t'u habitur që makinat virtuale kanë shumë veti të dobishme që reduktojnë ndjeshëm kohën e zhvillimit dhe testimit dhe përmirësojnë efikasitetin e këtyre proceseve.

Në modelin klasik të zhvillimit të softuerit, programuesit dhe inxhinierët e cilësisë së softuerit në shumicën e kohës duhej të testonin një produkt softuer në një platformë pothuajse gjatë gjithë kohës së zhvillimit, dhe vetëm në fund ta testonin atë në OS dhe mjedise të ndryshme përdoruesi (kështu- i quajtur testimi i konfigurimit, Testimi i konfigurimeve). Për më tepër, nuk kishte aq shumë kompjuterë fizikë në dispozicion të punonjësve dhe zhvilluesve të departamentit të testimit, dhe në një makinë, në një sistem operativ, është e pamundur, për shembull, të instalohen njëkohësisht disa versione të një produkti softuer me të cilin programi i zhvilluar duhet të ndërveprojë. Si rezultat, në softuer, veçanërisht në ekipet e vogla të zhvillimit, shpesh haseshin gabime në lidhje me veçoritë e konfigurimeve të përdoruesve, pasi nuk kishte kohë dhe burime të mjaftueshme për testimin e plotë të konfigurimit. Për më tepër, inxhinierëve cilësorë iu desh të shpenzonin shumë kohë duke vendosur një grup produktesh softuerësh në bankat e testimit dhe duke vendosur punën e tyre në një infrastrukturë rrjeti.

Pa dyshim, një nga problemet më serioze në zhvillimin e softuerit është fakti se në fazat e hershme të zhvillimit, montimet e një produkti softuer gjatë punës së tyre mund të shkaktojnë dëme të pariparueshme në sistem (për shembull, drejtues të ndryshëm pajisjesh). Prandaj, duhet të planifikoni rikuperimin e sistemeve operative dhe cilësimet e tyre pas dështimeve nga kopjet rezervë dhe të shpenzoni një kohë të konsiderueshme për t'i rivendosur ato.

Duhet theksuar edhe një problem që është mjaft i zakonshëm në zhvillimin e softuerit dhe ju bën të shpenzoni shumë kohë për zgjidhjen e tij. Të gjithë programuesit që kanë përvojë në bashkëveprim me ekipet e testimit janë të vetëdijshëm për situatën e mëposhtme: në sistemin e gjurmimit të gabimeve, testuesi rregullon një defekt që programuesi nuk mund ta përsërisë. Pasi programuesi vendos statusin e problemit si të zgjidhur, testuesi e thërret atë në kompjuterin e tij dhe demonstron grafikisht gabimin. Në këtë situatë, vjen deri në pikën që programuesi duhet të instalojë shumë debugger dhe marrëzi të tjera të panevojshme në makinën e testuesit dhe të "kapë" defektin, duke e ndaluar plotësisht punën e testuesit. Nëse kësaj i shtoni kohën që testuesi të heqë shërbimet e programimit, do të keni një humbje serioze të kohës së ekipit.

Për më tepër, veçoritë e funksionimit të disa produkteve softuerike kërkojnë kontrollimin e funksionimit të tyre në kushte të caktuara (sasi e ndryshme RAM, gjerësia e brezit të kanalit të komunikimit, frekuenca e procesorit, etj.). Në këtë rast, ekipi i testimit mund të mos ketë në dispozicion konfigurimin e kërkuar të harduerit (po sikur të na duhen dhjetë disqe?). Kur përcaktohen kërkesat e sistemit të një produkti për faktorë të tillë, kjo nevojë mund të jetë kritike.

Në fund të listës së problemeve që lindin në procesin e zhvillimit dhe testimit, është e nevojshme të jepet një tjetër. Shpesh ekziston një situatë e tillë kur kërkohet të kontrollohet montimi i një produkti softuer "për tym" (i ashtuquajturi testimi i tymit, Testimi i tymit), që nënkupton një ekzekutim të shpejtë të testeve më të rëndësishme. Po sikur të zhvillojmë një aplikacion që kërkon versione të ndryshme të Internet Explorer? Në këtë rast, do të duhet shumë kohë për të nisur një sistem të përshtatshëm ku është instaluar versioni i kërkuar.

Duke përmbledhur situatat e përshkruara, le të përgjithësojmë problemet që hasen shpesh në procesin e zhvillimit dhe testimit të produkteve softuerike:

• nevoja për të testuar softuerin në më shumë konfigurime të përdoruesve sesa është në dispozicion për testimin e kompjuterëve fizikë
• vendosja dhe konfigurimi që kërkon shumë kohë të stolave ​​të testimit që përmbajnë shumë komponentë të ndryshëm, ndërmjet të cilëve sigurohet ndërveprimi i rrjetit
• kosto të mëdha kohore për krijimin e kopjeve rezervë të sistemeve dhe konfigurimeve të tyre, si dhe rikuperimin nga një dështim për shkak të funksionimit të paqëndrueshëm të asambleve të produktit softuer
• pamundësia për të riprodhuar defektin e gjetur nga testuesi në makinën e zhvilluesit dhe humbur kohë duke e kërkuar atë, duke e rregulluar atë
• nevoja për të testuar programin në një mjedis harduerik që nuk është i disponueshëm për ekipin e testimit
• nevoja për të testuar një produkt softuer në kushte që kërkojnë kalim të shpejtë midis konfigurimeve të përdoruesit

Nëse llogaritni se sa kohë dhe burime harxhohen për zgjidhjen e këtyre problemeve, do të merrni një shifër shumë, shumë mbresëlënëse, e cila, e shprehur në terma monetarë, përbën një pjesë mjaft të madhe të buxhetit të projektit.

Teknologjitë e virtualizimit, të aplikuara saktë në procesin e zhvillimit dhe testimit, mund të zvogëlojnë ndjeshëm kostot e punës dhe të rrisin ndjeshëm efikasitetin e procesit, gjë që do të ketë një efekt pozitiv në cilësinë e produktit softuer të lëshuar. Kjo është mënyra se si virtualizimi ju lejon ta bëni këtë:

• testuesit në procesin e punës me makinat virtuale mund të krijojnë një numër të pakufizuar konfigurimesh përdoruesi në makinën e tyre fizike, duke nisur, nëse është e nevojshme, më të përshtatshmet për momentin
• Pasi të krijohen, konfigurimet e shumë makinave mund të konfigurohen duke përdorur mjetet e platformës së virtualizimit dhe thjesht të migrohen në pajisje të tjera, pa pasur nevojë për t'i rikonfiguruar ato
• një kopje rezervë e makinës virtuale mund të krijohet duke kopjuar një dosje ose duke krijuar një fotografi ("snapshot")
• pasi testuesi të gjejë një gabim, një makinë virtuale me një defekt të përsëritur mund të transferohet te zhvilluesi, duke liruar kështu burimet për testim të mëtejshëm
• kushtet e nevojshme për testim mund të krijohen shpejt për shkak të rregullimit fleksibël të parametrave të mjedisit harduerik të makinës virtuale (sasia e RAM-it, numri i procesorëve virtualë, kufizimi i burimeve)
• aftësia për t'u kthyer shpejt në gjendjen e ruajtur të një makinerie virtuale me konfigurimin e nevojshëm ose për të kaluar midis disa sistemeve të vizitorëve që funksionojnë njëkohësisht, zvogëlon kohën e testimit

Të gjitha zgjidhjet e mësipërme duhet të merren parasysh në dritën e faktit se një makinë virtuale me softuer të instaluar në të është një objekt shumë fleksibël që mund të vendoset shpejt në makinat e klientit nga një depo e centralizuar e shablloneve të konfigurimit të përdoruesve, ose mund të konfigurohet si në mënyrë sa më fleksibël në lidhje me parametrat e mysafirëve.sistemi dhe mjedisi i tij. Transportueshmëria e lehtë ndaj pajisjeve të tjera dhe pavarësia e platformës së harduerit janë avantazhet kryesore të makinave virtuale.

Mjete të makinerisë virtuale për testim dhe zhvillim

Gjatë zbatimit të një infrastrukture virtuale për zhvillimin dhe testimin e softuerit, është e nevojshme, para së gjithash, të zgjidhni platformën më të përshtatshme, të besueshme dhe efikase të virtualizimit që plotëson të gjitha kërkesat për procesin e zhvillimit në organizatë. Ekzistojnë dy mënyra më të zakonshme për të përdorur makina virtuale për të testuar produktet softuerike:

• Shpërndarja e pakontrolluar e makinave virtuale në makinat e klientit ose serverët e testimit, në të cilat ose vetë testuesit krijojnë konfigurimet që u nevojiten, ose kopjojnë shabllonet e sistemit virtual në kompjuterët e tyre nga një bibliotekë qendrore e shablloneve virtualë (server skedari). Avantazhi i kësaj qasjeje është kostoja e ulët e zgjidhjes; ju mund të përdorni një nga shumë sistemet e virtualizimit falas (VMware Server, Virtual PC, VirtualBox dhe të tjerë). Disavantazhet kryesore janë se vendosja spontane e makinave virtuale gjeneron konflikte në infrastrukturën e rrjetit, mungesë kontrolli mbi përdorimin e licencave për sistemet operative dhe softuerët aplikativë dhe pamundësia për t'u integruar në mjedisin ekzistues IT të organizatës.
• Vendosja e menaxhuar e sistemeve virtuale nga bibliotekat e centralizuara të modeleve virtuale, me kontroll të plotë mbi përdorimin e makinave virtuale brenda infrastrukturës së IT të kompanisë. Përparësitë e kësaj qasjeje përfshijnë aftësinë për të zgjidhur konfliktet midis sistemeve virtuale dhe fizike në rrjet, kontrollin e përdorimit të licencave, aftësinë për të monitoruar përdorimin e infrastrukturës virtuale dhe krijimin e një hapësire të përbashkët midis pjesëmarrësve të ndryshëm në procesin e zhvillimit dhe testimit, integrimi në infrastrukturën reale të TI-së të ndërmarrjes. Disavantazhi kryesor i kësaj qasjeje është kostoja e lartë e zgjidhjeve. Shembuj të produkteve që ofrojnë vendosje të menaxhuar të makinës virtuale: VMware LabManager, VMLogix LabManager, Menaxheri i makinës virtuale të qendrës së sistemit të Microsoft.

Platformat e virtualizimit, nga të cilat ka një numër të madh sot në treg, po zhvillohen me ritme të shpejta dhe u ofrojnë përdoruesve një grup në rritje mjetesh për të përmirësuar efikasitetin e procesit të zhvillimit dhe testimit. Për të zgjidhur secilin nga problemet e listuara, platformat e virtualizimit nga shitës të ndryshëm kanë mjetet e tyre që lejojnë përdoruesit të testojnë në mënyrë efektive produktet softuerike në makinat virtuale.

1. Krijimi i shumë konfigurimeve të personalizuara.

   Nëse ka një sasi të madhe të hapësirës së lirë në disk në makinën e testuesit, duke përdorur platformën e virtualizimit, mund të krijoni një numër të pakufizuar sistemesh virtuale, secila prej të cilave mund të ngarkohet sipas kërkesës, pa ndalur punën e punonjësit në sistemin pritës. Makinat virtuale mund të përdoren gjithashtu në serverë testimi të dedikuar të bazuar në platformat VMware ESX Server, XenEnterprise ose Virtual Iron. Në këtë rast, disa të drejta mund t'u caktohen përdoruesve të sistemeve virtuale, si dhe burimet fizike të serverit që mund të përdoren nga një përdorues specifik janë të kufizuara. Serveri i skedarëve me shabllone virtuale mund të ruajë makina virtuale të parainstaluara që janë vendosur për të testuar serverët ose stacionet e punës. Në këtë rast, duhet të merrni parasysh veçoritë e përdorimit të makinave virtuale në përputhje me licencën. Në shumicën e rasteve, çdo makinë virtuale kërkon një licencë të veçantë, por ka përjashtime: për shembull, një licencë Windows Server 2003 Datacenter Edition ju lejon të ekzekutoni një numër të pakufizuar shembujsh të OS virtual.

   Nëse mjedisi i konfiguruar i testimit është vendosur tashmë në një makinë fizike, ai mund të migrohet në një virtual duke përdorur produkte nga shitësit e platformave të virtualizimit dhe zhvilluesit e palëve të treta. Këto zgjidhje përfshijnë PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.

2. Krijimi i konfigurimeve me shumë makina në një server fizik.

   Platformat e virtualizimit të fokusuara në testimin e softuerit (VMware Workstation, Virtual PC, VirtualBox, Xen) ju lejojnë të krijoni infrastruktura të tëra virtuale me lloje të ndryshme rrjetesh brenda një hosti të vetëm fizik. Për shembull, mund të krijoni disa "blloqe" të serverëve virtualë (serveri i bazës së të dhënave, serveri i aplikacionit, mjedisi i klientit), të konfiguroni përshtatësit e rrjetit të makinave virtuale (një makinë mund të ketë disa prej tyre, në VMware Workstation - deri në dhjetë), dhe ekzekutoni grupin e testuar të serverëve ... Në të njëjtën kohë, platformat e virtualizimit ju lejojnë të lidhni adaptorët e rrjetit të makinave virtuale me segmente të ndryshme të rrjetit virtual.
   

   Pasi të krijohet infrastruktura virtuale testuese, mund të konfiguroni parametrat e kanaleve të komunikimit ndërmjet makinave virtuale.
   

   Duhet të theksohet se rrjetet virtuale nuk janë të lëvizshme në të gjitha platformat e virtualizimit dhe ndonjëherë ato duhet të rikonfigurohen kur lëvizni makinat virtuale në pajisje të tjera.

3. Rezervimi i makinave virtuale gjatë testimit.

   Nëse testuesit përdorin makina virtuale në stacionet e tyre të punës, ata mund t'i rezervojnë ato duke kopjuar dosjen e skedarit të makinës virtuale. Në rast të një përplasjeje të sistemit, kopja e ruajtur nuk ka nevojë të rikthehet - ajo tashmë është plotësisht funksionale. Përveç kësaj, shumë platforma virtualizimi ju lejojnë të krijoni fotografi të shumta të një makinerie virtuale, secila prej të cilave mund të kthehet në pak minuta.

   Nëse testimi kryhet në serverë të dedikuar testimi, zgjidhjet e specializuara nga shitësit e platformës virtuale si vRanger Pro i Vizioncore, VMware Consolidated Backup (VCB) ose Microsoft Data Protection Manager për Virtual Server 2005 mund të përdoren për të krijuar kopje rezervë të makinës virtuale. R2, të cilat ju lejojnë të bëni kopje rezervë të makinave virtuale pa i ndaluar ato.

4. Demonstrimi i defekteve tek zhvilluesit.

   Nëse zbulohet një defekt, testuesi thjesht mund të ruajë gjendjen e sistemit në të cilin gabimi shfaqet në një fotografi dhe të vazhdojë testimin e sistemit. Nëse është e nevojshme të demonstrohet një defekt, makina virtuale mund të transferohet te një zhvillues i cili mund të punojë me të pa frikë se do të dëmtojë mjedisin e testuesit. Përveç kësaj, në platformën VMware Workstation, makinat virtuale mund të veprojnë si serverë VNC pa pasur nevojë të instalojnë softuer shtesë për desktopin në distancë.
   

5. Konfigurim fleksibël i mjedisit të harduerit.

   Testimi i softuerit shpesh kërkon shumë fleksibilitet në konfigurimin e komponentëve të harduerit. Për shembull, gjatë testimit të stresit (Stress Testing), kërkohet të kontrollohet funksionimi i një produkti softuer në kushte ekstreme ose të kufizuara (mungesa e hapësirës në disk, ndërprerja e lidhjes në rrjet). Në këtë rast, duke përdorur platformën e virtualizimit, makina virtuale mund të shtojë pajisje të reja virtuale ose të kufizojë burimet e alokuara për të.

   Për më tepër, nëse shtojmë një disk virtual në sistemin guest, mund ta krijojmë atë si të zgjerueshëm dinamikisht, gjë që na lejon të kursejmë hapësirë ​​të lirë në disk, si dhe të krijojmë të ashtuquajturat disqe Undo, ndryshimet e të cilave vlejnë vetëm gjatë punës me makina virtuale dhe në fund të seancës mund të anulohet, gjë që është shumë e përshtatshme për testim.
   

   Për sa i përket kontrollit të burimeve, shumë platforma virtualizimi ju lejojnë të kufizoni burimet e një makine virtuale ose një grup burimesh të makinave virtuale, gjë që ju lejon të simuloni mjediset e përdoruesve në botën reale.

   Platformat moderne të virtualizimit mbështesin standardin USB 2.0, një numër të madh të përshtatësve të rrjetit virtual në një makinë virtuale, emulimin e disqeve SCSI dhe përfaqësimin e një numri të ndryshëm procesorësh në një sistem mysafir përmes SMP virtual (Symmetric Multi Processing).

6. Puna me disa sisteme virtuale në të njëjtën kohë.

   Kjo veçori i lejon testuesit jo vetëm të përdorin shembuj të sistemeve të ndryshme të ftuar gjatë testimit, por gjithashtu të kryejnë shkëmbim të thjeshtë skedarësh si midis hostit dhe OS mysafir, ashtu edhe midis sistemit operativ të ftuar duke përdorur mekanizmin Drag & Drop. Në të njëjtën kohë, disa platforma virtualizimi lejojnë shkëmbimin e thjeshtë të skedarëve ose përmes dosjeve të përbashkëta të sistemit pritës (Shared Folders), ose "drag and drop" skedarët midis sistemeve të ftuar (VMware Workstation).

   Shumë platforma virtualizimi lejojnë përdorimin e një clipboard të përbashkët me sistemin pritës, i cili thjeshton shumë, veçanërisht, kopjimin e mesazheve të gabimit të programit në sistemin e gjurmimit të gabimeve.

Mjetet e zhvillimit dhe testimit për vendosjet e pamenaxhuara

Baza për vendosjen e menaxhuar të makinave virtuale janë zgjidhjet e specializuara për krijimin dhe mirëmbajtjen e laboratorëve virtualë testues (Virtual Labs), brenda të cilave kontrolli mbi përdorimin e sistemeve virtuale nga grupe të ndryshme përdoruesish, vendosja e automatizuar e makinave virtuale në kompjuterët e pjesëmarrësve të projektit, dhe kryhen krijimin e një mjedisi të përbashkët pune. Këto zgjidhje janë mjaft të shtrenjta (për shembull, infrastruktura VMware LabManager do të kushtojë të paktën 15,000 dollarë), por ato shpërblehen në një shkallë të gjerë përdorimi. Kompanitë e mëdha si Dell përdorin makina virtuale shumë gjerësisht brenda laboratorëve virtualë për të testuar produktet softuerike. Këto sisteme përdorin SAN, ku shabllonet e makinave virtuale qëndrojnë në një bibliotekë të përbashkët shabllonesh virtuale që vendosen sipas kërkesës për të liruar serverët e testimit të bazuar në platformat e virtualizimit. Përdorimi i laboratorëve virtualë ofron përfitimet e mëposhtme:

• Puna me konfigurime me shumë makineri si një modul i vetëm, aftësia për të publikuar këto module
• Koha e reduktuar e shpenzuar për konfigurimin e sistemeve
• Diferencimi i aksesit në makinat virtuale dhe demonstrimi i defekteve duke transferuar lidhje në situatën e problemit, i ruajtur si një pamje e gjendjes së sistemit të mysafirëve
• Biblioteka e përbashkët e shablloneve me aftësinë për të zgjidhur konfliktet e rrjetit gjatë vendosjes (SID, caktimi i adresave unike MAC në ndërfaqet e rrjetit virtual)
• Mirëmbajtja e centralizuar dhe vendosja e përditësimeve në mjediset e testimit
• Testoni monitorimin e ngarkesës së serverit

Aktualisht, zgjidhjet më të njohura për vendosjen e infrastrukturës së testimit virtual të menaxhuar janë VMware LabManager (për platformën ESX Server) dhe VMLogix LabManager (për platformat Microsoft, VMware dhe XenSource).

VMware LabManager Test Labs

VMware u ofron kompanive të mëdha të përdorin një infrastrukturë testimi virtual të bazuar në një zgjidhje (të zhvilluar më parë nga kompania e blerë Akimbi), e cila ju lejon të vendosni shpejt makina virtuale në serverët e testimit dhe të kontrolloni përdorimin e sistemeve virtuale, ndërsa procesi duket si përdoruesi punon me një kompjuter fizik. Modeli i laboratorit virtual është paraqitur më poshtë:

Përveç të gjitha avantazheve të listuara të sistemeve të menaxhimit të laboratorit virtual, VMware LabManager ofron integrim me mjetet e njohura të testimit dhe ka aftësinë të vendosë shabllone me disa klikime të miut, mbështet protokollin LDAP, integrohet lehtësisht me zgjidhjet e tjera për infrastrukturën virtuale VMware dhe ka aftësia për të automatizuar operacionet përmes API-së së vet (Application Program Interface). Pengesa kryesore e këtij produkti është aftësia për të shërbyer serverë virtualë vetëm në platformat VMware.

VMLogix LabManager Test Labs

Ndryshe nga zgjidhja nga VMware, produkti mbështet platformat e virtualizimit nga shitës të ndryshëm. Platformat Microsoft (Serveri Virtual), Xen (XenEnterprise) dhe VMware (Serveri dhe Serveri ESX) mund të përdoren si bazë për një laborator testimi virtual. Përveç kësaj, VMLogix LabManager mbështet mirëmbajtjen e serverëve fizikë të një organizate. Arkitektura e zgjidhjes VMLogix LabManager është paraqitur më poshtë:

LabManager u ofron përdoruesve një portal vetëshërbimi që u mundëson përdoruesve të vendosin makina virtuale nga një bibliotekë e centralizuar shabllonesh dhe ISO të sistemit operativ, menaxhimin e licencave, zonat e caktimit të adresave IP dhe aftësitë e auditimit të sigurisë së infrastrukturës virtuale të testimit. Përveç kësaj, VMLogix LabManager ka gjithashtu API për automatizimin e operacioneve, aftësinë për të vendosur dhe mirëmbajtur konfigurimin e shumë makinave dhe veçori për të demonstruar situata problemore duke ndarë fotografitë e makinës virtuale.

konkluzioni

Modeli për organizimin e procesit të zhvillimit dhe testimit duke përdorur makina virtuale mund të zvogëlojë ndjeshëm koston e vendosjes së mjediseve të përdoruesve testues dhe konfigurimit të mjediseve të testimit. Sipas statistikave, gjatë testimit të produkteve softuerike në serverë fizikë dhe stacione pune, këto detyra marrin deri në 50 për qind të kohës së ekipit të testimit. Makinat virtuale në platformat e shitësve të ndryshëm mund ta zvogëlojnë këtë kohë disa herë, deri në 5% të kostove totale të testimit. Fleksibiliteti i shtuar i sistemeve virtuale dhe pavarësia e tyre nga hardueri bën të mundur punën me to si me blloqe të caktuara nga të cilat është ndërtuar infrastruktura e testimit virtual të kompanisë. Aftësia për të ofruar akses të përgjithshëm në defektet e gjetura për anëtarët e ekipit të zhvillimit dhe përdoruesit e produktit mund të përshpejtojë ndjeshëm kërkimin dhe korrigjimin e gabimeve. Në shumë kompani, testimi me makina virtuale është bërë tashmë standardi de facto.

Megjithatë, procesi i testimit në sistemet virtuale ka disa kufizime: për shembull, sistemet virtuale nuk rekomandohen për testimin e performancës, si dhe testimin e aplikacioneve që vendosin kërkesa të larta për burimet fizike të një kompjuteri. Për llojet e tjera të testimit, infrastruktura e testimit virtual është një nga zgjidhjet më të mira për përmirësimin e efikasitetit të procesit të zhvillimit si dhe thjeshtimin e ndërveprimit midis anëtarëve të ekipit.

Platformat e harduerit

Përputhshmëria e platformës së harduerit do të thotë që kompjuterët përbëhen nga njësi dhe pajisje që kanë të njëjtin sistem komandimi dhe kodim të të dhënave, dhe për këtë arsye mund të jenë të këmbyeshëm. Edhe pse kjo nuk është e nevojshme - nëse pajisjet ndryshojnë shumë në karakteristikat teknike, atëherë njëra nuk mund të zëvendësohet me një tjetër. Por për platforma të ndryshme harduerike, të gjithë komponentët janë krejtësisht të ndryshëm dhe të papajtueshëm.

Tani kanë mbetur vetëm dy platforma konkurruese harduerike për PC: IBM PC dhe Apple Macintosh(Figura 3) Për më tepër, IBMPC dominon qartë, mbi 90% e kompjuterëve i përkasin kësaj platforme. Në një kohë Apple Macintosh ishte më i përshtatshëm për grafikë dhe botim, por tani aftësitë e të dy platformave janë të barabarta. Megjithatë,

Kompjuterët Apple nuk po zhduken, ata ende po përdoren.
Për serverët me performancë të lartë, ose anasjelltas - çipa primitivë, ekzistojnë platforma të tjera harduerike: SunMicrosystems, Compaq, HewlettPackard, etj.

Një rol të rëndësishëm në konfigurimin e harduerit të një kompjuteri luhet nga Parimi i arkitekturës së hapur... Ky është ndërtimi i një kompjuteri në baza modulare, kur të gjitha pajisjet kompjuterike të të njëjtit lloj kanë:

1. Protokollet (standardet) e transmetimit të të dhënave të miratuara reciprokisht;

2. dimensionet standarde gjeometrike dhe lidhësit e unifikuar për lidhje.

Arkitektura e hapur lejon Përmirëso(Përmirëso), d.m.th. përmirësimin e kompjuterit tuaj thjesht duke zëvendësuar disa pajisje me të tjera, pa ndikuar gjithçka tjetër.

Në vend të një pajisjeje të vjetëruar, instalohet një e re me parametra më të mirë dhe lidhet me të njëjtin lidhës. Sistemi operativ regjistron pajisjen e re dhe përcakton drejtuesit më të mirë për të. Nëse nuk janë brenda sistemit operativ, atëherë drejtuesit e nevojshëm merren nga media e jashtme ose nga Interneti. Pas kësaj, kompjuteri fillon të punojë me parametra disa herë më të mirë. Procedurë e thjeshtë dhe efektive.

Zëvendësimi i disa pajisjeve harduerike për të tjera me karakteristika më të mira kryhet në një masë të caktuar në çdo pajisje teknike, por askund nuk arrin përmasa të tilla si në teknologjinë kompjuterike. Për shembull, është e vështirë të imagjinohet një makinë në të cilën pjesët e reja të motorit dhe transmisionit zëvendësohen me ato të vjetruara, si rezultat i së cilës fuqia e makinës rritet disa herë.

Përmirësimet kanë kufijtë e tyre dhe nuk mund të vendosni të gjitha të fundit në një kompjuter shumë të vjetër. Herë pas here, shfaqen standarde thelbësisht të reja të lidhjes, autobusët e sistemit të vjetër nuk prodhohen më, standardet e pajisjeve bazë, të tilla si, për shembull, një motherboard, ndryshojnë. Dhe pastaj azhurnimi bëhet i pakuptimtë, është më e lehtë të blini një kompjuter të ri.

Platforma IBMPC është arkitekturë e hapur, ndërsa Apple është e mbyllur.

Arkitektura e hapur është pikërisht ajo që i lejoi platformës IBM në një kohë të merrte një pozicion udhëheqës në prodhimin e kompjuterëve dhe të mposhtte konkurrencën. Dhe tani kompjuterët në platformën IBM janë dominues në botë.

Sidoqoftë, vetë IBM, pasi prezantoi një arkitekturë të hapur të produkteve të saj, zgjidhi me sukses problemet taktike, por humbi strategjikisht. Qindra kompani në të gjithë botën - në Amerikë, Evropë, Azi - filluan të prodhojnë pajisje me arkitekturë të hapur për kompjuterët IBM. Nuk ka asnjë ndalim ligjor për këtë. Dhe arkitektura e autobusit teknikisht e hapur e bën mjaft të lehtë për ta bërë këtë.

Si rezultat, IBM pushoi së qeni lideri i vetëm në prodhimin e teknologjisë kompjuterike. Ajo është bërë vetëm një nga korporatat më të mëdha në pesë prodhuesit kryesorë.

Hyrje Pasi të keni zbuluar mundësitë në 3DMAX të kartave grafike moderne, është koha për të kryer të njëjtat teste për të krahasuar platformat moderne të harduerit me një procesor.
Për momentin, ekzistojnë vetëm dy familje të procesorëve në tregun masiv që mund të konsiderohen "premtues" - platformat Socket478 dhe Socket462 (SocketA). Unë nuk do t'i konsideroj platformat "të vjetruara" të bazuara në procesorë për Socket370 dhe Socket423, pasi nuk ka kuptim të blini sisteme me një procesor të bazuar në këta procesorë për të punuar në 3DMAX.
Sigurisht, sistemet e blera tashmë të bazuara në të dy procesorët Socket370 bazuar në bërthamën Tualatin dhe cache 512 Kb L2, si dhe sistemet e bazuara në procesorët më të vjetër Socket423 ju lejojnë të punoni me efikasitet në 3DMAX. Sidoqoftë, kostoja e këtyre sistemeve "të vjetruara" sot i bën ato joprofitabile, pasi sistemet e bazuara në këta procesorë nuk kanë asnjë avantazh të performancës ose madje janë inferiorë ndaj sistemeve të bazuara në procesorët Socket478 dhe Socket462 me të njëjtin çmim. Kjo është pasojë e politikës së Intel për të zëvendësuar linjat e procesorëve "të vjetëruara" me ato të reja "premtuese", gjë që manifestohet në një përditësim më të shpejtë të linjave të procesorëve "premtues" dhe, rrjedhimisht, një ulje më të shpejtë të çmimeve për procesorët në këto "premtuese" linjat.
Çipet më produktive për procesorët Socket478 dhe Socket462, pllakat amë në të cilat janë gjerësisht të disponueshme sot, janë i850 dhe Apollo KT266A. Nuk ka kuptim të ndërtosh platforma në pllaka amë me chipset i845D që mbështet PC2100 DDR SDRAM sot, pasi PC800 RDRAM aktualisht kushton njësoj ose edhe më lirë se PC2100 DDR SDRAM, ndërkohë që ofron performancë dukshëm më të lartë.

Pra, në këtë artikull do të shqyrtojmë performancën e një sistemi të bazuar në një motherboard me një chipset i850 (Abit TH7II) dhe procesorë Pentium4 - 2.2 GHz, 2.0 GHz me një cache 512 Kb L2 (core Northwood) dhe procesorë Pentium4 - 2.0 GHz, 1,7 GHz me një nivel memorie L2 256 Kb (bërthama Willamette). Para së gjithash, me interes është rritja e performancës, e cila mund të merret duke dyfishuar cache-in L2. Do të shohim gjithashtu se sa procesorët Pentium4 janë të shkallëzuar, d.m.th. Nëse rritja e shpejtësisë së orës siguron një fitim të krahasueshëm të performancës.
Për krahasim me këtë sistem, zgjodha një platformë të përbërë nga një motherboard i bazuar në chipset Apollo KT266A (Epox 8KHA +) dhe një procesor AthlonXP 2000+ (frekuenca reale e orës - 1667Mhz). Mora vetëm një procesor për Socket462 për faktin se AMD mbeti shumë prapa Intel në procesin e rritjes së frekuencave të orës së procesorëve të saj, dhe frekuenca e orës së këtij procesori "më të lartë" është edhe më e ulët se shpejtësia e orës së Pentium4 të ri. procesor, i konsideruar në këtë material.

Përshkrimi i konfigurimeve të harduerit

Për të vlerësuar treguesit e shpejtësisë, përdora të njëjtat teste si në rishikimet e mëparshme. Më lejoni t'ju kujtoj se këto standarde rekomandohen për testim në 3D Studio MAX nga vetë prodhuesi i softuerit.
Duke filluar me këtë artikull, unë refuzova të testoja me aktivizimin e anti-aliasing të linjës, pasi të gjitha kartat moderne video kryejnë anti-aliasing të linjës pa humbje të performancës.

Platforma # 1:

Procesori - Pentium 4 2.2GHz (512Kb L2), Pentium 4 2.0A GHz (512Kb L2), Pentium 4 2.0GHz (256Kb L2), Pentium 4 1.7GHz (256Kb L2).
Motherboard - Abit TH7II (i850)
Kujtesa - 1024 Mb PC800 RDRAM

Platforma # 2:

Procesori - AthlonXP 2000+ (1667 Mhz)
Motherboard - Epox 8KHA + (Apollo KT266A)
Kujtesa - 1024 Mb PC2100 SDRAM
Karta video - NVIDIA GeForce4 Ti4600 (versioni Detonator 27.51)
Hard Disk - 20 Gb IBM DTLA 7200 rpm

Softueri:

Windows 2000 SP2
3ds max 4,26 (përkthim OpenGL), 1280x1024 32 bit

Testimi i karakteristikave të shpejtësisë kur punoni në dritaret e projektimit

1 ... Standardi i parë është një "test stresi" - animacioni i skenës luhet në katër dritare. Sidoqoftë, metoda e paraqitjes është e ndryshme. Në dy dritaret e sipërme, skena paraqitet në formën e "Wireframe" (d.m.th., në modalitetin "wireframe" ose "wireframe"), në pjesën e poshtme të majtë "Smooth + Highlights" + "Edged Faces" (në modalitetin e hijes). me skajet e zgjedhura), në pjesën e poshtme djathtas poshtë - "Smooth + Highlights":

Kjo skenë përmban shumë pak poligone - vetëm 28 mijë, megjithatë, për shkak të riprodhimit të njëkohshëm të animacionit në të katër dritaret, "totali" fps është shumë i vogël.

Shumëkëndëshat: 28868
Burimet e dritës: 1
Modaliteti: Kornizë teli, Smooth + Pikat kryesore

Kur animacioni shfaqet njëkohësisht në të katër dritaret e projeksionit, pjesa më e madhe e ngarkesës së interpretimit të skenës bie në lidhjen e procesorit qendror - kujtesës. Siç mund ta shohim, në këtë pikë referimi, procesori AMD "po ecën mirë", duke konfirmuar vlerësimin e tij. Fitimi nga rritja e cache L2 në procesorët Intel është shumë i vogël dhe arrin në rreth 5%

2 ... Standardi i dytë është një skenë me shtatë objekte gjeometrike bazë, me një kompleksitet total prej dhjetë mijë poligonesh.

Gjashtë objekte janë statike, njëri lëviz ngadalë nëpër skenë, duke “kaluar” nëpër objekte të tjera. Ky pikë referimi kontrollon korrektësinë e shfaqjes së "kryqëzimit" të objekteve dhe shpejtësinë me të cilën shoferi dhe pajisja e kartës video do të përballen me këtë.

Shumëkëndëshat: 9712
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Ndryshe nga ai i mëparshmi, ky pikë referimi, në këtë rast, ngarkon autobusin AGP dhe tregon shpejtësinë e portit AGP të motherboard. Në rast të zbatimit të gabuar të AGP, vlera e fps bie në këtë pikë referimi në rreth 80-100.
Kështu, ne shohim se zbatimi AGP është i mirë për të dy platformat. Sidoqoftë, në këtë pikë referimi, rritja e cache-it jep një fitim shumë më të madh sesa në atë të mëparshëm - deri në 20%.

3 ... Skena e standardit të tretë përmban një top që lëviz shumë ngadalë në një sfond prej 15,000 poligonesh të gjeometrisë.

Topi nuk kryqëzon objekte të tjera askund. Meqenëse topi lëviz shumë ngadalë, drejtuesi "korrekt" do të bëjë shumë pak ndryshime në çdo kornizë. Me fjalë të tjera, ky pikë referimi teston aftësinë e kartës video për të mos rivizatuar objekte që nuk rifreskohen në çdo kornizë.

Shumëkëndëshat: 15653
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Ky standard është i ngjashëm me atë të mëparshëm, dhe rezultatet e sistemeve janë gjithashtu të ngjashme me ato të treguara në standardin e fundit - AthlonXP 2000+ përsëri demonstron "drejtësinë" e vlerësimit të tij, dhe cache e dyfishuar L2 në Pentium4 ofron një shpejtësi të dukshme rrit.

4 ... Ky pikë referimi tregon aftësinë e kartës video për të trajtuar gjeometrinë shumë komplekse. Ky standard tregon performancën e kartave video në modalitetin Smooth + Highlights në skena me gjeometri komplekse.

Shumëkëndëshat: 200270
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Në këtë pikë referimi gjeometrik, rezultati varet nga fuqia e FPU (pasi ju duhet të llogaritni gjeometrinë komplekse) dhe gjerësinë e brezit të memories (pasi ju duhet të vizatoni sipërfaqet në modalitetin Smooth + Highlight). Athlon ka një avantazh të qartë në të parën, megjithatë, gjerësia e brezit RDRAM është shumë më e lartë, kështu që platforma Socket462 performon më pak se sistemi në Pentium4 2.0 GHz.

5 ... Standardi i pestë teston aftësitë e kartave video për trajtimin e gjeometrisë jashtëzakonisht komplekse. Këtë herë, numri i poligoneve pothuajse u dyfishua dhe arriti në gati 376 mijë. Shtëpitë tani janë duke qëndruar në të njëjtën "sipërfaqe".

Ky pikë referimi është në gjendje të "gjunjëzojë" çdo kartë video - mesatarja e fps nuk i kalon tre korniza. Vetë skedari u krijua, natyrisht, jo me fps = 3, shtëpitë u krijuan veçmas në skedarë të ndryshëm, dhe kur "vendoset në tokë" pjesa e papërdorur e gjeometrisë u "fik" për të përmirësuar performancën.

Shumëkëndëshat: 376875
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Në një standard më të rëndë gjeometrik, situata është e ngjashme me atë të mëparshme, megjithatë, me një rritje të gjeometrisë së përpunuar, ndikimi i memories së cache zvogëlohet dhe ndikimi i FPU rritet.

6 ... Testimi standard i shpejtësisë së përpunimit të burimeve të shumta të dritës. Meqenëse shumica e kartave video nuk mbështesin më shumë se 8 burime, ky test dhe dy të ardhshëm përmbajnë 8 lloje të ndryshme burimesh drite. Në këtë test, 8 SpotLights lëvizin për të ndriçuar një lloj "asteroidi":

Duhet të theksohet se shfaqja e dritave të vëmendjes kërkon shumë më tepër burime sesa shfaqja e dritave Omni dhe Directional.

Shumëkëndëshat: 39600
Burimet e dritës: 8
Modaliteti: I qetë + Pikat kryesore

7 ... I njëjti "asteroid", vetëm tani është ndriçuar nga tetë burime drite Drejtuese. Dritat e drejtimit janë "më të ngadalta" se dritat Omni, por "më të shpejta" se Spotlights.

Shumëkëndëshat: 39600
Burimet e dritës: 8
Modaliteti: I qetë + Pikat kryesore

8 ... Përsëri i njëjti "asteroid" dhe përsëri tetë burime drite. Këto janë tani dritat e tipit Omni, dritat "më të shpejta" në 3DMAX.

Shumëkëndëshat: 39600
Burimet e dritës: 8
Modaliteti: I qetë + Pikat kryesore

Në standardet e ndriçimit, AthlonXP 2000+ performon në mënyrë të krahasueshme me Pentium4 2,0 ​​GHz. Fitimi i performancës nga rritja e memories cache nuk kalon 10%.

9 ... Një skenë me gjeometri "dritë" dhe një burim të vetëm drite, vetëm katër mijë e gjysmë poligone, që zë të gjithë dritaren e projeksionit - ky është një pikë referimi për shpejtësinë e rasterizimit në modalitetin Smoth + Highlights.

Gjatë lëvizjes së kamerës, karta video duhet të rasterizojë poligonet e mëdhenj dhe të vegjël (në lidhje me madhësinë e ekranit)

Shumëkëndëshat: 4684
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Në standardin e rasterizimit, AthlonXP 2000+ tregoi një rezultat të ulët - më të ulët se ai i një Pentium4 me të njëjtën shpejtësi orë (1700 Mhz). Kjo për faktin se në këtë pikë referimi gjithçka varet nga shpejtësia e transferimit të procesorit - memoria e dhënë në autobus.

10 ... Standardi që tregon shpejtësinë e kartave video me tekstura. Skedari përmban shumë tekstura dhe një minimum gjeometrie. Standardi është një top rrotullues me 48 tekstura të mbivendosura në skajet e tij.

Gjeometria minimale dhe teksturat maksimale të kësaj skene tregojnë shpejtësinë maksimale të përpunimit të teksturës nga karta video.

Shumëkëndëshat: 224
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

11 ... Një dhomë me teksturë të plotë me një kamerë që lëviz brenda. Ky pikë referimi është më i afërti me aplikacionet e botës reale, pasi përmban shumë tekstura, gjeometri komplekse dhe disa burime drite. Ky pikë referimi tregon aftësitë e kartave video kur përpunohen skena të vështira në modalitetin Smooth + Highlight.

Shumëkëndëshat: 12413
Burimet e dritës: 8
Modaliteti: I qetë + Pikat kryesore

12 ... "Valët" e animuara me teksturën e aplikuar tregojnë shpejtësinë e përpunimit dhe modifikimit të teksturave.

Shumëkëndëshat: 880
Burimet e dritës: 1
Modaliteti: I qetë + Pikat kryesore

Në tre standardet e teksturës, sistemet duhet të llogarisin teksturat rrotulluese (në standardin e parë të teksturës), të korrigjojnë teksturat fikse me një kamerë rrotulluese (në të dytën) dhe të deformojnë teksturën (në të tretën).
Nuk është e vështirë të merret me mend se në standardin e parë të teksturës, gjerësia e brezit të memories dhe madhësia e memories së memories janë të një rëndësie të madhe - prandaj Athlon "i bie" Pentium4 2.2 GHz.
Korrigjimi i teksturës kryhet nga FPU, kështu që në standardin e dytë Athlon2000 + i afrohet Pentium4 2.2 GHz. Gjithashtu, rritja e memories cache jep një rritje prej 15%.
Deformimi i teksturës llogaritet gjithashtu nga FPU, dhe në këtë pikë referimi AthlonXP 2000+ performon më mirë se Pentium4 2.2 GHz.

13 ... Standardi mat shpejtësinë e punës në modalitetin Wireframe. 111 mijë poligone në modalitetin wireframe do të jenë një provë serioze për çdo kartë video moderne.

Shumëkëndëshat: 111270
Burimet e dritës: 1
Modaliteti: Kornizë teli

Ky standard i teksturës përmban të njëjtën skenë si standardi numër 4, por ndryshe nga standardi i katërt, këtu kjo skenë paraqitet në modalitetin Wireframe. Prandaj, në këtë pikë referimi, gjithçka varet nga fuqia e FPU - Ahtlon tregon një rezultat të krahasueshëm me rezultatet e procesorëve Pentium4 që funksionojnë në 2 GHz, dhe një rritje në memorien e cache në këtë test nuk jep ndonjë rritje të shpejtësisë.

Të gjitha standardet e mësipërme rekomandohen për testimin e kartave video nga prodhuesi 3DMAX, megjithatë, siç e kemi parë, ato testojnë aftësitë e kartave video me funksione të veçanta dhe nuk ka teste "të përgjithshme" midis tyre. Kështu shtova edhe një pikë referimi - kjo është një skenë me tetë drita, 61371 poligone dhe shumë plane transparente. Kompleksiteti i këtij skedari është mjaft tipik sot, i gjithë skedari së bashku me teksturat merr më shumë se 6 Mb. Animacioni është ndërtuar për testimin më të mirë të mundshëm - kamera lëviz nëpër dhomë, duke kapur të gjitha objektet. Ja si duket korniza e parë pas paraqitjes përfundimtare:

E përdora këtë skenë për të testuar kartat grafike si në modalitetin Wireframe ashtu edhe në Smoth + Highlights. Prandaj, kemi marrë dy standarde:

14 ... Skena me kornizë teli

Shumëkëndëshat: 61371
Burimet e dritës: 8
Modaliteti: Kornizë teli

Meqenëse skena në këtë pikë referimi pasqyrohet në modalitetin Wireframe, si në standardin e mëparshëm, madhësia e memories së memories nuk ka një efekt të dukshëm, dhe rezultati i AthlonXP2000 +, falë FPU-së efikase, doli të jetë i barabartë me rezultatin i Pentium4 2.2 GHz, i cili funksionon me 50 % frekuencë dhe ka dyfishin e sasisë së memories cache.

15 ... E njëjta skenë në modalitetin Smooth + Highlight

Shumëkëndëshat: 61371
Burimet e dritës: 8
Modaliteti: I qetë + Ndriçim

Meqenëse skena pasqyrohet në modalitetin Smooth + Highlight, rezultatet e Athlon nuk janë aq të mira sa në standardin e mëparshëm. Sidoqoftë, rezultatet e AthlonXP 2000+ janë të barabarta me rezultatet e Pentium4 2.0 GHz dhe Athlon konfirmon përsëri vlerësimin e tij.
Memorie cache 512 Kb në vend të 256 Kb, në këtë pikë referimi, si në shumicën e standardeve me gjeometri "mesatare" dhe modalitetin Smooth + HighLight, ju lejon të merrni rreth 15% rritje të shpejtësisë.

Testimi i karakteristikave të shpejtësisë gjatë paraqitjes përfundimtare

Kam bërë paraqitjen përfundimtare të tre skenave nga shpërndarja 3ds max4 me të njëjtat parametra, në të njëjtën rezolucion 800x600, pasi përqindja e rezultateve të platformave të testuara është e njëjtë për të gjitha rezolucionet nga 640x480 deri në 1600x1200. Këto skena janë:

Tabela e rezultateve (koha në sekonda: më pak është më mirë):

Shpejtësia e paraqitjes përfundimtare varet kryesisht nga fuqia e FPU-së, kështu që në paraqitjen përfundimtare AthlonXP2000 + performoi vetëm pak më keq se Pentium4 2.2 GHz.

konkluzionet

Për sa i përket tërësisë së rezultateve në të gjitha standardet që testojnë funksionimin në dritaret e projektimit, AthlonXP 2000+ tregon rezultate të krahasueshme me ato të Pentium4 2.0A GHz. Dhe kur punoni në modalitetin Wireframe, AthlonXP2000 +, falë një FPU jashtëzakonisht të fuqishme, demonstron një rezultat afër ose të barabartë me atë të Pentium4 2.2 GHz (pavarësisht se ky i fundit funksionon me + 50% frekuencë të orës dhe ka dyfishin e cache-it) . Prandaj, nëse kaloni pjesën më të madhe të kohës duke punuar në modalitetin Wireframe, atëherë AthlonXP2000 + është zgjidhja më e mirë. Në testet për shpejtësinë e paraqitjes përfundimtare, rezultatet e AthlonXP 2000+ janë gjithashtu afërsisht të barabarta me ato të Pentium4 2.2 GHz. Kështu, me procesorin AthlonXP 2000+ që kushton 250 USD (dhe me koston e Pentium4 2.0AGHz dhe 2.2GHz në 350 dhe 550 USD, respektivisht) dhe motherboard më të lirë për të, platforma Socket462 është aktualisht më e favorshmja në kategorinë e performancës së çmimeve. Sidoqoftë, procesori më i shpejtë për 3DMAX është Pentium4 2.2 GHz.
Dallimi në performancën e procesorëve Pentium4 me një madhësi cache prej 256 Kb dhe 512 Kb në shumicën dërrmuese të testeve që simulojnë punën në dritaret e projektimit dhe llogaritin paraqitjen përfundimtare nuk kalon 5%, kështu që nuk ka kuptim të ndryshoni një procesor me cache 256 Kb në procesorë të rinj me cache 512 Kb. Nga ana tjetër, është gjithashtu e kotë të blini procesorë me një cache më të vogël sot - çmimet për procesorët me cache 265 Kb dhe 512 Kb janë pothuajse të barabarta.