Conform definiției oficiale propuse de OSHWA.org: „Soluțiile hardware deschise sunt soluții al căror design este public și deschis spre studiu, modificare, distribuție, vânzare. Acest lucru se aplică atât soluției în sine, cât și derivatelor și componentelor sale. Datele inițiale ale proiectului și ale componentelor acestuia trebuie prezentate într-un format care să permită modificarea ulterioară a acestora. În mod ideal, hardware-ul deschis utilizează instrumente și materiale ușor disponibile, procese standard, infrastructură deschisă, conținut gratuit și instrumente de dezvoltare open source pentru a oferi utilizatorilor libertate maximă de a le utiliza.”

Este demn de remarcat aici că platformele hardware deschise nu sunt obligate să ofere instrumente de dezvoltare gratuite. „Unelte de dezvoltare” se referă la o gamă largă de instrumente de proiectare și depanare, variind de la instrumente de măsurare (multimetre, osciloscoape) și medii integrate (IDE), până la utilități bazate pe web care oferă management funcțional al proiectelor. Este important de reținut că multe dintre platformele open source binecunoscute, cum ar fi Arduino, LaunchPad, BeagleBone și STM Nucleo, oferă biblioteci de software gratuite, mostre de cod și chiar cadre întregi, cum ar fi Arduino IDE sau mbed.org.

Unele instrumente de dezvoltare sunt ele însele platforme deschise, ceea ce le face foarte accesibile datorită costului lor relativ scăzut. Un exemplu este placa universală de măsurare Red Pitaya care rulează Linux. De fapt, Red Pitaya este un complex de măsurare care înlocuiește echipamentele de laborator care sunt inaccesibile utilizatorilor obișnuiți din cauza prețului ridicat. Red Pitaya oferă serviciului proiectantului 125 de intrări analogice MSPS și 100 de ieșiri KSPS. Acest instrument versatil poate acționa ca o varietate de instrumente standard, cum ar fi: un osciloscop cu o lățime de bandă de aproximativ 50 MHz, un analizor de spectru, un metru de impedanță LCR, un analizor Bode, un teslametru, un generator de funcții cu rezoluție de 14 biți, inclusiv cele potrivite pentru audio etc. Pentru a afișa rezultatele măsurătorilor, Red Pitaya se conectează la o tabletă, PC sau smartphone. Adăugați un modul de extensie a senzorilor și puteți conecta Red Pitaya la plăcile Arduino și la senzorii SEEED Studio Grove pentru a extinde și mai mult funcționalitatea acestui sistem de măsurare.

Orez. 1. Sistemul universal de măsurare Red Pitaya este un exemplu de platformă hardware deschisă și se caracterizează prin disponibilitate maximă. Red Pitaya are funcționalitatea unui osciloscop, analizor de spectru, contor de impedanță, analizor Bode, teslametru, generator de funcții etc.

Placa Red Pitaya a fost introdusă pe platforma de internet Kickstarter în 2013. A devenit o spin-off pentru o companie care dezvoltă instrumente pentru acceleratorii de particule. Astfel, Red Pitaya este un instrument open source de măsurare și control și un software cu suport pentru programare vizuală. Red Pitaya este susținut de Matlab, LabView, Python și Scilab. Cu codul sursă deschis, capacitățile Red Pitaya pot fi extinse cu funcții suplimentare și utilități create de utilizator.

Multe platforme deschise pot fi, de asemenea, transformate în instrumente de dezvoltare. De exemplu, folosind Arduino UNO, puteți crea un analizor logic digital. Cu toate acestea, merită remarcat faptul că aceasta nu este funcția principală a unor astfel de platforme. Practic, majoritatea soluțiilor open source sunt concepute pentru a ajuta la testare, depanare și depanare. În același timp, chiar și cea mai bună placă de depanare este inutilă dacă nu există o documentație completă și detaliată pentru aceasta.

Luați în considerare cele mai comune instrumente utilizate atunci când lucrați cu platforme hardware deschise.

1. Primul instrument de proiectare este poate cel mai important și cel mai puțin „tehnic”. Acesta este un creion obișnuit. Este creionul care vă permite să „întruchipați” instantaneu ideile concepute pe hârtie, să marcați rezultatele testelor și să remediați modificările pentru a restabili în continuare întreaga imagine a proiectului luni sau chiar ani mai târziu.
2. Echipamente. Aceasta include o gamă largă de instrumente, de la instrumente de măsură (multimetre, osciloscoape) până la organizatoare pentru depozitarea componentelor electronice. Din păcate, echipamentul este departe de a fi gratuit, dar dacă sunteți aproape de comunitatea de dezvoltatori, atunci împrumutul unuia sau altui dispozitiv de măsurare nu va fi o problemă. În plus, multe instrumente sunt acum disponibile prin magazinele online și sunt vândute la prețuri foarte mici.
3. Programarea în cod nativ nu este ușoară, astfel încât compilatoarele și interpreții sunt utilizați pentru a crea software încorporat, permițând dezvoltatorilor să scrie programe folosind limbaje de nivel înalt sau chiar să efectueze programare grafică.

Mediile integrate (IDE) sunt un alt instrument pentru dezvoltarea software-ului încorporat. IDE-urile sunt platforme software care combină un editor de cod sursă, un compilator/interpret, un depanator, un instrument de automatizare a construcției și uneori instrumente de testare. Multe medii integrate vă permit să depanați codul și să analizați funcționarea acestuia în dispozitive reale. Există instrumente care ajută la vizualizarea dispozitivului și la rularea simulărilor înainte ca un prototip real să fie asamblat. IDE-urile optimizează și accelerează foarte mult procesul de dezvoltare.

Instrumentele de dezvoltare și editare software sunt de obicei create pentru anumite nuclee de procesor. Pentru majoritatea plăcilor, producătorii specifică ce mediu de dezvoltare să folosească.

Luați în considerare principalele tipuri de IDE utilizate pentru a crea software încorporat:

1. Medii de dezvoltare integrate gratuite (IDE), cum ar fi Arduino IDE, Energia IDE pentru TI LaunchPads, care pot fi descărcate gratuit de pe site-ul producătorului și instalate pe computer.
2. IDE-uri online care nu necesită instalare pe un PC, dar au nevoie de acces la Internet. Avantajele lor sunt că nu necesită actualizări și nu ocupă spațiu pe hard disk. Un exemplu de astfel de programe este Mbed.org.
3. Medii de dezvoltare plătite. După cum am menționat mai sus, compilatoarele vă permit să lucrați cu un anumit tip de nuclee de procesor și, mai exact, cu un anumit set de procesoare / microcontrolere specifice. De exemplu, dacă se utilizează o pereche de procesoare cu un nucleu ARM ® Cortex ® -M4, atunci poate fi o situație în care un procesor este suportat de IDE, iar al doilea nu. Prin urmare, înainte de a cumpăra un IDE, ar trebui să verificați dacă procesorul țintă se află în lista de dispozitive acceptate. Exemple de medii de dezvoltare plătite sunt, de exemplu, Keil de la ARM și IAR Embedded Workbench de la IAR Systems.
4. Probe gratuite ale mediilor plătite cu o limită de timp. Multe IDE-uri, cum ar fi IAR și Keil, au teste gratuite cu o perioadă limitată de încercare gratuită. După încheierea perioadei de probă, programul este blocat și necesită achiziționarea unei licențe.
5. Versiuni gratuite ale mediilor plătite cu funcționalitate limitată. Există versiuni limitate de medii plătite cu funcționalitate redusă. Un exemplu de astfel de mediu este versiunea Keil pentru microcontrolere STM32L0 cu o limită de dimensiune a codului.
6. Medii gratuite și open source, cum ar fi diverse soluții GNU. Un exemplu de mediu liber este Eclipse IDE. Eclipse IDE vă permite să adăugați pluginuri pentru a suporta diferite limbaje de programare, în special C++ sau Python. Este de remarcat faptul că, în majoritatea cazurilor, compilatoarele gratuite sunt inferioare omologilor comerciali în ceea ce privește calitatea optimizării codului. Cu toate acestea, acest decalaj se micșorează în timp.
7. Microcontrolerele provin de la producător într-o formă neprogramată. Pentru „firmware-ul” fizic al programelor, este necesar un dispozitiv special - un programator. Excepție fac microcontrolerele care au un bootloader încorporat (bootloader). Bootloader-ul este un mic program încorporat care vă permite să programați microcontrolere folosind una dintre interfețele populare USB, UART, CAN etc.

Luați în considerare opțiunile pentru programarea microcontrolerelor fără un bootloader încorporat.

• Multe plăci populare (cum ar fi LaunchPad și Nucleo) au programatori încorporați. Acest lucru vă permite să le conectați la un computer prin USB și să efectuați programarea.
• Pentru plăcile care nu au un programator încorporat, trebuie să utilizați programarea în circuit (In-System Programming, ISP). Acest lucru necesită un programator extern. De obicei, programatorul este conectat la un PC prin portul USB sau COM și la microcontroler printr-o interfață de programare specială (SWIM, JTAG, SPI, UART etc.). Exemplele includ programator ST-LINK/V2-1 pentru microcontrolere STM32/STM8 de la STMicroelectronics, programatori Atmel pentru microcontrolere AVR, programatori Microcip pentru microcontrolere PIC.

Orez. 2. STM32 Nucleo este un exemplu excelent de platformă deschisă. Plăcile Nucleo vin cu un depanator ST-LINK/V2-1 încorporat (evidențiat cu roșu)

1. Depanatoare. Un depanator este un set de instrumente care le permite programatorilor să monitorizeze execuția unui program și să găsească erori în cod. Depanatorul este format din trei părți principale: partea software, care rulează în IDE, partea hardware, care este implementată în microcontroler și partea hardware, care este implementată într-un dispozitiv special, numit și depanator. Este demn de remarcat aici că pentru toate microcontrolerele moderne, programatorul și depanatorul reprezintă același dispozitiv. Prin urmare, de exemplu, pentru programarea și depanarea STM32 / STM8, programatorul / depanatorul ST-LINK / V2-1 va fi suficient.

Să ne uităm la câteva dintre elementele și instrumentele cheie utilizate la depanarea sistemelor încorporate:

• GDB sau GNU Debugger sunt programe de depanare populare care sunt folosite pentru a lucra cu diferite limbaje de programare. Multe dintre ele acceptă „modul la distanță”, care vă permite să controlați dispozitivul care este depanat folosind o aplicație care rulează pe un PC.
• JTAG este o interfață care a fost dezvoltată inițial pentru testarea sistemelor încorporate, dar mai târziu „de facto” a devenit standardul industriei. În prezent, JTAG este utilizat pe scară largă, inclusiv în platformele deschise.
• Punctele de întrerupere sunt folosite pentru a întrerupe programele în locurile potrivite. Această funcție este necesară pentru analiza detaliată a contextului, de exemplu, starea porturilor I/O, conținutul registrelor etc. O altă caracteristică utilă a depanatoarelor este capacitatea de a depana un program pas cu pas.
• Open OCD (Open On-Chip Debugger) este un pachet open source care oferă depanare încorporată, programare în circuit și testare pentru o mare varietate de platforme, făcând Open OCD atractiv pentru mulți producători de cipuri. Open OCD acceptă multe programe de depanare, inclusiv JTAG.

1. Instrumente pentru urmărirea erorilor și controlul versiunilor

• A avea un instrument de urmărire a erorilor este o necesitate pentru platformele deschise, indiferent de numărul de dezvoltatori și utilizatori. Există multe instrumente de urmărire a erorilor. De exemplu, Bugzilla sau Mantis BT pot fi descărcate și instalate pe servere gratuit și există servicii care pot oferi găzduire pentru o taxă nominală.
• Sistemele de control al versiunilor sunt un alt instrument care este critic pentru platformele deschise, mai ales că platformele deschise implică mai mulți utilizatori și dezvoltatori care lucrează împreună. Instrumente precum Git și Subversion sunt sisteme populare de gestionare a versiunilor și a conținutului. Servicii precum GitHub oferă găzduire de conținut de proiect, urmărire a erorilor și recenzii colaborative ale codului.

Platformele hardware deschise ajută la simplificarea procesului de dezvoltare și la reducerea semnificativă a costurilor acestuia. În același timp, platforma trebuie să aibă instrumente de dezvoltare și depanare fiabile și ieftine, altfel este puțin probabil să trezească interesul utilizatorilor.

În loc de o concluzie, încă un gând după

De foarte multe ori, dezvoltatorii se limitează la a deveni specialiști într-un singur procesor sau microcontroler. Desigur, un studiu amănunțit al tuturor registrelor și caracteristicilor nucleului procesorului este un mare plus pentru un anumit proiect. Cu toate acestea, merită remarcat faptul că tehnologia nu stă pe loc, iar capacitatea de a se adapta rapid la diferite platforme este o abilitate mult mai valoroasă decât cunoașterea tuturor complexităților unei singure soluții. Proiectele deschise simplifică foarte mult o astfel de instruire la scară largă prin reducerea costurilor și a timpului. Încercați să obțineți experiență cu Arduino, puneți mâna pe microcontrolere PIC, lucrați cu un programator extern! Acest proces de auto-educare poate ajuta chiar la obținerea unui loc de muncă, de exemplu, studenții fără experiență, dacă se „luminează” pe orice forum. Stăpânirea diferitelor soluții și arhitecturi vă va perfecționa abilitățile de auto-învățare, care vor fi cheia unei cariere lungi și de succes.

Pregătirea preliminară

- Toată lumea vă rugăm să respectați centura de siguranță și nu au fost aprinse semnele de fumat. Stai pe spate și bucură-te de plimbare.

Deci, în ordine.
Testarea este efectuată în toate etapele de viață ale echipamentului. Testarea poate fi inițială (aducere), componentă, funcțională, de încărcare, producție și chiar testare pe clienți.

Chiar și în stadiul de dezvoltare a echipamentelor, un inginer se gândește la modul în care își va reînvia urmașii. Plăcile sunt presărate cu puncte de testare, conectori de depanare, jumperi, amprente pentru componente de rezervă și altele asemenea. Setul de capabilități de testare încorporate în echipament se numește DFT (Design for Testability). O placă lansată în faza DFT poate conține de două ori mai multe componente decât o placă eliberată în circulație. Desigur, urmând principiul „funcționează - nu-l atinge”, atunci nimeni nu îl reface, iar utilizatorul final examinează perplex locurile goale de pe placa de bază din magazin, venind cu diverse teorii ale conspirației despre scopul lor.

Deci, placa noastră a fost luată din fabrică - ce să facem în continuare? Ei bine, bineînțeles - conectați-l la o priză și lăsați tot fumul alb din ea.

- Toată lumea cade prima dată.

Fotografie de pe Internet, nu am găsit nicio placă arse, dar mărturisesc - uneori se face. Există o istorie lungă în memoria mea când un arhitect de sistem curios s-a așezat și a ales la întâmplare ce conectori să conecteze faza, neutrul și împământarea (ei bine, nu a avut timp să se uite în circuit), iar dezvoltatorul a stat alături. la el și l-a prins pe cel palid.

Dar de obicei lucrurile stau altfel. Prima fază a testării este aducerea (în mod popular „reînvie”).

Revitalizare Naștere

- Trezește-te Neo...

Pentru aducere, se fac de obicei 3-5 mostre (presupunând că cel puțin două vor fi distruse în delirul de depanare). Dacă dispozitivul conține cipuri scumpe, acestea nu sunt instalate pe una dintre mostre. Fab poate să vă ofere să economisiți pe aur - NU SUNTEȚI DE ACORD ÎN NICIO CAZ (ei bine, trebuie doar să lipiți mult și des).

O placă fără cip este primul candidat pentru sacrificare. Verifică secvența de pornire, resetări, tensiuni nominale și așa mai departe. Atunci un astfel de consiliu este un donator de organe și/sau un teren de testare pentru testarea tot felul de ipoteze. De asemenea, înainte de a porni ceva, trebuie să:

• sunetul sursei de alimentare la pământ, există adesea un scurtcircuit acolo;
• inspectați vizual placa - polaritatea condensatoarelor este ușor inversată acolo, cipurile sunt cu susul în jos, există cipuri, puteți găsi cu ușurință componente pasive care au fost rupte;
• studiați separat - și ați pus componente pe placă pe care ați cerut să nu le instalați (life hack: nu faceți o mască neagră la primele mostre - nu puteți vedea dacă sunt instalate sau nu rezistențe de cip pe ea).

Ne-am jucat destul cu prima victimă - vom arunca fum de pe tabla de luptă. În acest caz, este necesar să vă aprovizionați cu un pilot cu un buton de oprire a alimentării și o cameră termică. Pilotul trebuie pus sub picior, in cazul in care 220 V loveste mainile (bine, sau doar mainile sunt ocupate), iar scurtcircuitul se vede in termocamera.

Dar, în general, atunci când îl porniți pentru prima dată, de obicei nu trebuie să vă fie teamă - cel mai probabil nu se va porni, deoarece probabil ați uitat să relipiți componentele care au picioarele amestecate în design :

Și lipiți niște fire:

Lipiciul fierbinte este totul, cel mai bun prieten al dezvoltatorului, aproape ca banda scotch în viața de zi cu zi.
Imediat după Dremel:

Iar ciocanele care trebuie să înfișeze bonkurile în bord nu ies întotdeauna bine.

Uneori este necesar să se facă pacientului o radiografie sau o tomografie. Arata cam asa:

Se pare că scanarea filmului nu este foarte ușoară. Filmat cu un telefon în fața ferestrei.

Mai exact, nimic nu este vizibil în această imagine - nu priviți. Dar, în general, pe radiografie, puteți vedea nelipire, crăpături și chestii de genul ăsta.

Separat, merită menționată aducerea plăcilor de bază, deoarece se face diferit. Mostrele mame DFT sunt de obicei comandate mult - aproximativ 20 de bucăți. Este scump, așa că există o strategie aici.

Dezvoltatorii sunt luați și trimiși la fabrică. Sunt asamblate aproximativ 5 plăci și transportorul se oprește. Apoi dezvoltatorii au aproximativ 30 de minute pentru a porni placa (pentru sistemele x86, criteriul de succes este încărcarea BIOS-ului). Dacă toată lumea are noroc, restul probelor sunt colectate. Dacă nu, producția este anulată, iar dezvoltatorii merg acasă să se gândească. Banii cheltuiți pe PCB sunt pierduți, dar componentele așteaptă în depozit următoarea încercare.

Bine - am lansat placa noastră și chiar am lansat altele care ar trebui să funcționeze cu ea. Ce urmeaza? Colectăm standul.
Și atunci probabil că te aștepți să vezi asta?

Toate acestea sunt vitrine pentru viceminiștri. Un suport adevărat ar trebui asamblat din bețe și ghinde și arată astfel:

- N-am spus că va fi ușor, Neo.Am spus doar că va fi adevărul.
(un pahar pentru contragreutate, un creion - astfel încât radiatorul să stea bine - este înfășurat acolo cu un fir)

Această hoardă se înghesuie în laborator:

Și toată lumea începe să alerge să-și croiască firmware-ul, programele și să găsească peste tot cu un osciloscop.
Uneori, în proces, există o cerere politicoasă „Dragă coleg, vă rog să-mi scoateți fierul de lipit din mână – este foarte fierbinte” sau „Fiți atât de amabili – nu porniți din nou sursa de alimentare când înșurubați placa pe șasiu”.

În cazul nostru particular, scopul principal al verificării compatibilității mai multor dispozitive este de a afla dacă PCI Express funcționează, dacă respectă standardul. Practic, poți trăi fără orice altceva. De obicei, funcționalitatea introdusă în piesa de fier este redundantă. Tone de pini GPIO, autobuze I2C/SPI, senzori termici, gheață și alte lucruri, de regulă, rămân nerevendicate, deoarece depanarea lor este amânată până în ultimul moment care nu vine niciodată.

Bineînțeles, nu avem echipamente de măsurare în valoare de câteva milioane de ruble pentru fiecare ocazie a vieții - aceasta este pentru băieți. Software-ul de testare de la producătorii de componente se grăbește să ne ajute. Aproape toate cipurile moderne cu interfețe de mare viteză au în interior un osciloscop digital. Se bazează pe software specializat care vă permite să citiți mărturia acestuia. Începem și ne uităm la diagramele ochilor. Vedem asta:

Uneori vedem o strabire periculoasă:

Și uneori prindem calmari:

Calamarii sunt cei mai periculoși. Acestea sunt distorsiuni neliniare, iar egalizatoarele încorporate nu sunt în mod special capabile să facă față acestui lucru. Calamarii inseamna ca undeva in canalul de comunicatie este ceva foarte rau - o via prea lunga, o scadere semnificativa a impedanței, un fel de neuniformitate in 1/4 sau 1/2 lungime de unda a unor armonici din banda utila etc. asemanatoare.

S-ar putea observa că calmarul seamănă puțin cu ceea ce face cu semnalul DFE primit în egalizatorul unui receptor PCIe. Dar în acest caz, acesta este încă un calmar și nu rezultatul operațiunii DFE (software-ul pe care îl folosim nu poate afișa rezultatul operațiunii DFE).

Separat, trebuie spus despre software-ul de testare, care poate fi și extrem de insidios. De exemplu, pentru a fotografia diagrame de ochi, folosim două versiuni ale aceluiași program - o versiune desenează imagini, dar nu scrie valori de deschidere a ochilor, a doua face opusul.

Ei bine, da - dacă intenționați să trageți ochi folosind interfața I2C - uitați, va fi foarte foarte foarte lent. Doar în bandă. Problema este că, pentru a elimina in-band, dispozitivul trebuie să aibă o legătură PCIe funcțională cu computerul pe care rulează software-ul de testare, ceea ce este foarte problematic atunci când hardware-ul nu este instalat într-un slot PCIe standard. Iar amuzant este că ar trebui să ai deja măcar un link de lucru pe canalul pe care îl depanezi și exact în modul (gen2 / 3) în care ai nevoie (pentru că în moduri diferite există ochi diferiți și egalizatoarele funcționează diferit). ). Fără picioare, fără desene animate, fără ochi - așa vrei și ieși.

Despre cum să ieși cu PCIe - anterior am scris un separat.

În general, atunci când dezvoltați un server, desigur, suportul din partea producătorilor componentelor utilizate este foarte important, deoarece astăzi complexitatea chiar și a cipurilor relativ simple este de așa natură încât este puțin probabil să fie posibilă verificarea și depanarea completă a sistemului. fără a folosi elementele de testare încorporate în ele. Generatoare de ceas, regulatoare de tensiune, controlere de rețea, comutatoare PCI Express, drivere - toate acestea au instrumente încorporate pentru configurare, diagnosticare și au nevoie de un anumit set de programe și cabluri pentru a se conecta pentru configurarea și testarea completă, fără de care dezvoltarea devine pur și simplu imposibilă .

În procesul de efectuare a inspecțiilor, uneori se dovedește că undeva ceva nu merge bine. Și apoi începe procesul captivant de localizare a erorii, astfel încât să poată fi remediată în următoarea revizuire. Și este bine dacă acest „nu este așa” se repetă în mod constant - atunci de obicei nu este dificil să aflați care este exact cauza erorii. Dar uneori lucrurile stau mult mai rău. De exemplu, pe unele cazuri de plăci, în timpul unei perioade lungi de teste, apar erori individuale necorectabile pe magistrală (care nu ar trebui să fie deloc). Și aici este adesea deja necesar să aplicați metoda „privire mai atentă” - adică, stați, uitați-vă ipotetic la circuit, ghiciți care ar putea fi motivul, încercați să eliminați acest motiv ipotetic din circuit și verificați deja cu testează dacă am ghicit bine sau nu.

Am întâlnit acest lucru în urmă cu câțiva ani, când testele NVIDIA (da, mulți producători oferă seturi de teste specifice care vă permit să verificați lucruri care nu sunt disponibile programatic folosind utilitare standard) au dat erori rare rare în timpul rulărilor lungi (zi sau mai multe) pe unele plăci . . Apoi, totul s-a dovedit a fi o urmărire nereușită a ceasului de referință (100 MHz) - deși înainte de a ajunge la asta, au fost verificate o mulțime de lucruri, începând de la calitatea sursei de alimentare și terminând cu diagramele de ochi pentru toate linii.

Și apropo, e bine. Cel mai mare coșmar al unui dezvoltator este atunci când totul funcționează deodată. Acest lucru înseamnă un singur lucru - o mină este îngropată undeva, care va funcționa după expedierea a 100.500 de echipamente către client. Cert este că, în procesul de căutare a cauzei unei probleme globale, sunt testate mai multe ipoteze și, de regulă, sunt relevate multe mici defecțiuni care nu au legătură cu problema care a apărut. Nu este nicio problemă mare - nu veți găsi altele mici. Clienții tăi le vor găsi pentru tine.

Verificarea listei

- Tot ce fac este ceea ce îmi spune el să fac.

După finalizarea testelor de componente, începe testarea funcțională - verificarea operabilității complexului în ansamblu și funcționarea corectă a tuturor funcțiilor încorporate. Acest lucru este de obicei făcut de QA. Domeniul de aplicare al creativității aici, desigur, este foarte extins, dar, în general, accentul principal este pus pe funcționarea corectă a sistemului atunci când se joacă scenarii de utilizare standard. Aici, erorile detectate pot fi deja atât de natură hardware, cât și software, așa că este important să aflați în primul rând ce anume a cauzat eroarea. Adesea, primele presupuneri pot fi înșelătoare, adică o problemă clară hardware la prima vedere poate fi cauzată de funcționarea incorectă a firmware-ului. O parte semnificativă a testării funcționale este verificarea modului în care sistemul gestionează diverse erori care pot apărea în timpul funcționării. Instrumentele moderne de depanare vă permit să injectați artificial erori în interfețele standard ale procesorului, deoarece la nivel hardware este destul de problematic să creați multe dintre ele intenționat (ei bine, nu rupeți cipurile de memorie din mers sau scurtați liniile de magistrală PCI Express) .

Ah... Nu am spus că testarea funcțională nu înseamnă un sistem asamblat, gata de luptă. Și aici nu totul merge bine. La un moment dat, s-a dovedit că nu aveam în stoc cabluri OcuLink de lungimea necesară, iar serverul a părut curaj.

Și din anumite motive, într-o astfel de configurație, în timpul unui test de încărcare, totul a început să se supraîncălzească. Încă ne întrebăm de ce. Cablurile s-au încins, cred.

Poți purta doi pepeni în fiecare mână?

- „Ești mai rapid decât asta. Să nu crezi că ești, să știi că ești...

La un moment dat, în paralel cu testarea funcțională, începe testarea încărcării - este important să vă asigurați că serverul continuă să funcționeze corect în moduri de operare extreme. În plus, testele de încărcare sunt efectuate atât în ​​raport cu subsisteme individuale (discuri, memorie, procesoare, I/O), cât și pe întregul sistem în ansamblu. De regulă, testele localizate vă permit să încărcați un anumit modul mai mult decât se poate face cu sarcina maximă pe întregul sistem.

În plus, instrumentele de depanare de la producătorul platformei hardware (de exemplu, Hardware Tests Executive de la IBM) ajută aici. Astfel, este posibil să conduceți procesorul în moduri complet limitative, care sunt fundamental de neatins atunci când rulați aplicații reale. Principalele probleme detectate în timpul testării sarcinii sunt supraîncălzirea, instabilitatea sursei de alimentare sau suprasarcina maximă de curent, erorile în timpul lucrului activ cu interfețele I/O.

Benchmark-urile vin și ele în ajutor. Pentru că atunci când valorile reale ale benchmark-urilor sunt foarte diferite de cele prezise, ​​atunci ceva a mers prost. Un motiv întemeiat să împingi tabla cu un băț.

În etapa de testare, folosim în principal microbenchmark-uri:
Pentru procesoare, acestea sunt de obicei încărcări cu un singur thread, cum ar fi spec2006(acum deja specpu2017), parsec, dar, în general, există un număr mare de ele din asamblarea nucleului Linux și compresie ( lzma, gzip), înainte de a înmulți matrice și de a calcula transformarea Fourier rapidă ( fftw).
De mulți ani, nimic nu s-a schimbat pentru memorie: CURENT,Viteza RAM SMP, lmbench.

Pentru discuri: fio, iozon.

Dacă toate testele funcționale și de sarcină sunt trecute cu succes, există încă o serie de lucruri care trebuie verificate - stabilitatea funcționării pe întregul interval de temperatură, rezistența la vibrații, verificarea compatibilității cu un anumit set de componente standard (memorie, discuri, controlere PCI Express).

P.S.: După ce am verificat totul și ne-am bucurat de testele funcționale ale primei revizii a serverului, trei servere s-au prăbușit brusc în laboratorul nostru. Am început să verificăm alimentarea și pe linia de 1.2V (alimentare pentru magistrala PCIe a procesoarelor) am văzut așa:

Îți concentrez atenția - o celulă 500mV. Valoarea nominală este de 1,2 V. Rezistorul a fost greșit în circuitul de compensare al unuia dintre VRM-uri. Cu o astfel de sursă de alimentare, toate testele de sarcină, criteriile de referință, prăjirea și alte lucruri similare au fost trecute cu succes, iar designul a trecut cu bucurie la a doua revizuire.
Deci, când un ecran al morții apare brusc pe computerul confortabil de acasă al unui brand celebru, nu ar trebui să vă gândiți că acesta este cu siguranță „Windows buggy”.

Tehnologiile de virtualizare sunt acum utilizate în multe domenii ale IT, atât în ​​mediul de producție, cât și de către entuziaști și utilizatori casnici pentru o varietate de sarcini. Mai multe sisteme virtuale care rulează simultan pe o singură mașină fizică cresc în mod semnificativ flexibilitatea infrastructurii IT și măresc eficiența utilizării resurselor hardware. Testarea software-ului este unul dintre cele mai frecvente cazuri de utilizare pentru platformele de virtualizare. Nu este surprinzător că mașinile virtuale au multe caracteristici utile care reduc semnificativ timpul de dezvoltare și testare și cresc eficiența acestor procese.

În modelul clasic de dezvoltare a software-ului, programatorii și inginerii de calitate software trebuiau de cele mai multe ori să testeze un produs software pe o singură platformă aproape tot timpul de dezvoltare și abia la sfârșit să-l testeze în diverse sisteme de operare și medii de utilizator (așadar. -numită testare configurație, Testare configurații). ). În plus, nu erau atât de multe computere fizice la dispoziția departamentelor de testare și dezvoltare, iar pe o singură mașină, într-un sistem de operare, este imposibil, de exemplu, să se instaleze mai multe versiuni ale unui produs software în același timp, cu cu care programul dezvoltat trebuie să interacționeze. Ca urmare, în software, în special în echipele mici de dezvoltare, au existat adesea erori legate de particularitățile configurațiilor utilizatorilor, deoarece nu a existat suficient timp și resurse pentru testarea completă a configurației. În plus, inginerii de calitate au trebuit să petreacă mult timp implementând un set de produse software pe bancuri de testare și configurându-și munca în infrastructura de rețea.

Desigur, una dintre cele mai grave probleme ale dezvoltării software este faptul că, în primele etape de dezvoltare, ansamblurile unui produs software în timpul lucrului lor pot provoca daune ireparabile sistemului (de exemplu, diverse drivere de dispozitiv). Prin urmare, este necesar să se planifice restaurarea sistemelor de operare și a setărilor acestora după eșecurile din backup-urile și să aloce timp considerabil pentru restaurarea acestora.

Trebuie remarcat faptul că există o altă problemă care este destul de comună în dezvoltarea de software și necesită timp considerabil pentru a fi alocat soluționării acesteia. Toți programatorii care au experiență în interacțiunea cu echipele de testare cunosc următoarea situație: în sistemul de urmărire a erorilor, testerul remediază un defect pe care programatorul nu îl poate repeta în niciun fel. După ce programatorul setează starea problemei ca fiind rezolvată, testerul îl cheamă la aparatul său și demonstrează vizual eroarea. În această situație, se ajunge la punctul în care programatorul trebuie să instaleze o mulțime de depanatoare și alte prostii inutile pe mașina testerului și să „prindă” defectul, oprind complet munca testerului. Dacă adăugăm la aceasta timpul pentru care testerul să elimine utilitățile de programare, obținem o pierdere serioasă de timp în echipă.

În plus, caracteristicile funcționării unor produse software necesită verificarea funcționării acestora în anumite condiții (cantitate diferită de RAM, lățime de bandă a canalului de comunicație, frecvență procesor etc.). În acest caz, este posibil ca echipa de testare să nu aibă la dispoziție configurația hardware necesară (ce se întâmplă dacă avem nevoie de zece hard disk-uri?). Atunci când se determină cerințele de sistem ale unui produs pentru astfel de factori, această nevoie poate fi critică.

În încheierea enumerarii listei de probleme care apar în procesul de dezvoltare și testare, ar trebui să se acorde încă una. Adesea există o astfel de situație când este necesară verificarea asamblarii unui produs software „pentru fum” (așa-numitul test de fum, Smoke Testing), ceea ce înseamnă o rulare rapidă a celor mai importante teste. Dar dacă dezvoltăm o aplicație care necesită versiuni diferite de Internet Explorer? În acest caz, se va petrece mult timp pentru încărcarea sistemului corespunzător unde este instalată versiunea necesară.

Rezumând situațiile descrise, să rezumăm problemele care sunt adesea întâlnite în procesul de dezvoltare și testare a produselor software:

• necesitatea de a testa software-ul în mai multe configurații de utilizator decât este disponibil pentru testarea computerelor fizice
• costuri mari de timp pentru implementarea și configurarea bancilor de testare care conțin multe componente diferite, între care este asigurată interacțiunea în rețea
• costuri mari de timp pentru crearea de copii de rezervă ale sistemelor și configurațiile acestora, precum și recuperarea după o defecțiune din cauza funcționării instabile a ansamblurilor de produse software
• incapacitatea de a reproduce defectul găsit de tester pe mașina dezvoltatorului și pierderea de timp pentru a-l găsi, a-l remedia
• necesitatea de a testa programul într-un mediu hardware care nu este disponibil echipei de testare
• necesitatea de a testa un produs software în condiții care necesită comutare rapidă între configurațiile utilizatorului

Dacă calculezi cât timp și cât resurse sunt cheltuite pentru rezolvarea acestor probleme, obții o cifră foarte, foarte impresionantă, care, exprimată în termeni monetari, reprezintă o parte destul de mare din bugetul proiectului.

Tehnologiile de virtualizare, aplicate corect în procesul de dezvoltare și testare, pot reduce semnificativ costurile cu forța de muncă și pot crește semnificativ eficiența procesului, ceea ce va afecta pozitiv calitatea produsului software lansat. Deci, în mod specific, virtualizarea vă permite să faceți acest lucru:

• testerii în proces de lucru cu mașini virtuale pot crea un număr nelimitat de configurații de utilizator pe mașina lor fizică, lansând, dacă este necesar, cea mai potrivită momentan
• odată create, configurațiile multi-mașină pot fi configurate folosind instrumente platformei de virtualizare și pur și simplu transferate pe alt hardware, fără a fi nevoie să le reconfigurați
• o mașină virtuală poate fi salvată prin copierea unui folder sau prin crearea unui instantaneu al stării („snapshot”)
• după găsirea unei erori de către un tester, o mașină virtuală cu un defect repetat poate fi transferată unui dezvoltator, eliberând în același timp resurse pentru testare ulterioară
• condițiile necesare pentru testare pot fi create rapid datorită configurației flexibile a parametrilor mediului hardware al mașinii virtuale (cantitatea de RAM, numărul de procesoare virtuale, limitele de resurse)
• capacitatea de a reveni rapid la o stare salvată a unei mașini virtuale cu configurația necesară sau comutarea între mai multe sisteme invitate care rulează simultan reduce timpul de testare

Toate soluțiile de mai sus ar trebui luate în considerare în lumina faptului că o mașină virtuală cu software instalat în ea este un obiect foarte flexibil, care poate fi atât rapid implementat pe mașinile client dintr-un depozit centralizat de șabloane de configurare a utilizatorului, cât și configurat ca flexibil. pe cât posibil în raport cu setările oaspeţilor.sistemul şi mediul său. Portabilitatea ușoară către alt hardware și independența față de platforma hardware este un avantaj cheie al mașinilor virtuale.

Mașini-unelte virtuale pentru testare și dezvoltare

La implementarea unei infrastructuri virtuale în scopul dezvoltării și testării software-ului, este necesar, în primul rând, să alegeți cea mai potrivită, fiabilă și eficientă platformă de virtualizare care să îndeplinească toate cerințele procesului de dezvoltare într-o organizație. Există două modalități cele mai comune de a utiliza mașini virtuale pentru a testa produse software:

• Implementarea negestionată a mașinilor virtuale pe mașinile client sau pe servere de testare, în care testerii fie creează configurațiile de care au nevoie, fie copiază șabloane de sistem virtual pe computerele lor dintr-o bibliotecă centrală de șabloane virtuale (server de fișiere). Avantajul acestei abordări este ieftinitatea soluției, puteți utiliza unul dintre numeroasele sisteme de virtualizare gratuite (VMware Server, Virtual PC, VirtualBox și altele). Principalele dezavantaje - desfășurarea spontană a mașinilor virtuale generează conflicte în infrastructura rețelei, lipsa controlului asupra utilizării licențelor pentru sistemele de operare și aplicații software, incapacitatea de a se integra în mediul IT existent al organizației.
• Implementarea gestionată a sistemelor virtuale din biblioteci centralizate de șabloane virtuale, cu control deplin asupra utilizării mașinilor virtuale în cadrul infrastructurii IT a companiei. Avantajele acestei abordări includ capacitatea de a rezolva conflictele dintre sistemele virtuale și cele fizice din rețea, de a controla utilizarea licențelor, abilitatea de a monitoriza utilizarea infrastructurii virtuale și de a crea un spațiu comun între diverșii participanți la procesul de dezvoltare și testare, integrarea în infrastructura IT reală a întreprinderii. Principalul dezavantaj al acestei abordări este costul ridicat al soluțiilor. Exemple de produse care asigură implementarea gestionată a mașinilor virtuale: VMware LabManager, VMLogix LabManager, Microsoft System Center Virtual Machine Manager.

Platformele de virtualizare, dintre care acum există un număr mare pe piață, se dezvoltă într-un ritm rapid și oferă utilizatorilor un set tot mai mare de instrumente pentru a îmbunătăți eficiența procesului de dezvoltare și testare. Pentru a rezolva fiecare dintre aceste probleme, platformele de virtualizare ale diverșilor furnizori au propriile lor instrumente care permit utilizatorilor să testeze eficient produsele software în mașinile virtuale.

1. Crearea multor configurații personalizate.

   Dacă există o cantitate mare de spațiu liber pe disc pe mașina testerului, folosind platforma de virtualizare, puteți crea un număr nelimitat de sisteme virtuale, fiecare dintre acestea putând fi pornit la cerere, fără a opri munca lucrătorului pe sistemul gazdă. Mașinile virtuale pot fi utilizate și pe servere de testare specializate bazate pe platformele VMware ESX Server, XenEnterprise sau Virtual Iron. În același timp, anumite drepturi pot fi atribuite utilizatorilor sistemelor virtuale, precum și resursele fizice ale serverului care pot fi utilizate de un anumit utilizator sunt limitate. Un server de fișiere cu șabloane virtuale poate stoca mașini virtuale preinstalate care sunt implementate pentru a testa servere sau stații de lucru. În acest caz, trebuie să țineți cont de particularitățile utilizării mașinilor virtuale în conformitate cu licența. În cele mai multe cazuri, fiecare mașină virtuală necesită o licență separată, dar există și excepții: de exemplu, o licență Windows Server 2003 Datacenter Edition vă permite să rulați un număr nelimitat de instanțe virtuale ale sistemului de operare.

   Dacă mediul de testare configurat este deja implementat pe o mașină fizică, acesta poate fi migrat la unul virtual folosind produsele furnizorilor de platforme de virtualizare și dezvoltatorilor terți. Astfel de soluții includ produsele PlateSpin PowerConvert, VMware Converter, Microsoft Migration Toolkit.

2. Crearea de configurații multi-mașină pe un singur server fizic.

   Platformele de virtualizare axate pe testarea software-ului (VMware Workstation, Virtual PC, VirtualBox, Xen) vă permit să creați infrastructuri virtuale întregi cu diferite tipuri de rețea într-o singură gazdă fizică. De exemplu, puteți crea mai multe „blocuri” de servere virtuale (server de baze de date, server de aplicații, mediu client), puteți configura adaptoare de rețea pentru mașini virtuale (o mașină poate avea mai multe, până la zece în VMware Workstation) și puteți rula o mulțime de servere. În același timp, platformele de virtualizare vă permit să conectați adaptoare de rețea pentru mașini virtuale la diferite segmente de rețea virtuală.
   

   După crearea infrastructurii virtuale de testare, puteți configura parametrii canalelor de comunicare între mașinile virtuale.
   

   Trebuie remarcat faptul că rețelele virtuale nu sunt portabile pe toate platformele de virtualizare și, uneori, trebuie reconfigurate atunci când se mută mașinile virtuale pe alt hardware.

3. Faceți backup mașinilor virtuale în timpul testării.

   Dacă testerii folosesc mașini virtuale pe stațiile lor de lucru, le pot face copii de rezervă prin copierea folderului de fișiere al mașinii virtuale. În cazul unui blocaj al sistemului, copia salvată nu trebuie restaurată - este deja complet gata de utilizare. În plus, multe platforme de virtualizare vă permit să creați mai multe instantanee ale stării unei mașini virtuale, fiecare dintre acestea putând fi derulată înapoi în câteva minute.

   Dacă testarea se face pe servere de testare dedicate, furnizorii de mașini virtuale, cum ar fi vRanger Pro de la Vizioncore, VMware Consolidated Backup (VCB) sau Microsoft Data Protection Manager pentru Virtual Server 2005, care nu a fost lansat încă, pot fi utilizați pentru a crea copii de rezervă virtuale. R2, care vă permit să faceți backup mașinilor virtuale fără a le opri.

4. Demonstrarea defectelor pentru dezvoltatori.

   Când este găsit un defect, testerul poate pur și simplu să salveze starea sistemului în care apare eroarea într-un instantaneu și să continue testarea sistemului. Dacă este necesar să se demonstreze un defect, mașina virtuală poate fi transferată unui dezvoltator care poate lucra cu ea fără teama de a deteriora mediul testerului. În plus, pe platforma VMware Workstation, mașinile virtuale pot acționa ca servere VNC fără a fi nevoie să instaleze software suplimentar pentru accesul la desktop la distanță.
   

5. Configurare flexibilă a mediului hardware.

   Adesea, atunci când testați software-ul, aveți nevoie de mai multă flexibilitate în ceea ce privește configurarea componentelor hardware. De exemplu, în timpul testării de stres (Stress Testing) este necesară verificarea funcționării unui produs software în condiții extreme sau limitate (lipsa spațiului pe disc, eșecul conexiunii la rețea). În acest caz, folosind platforma de virtualizare pentru o mașină virtuală, puteți adăuga noi dispozitive virtuale sau puteți limita resursele alocate acesteia.

   În același timp, dacă adăugăm un disc virtual în sistemul invitat, îl putem crea ca expansiv dinamic, ceea ce ne permite să economisim spațiu liber pe disc și, de asemenea, să creăm așa-numitele discuri Undo, modificări la care sunt valabile numai în timpul lucrului. cu mașina virtuală și la terminarea sesiunii poate fi anulată, ceea ce este foarte convenabil pentru testare.
   

   În ceea ce privește controlul resurselor, multe platforme de virtualizare vă permit să limitați resursele unei mașini virtuale sau a unui pool de resurse de mașini virtuale, ceea ce vă permite să simulați condițiile reale ale mediilor de utilizator.

   Platformele moderne de virtualizare acceptă standardul USB 2.0, un număr mare de adaptoare de rețea virtuale într-o mașină virtuală, emularea discurilor SCSI și reprezentarea unui număr diferit de procesoare într-un sistem invitat prin SMP virtual (Symmetric Multi Processing).

6. Lucrați cu mai multe sisteme virtuale în același timp.

   Această caracteristică permite testerilor nu numai să folosească instanțe ale diferitelor sisteme invitate atunci când testează, ci și să schimbe cu ușurință fișiere atât între sistemul de operare gazdă și cel invitat, cât și între sistemul de operare invitat folosind mecanismul Drag&Drop. În același timp, unele platforme de virtualizare vă permit să schimbați cu ușurință fișiere fie prin foldere partajate ale sistemului gazdă (Shared Folders), fie fișiere „drag and drop” între sistemele invitate (VMware Workstation).

   Multe platforme de virtualizare vă permit să utilizați un clipboard comun cu sistemul gazdă, ceea ce simplifică foarte mult, în special, copierea mesajelor de eroare ale programului în sistemul de urmărire a erorilor.

Instrumente de dezvoltare și testare pentru implementare negestionată

La baza implementării gestionate a mașinilor virtuale se află soluțiile specializate pentru crearea și întreținerea laboratoarelor virtuale de testare (Virtual Labs), în cadrul cărora se exercită controlul asupra utilizării sistemelor virtuale de către diverse grupuri de utilizatori, implementarea automată a mașinilor virtuale pe calculatoarele proiectului. participanților și crearea unui mediu de lucru comun. Aceste soluții sunt destul de costisitoare (de exemplu, infrastructura VMware LabManager va costa cel puțin 15.000 USD), dar se justifică pe o scară largă de utilizare. Companiile mari, cum ar fi Dell, folosesc pe scară largă mașinile virtuale în laboratoarele virtuale pentru a testa produse software. Aceste sisteme folosesc SAN-uri, unde o bibliotecă partajată de șabloane virtuale găzduiește șabloane de mașini virtuale care sunt implementate la cerere pe servere de testare gratuite bazate pe platforme de virtualizare. Utilizarea laboratoarelor virtuale oferă următoarele beneficii:

• Lucrați cu configurații cu mai multe mașini ca un singur modul, abilitatea de a publica aceste module
• Reducerea timpului petrecut la configurarea sistemelor
• Diferențierea accesului la mașinile virtuale și demonstrarea defectelor prin transmiterea de link-uri către situația problemă salvată ca instantaneu al stării sistemului oaspete
• Bibliotecă de modele generice cu capacitate de rezolvare a conflictelor de rețea la implementare (SID-uri, alocarea de adrese MAC unice interfețelor de rețea virtuală)
• Întreținere centralizată și implementare de actualizări în medii de testare
• Monitorizarea încărcării serverelor de testare

În prezent, cele mai populare soluții pentru implementarea gestionată a infrastructurii de testare virtuală sunt VMware LabManager (pentru platforma ESX Server) și VMLogix LabManager (pentru platformele Microsoft, VMware și XenSource).

Laboratoarele de testare VMware LabManager

VMware oferă companiilor mari să utilizeze o infrastructură virtuală de testare bazată pe o soluție (fosta dezvoltare a companiei achiziționate Akimbi), care vă permite să implementați rapid mașini virtuale pe servere de testare și să controlați utilizarea sistemelor virtuale, în timp ce procesul arată ca utilizatorul lucrează cu un computer fizic. Modelul laboratorului virtual este prezentat mai jos:

Pe lângă toate avantajele de mai sus ale sistemelor de management al laboratoarelor virtuale, VMware LabManager oferă integrare cu instrumente de testare populare și are capacitatea de a implementa șabloane în câteva clicuri de mouse, acceptă protocolul LDAP, se integrează cu ușurință cu alte soluții de infrastructură virtuală VMware și are capacitatea de a automatiza operațiunile prin propriul API (Application Program Interface). Principalul dezavantaj al acestui produs este capacitatea de a servi servere virtuale numai pe platformele VMware.

Laboratoarele de testare VMLogix LabManager

Spre deosebire de soluția VMware, produsul acceptă platforme de virtualizare de la diverși furnizori. Platformele Microsoft (Virtual Server), Xen (XenEnterprise) și VMware (ESX Server și Server) pot fi folosite ca bază pentru un laborator virtual de testare. În plus, LabManager de la VMLogix sprijină întreținerea serverelor fizice ale unei organizații. Arhitectura soluției VMLogix LabManager este prezentată mai jos:

LabManager oferă utilizatorilor un portal de autoservire prin care utilizatorii pot implementa mașini virtuale dintr-o bibliotecă centralizată de șabloane de sistem de operare și ISO-uri, precum și gestionarea licențelor, setările zonei de adrese IP și capabilitățile de auditare a securității infrastructurii de testare virtuală. În plus, VMLogix LabManager include, de asemenea, automatizare API, implementare multi-mașină și capabilități de întreținere și caracteristici pentru demonstrarea situațiilor problematice prin partajarea instantanee ale mașinilor virtuale.

Concluzie

Modelul de organizare a procesului de dezvoltare și testare folosind mașini virtuale poate reduce semnificativ costul implementării mediilor de testare a utilizatorilor și al configurării mediilor de testare. Conform statisticilor, atunci când se testează produse software pe servere fizice și stații de lucru, aceste sarcini ocupă până la 50% din timpul echipei de testare. Mașinile virtuale de pe platformele diferiților furnizori pot reduce acest timp de câteva ori, până la 5% din costurile totale de testare. Flexibilitatea crescută a sistemelor virtuale și independența acestora față de echipamente vă permit să lucrați cu ele ca și cu anumite blocuri din care este construită infrastructura de testare virtuală a companiei. Capacitatea de a oferi acces partajat la defectele găsite membrilor echipei de dezvoltare și utilizatorilor de produse poate accelera semnificativ căutarea și corectarea erorilor. În multe companii, testarea cu mașini virtuale a devenit deja standardul de facto.

Totuși, procesul de testare pe sisteme virtuale are unele limitări: de exemplu, sistemele virtuale nu sunt recomandate pentru testarea performanței (Performance Testing), precum și testarea aplicațiilor care impun cerințe mari asupra resurselor fizice ale computerului. Pentru alte tipuri de testare, o infrastructură de testare virtuală este una dintre cele mai bune soluții pentru a crește eficiența procesului de dezvoltare, precum și pentru a simplifica interacțiunea dintre membrii echipei.

Platforme hardware

Compatibilitate cu platforma hardwareînseamnă că computerele constau din noduri și dispozitive care au același sistem de comandă și codificare de date și, prin urmare, pot fi interschimbate. Deși acest lucru nu este necesar - dacă dispozitivele diferă foarte mult în caracteristicile tehnice, atunci unul nu poate fi înlocuit cu altul. Dar pentru diferite platforme hardware, toate componentele sunt complet diferite și incompatibile.

Pentru computere, au mai rămas doar două platforme hardware competitive: PC IBMși Apple Macintosh(Figura 3) Mai mult, IBMPC domină clar, peste 90% dintre calculatoare aparțin acestei platforme. La un moment dat, Apple Macintosh era mai potrivit pentru grafică și publicare, dar acum capacitățile ambelor platforme sunt egale aici. In orice caz,

Calculatoarele Apple nu dispar, dar sunt încă folosite.
Pentru serverele de înaltă performanță, sau invers - cipuri primitive, există și alte platforme hardware: SunMicrosystems, Compaq, HewlettPackard etc.

În configurația hardware a unui computer, un rol important îl joacă principiul arhitecturii deschise. Aceasta este construcția unui computer după un principiu modular, atunci când toate dispozitivele de același tip au:

1. protocoale (standarde) convenite de comun acord pentru transmiterea datelor;

2. dimensiuni geometrice standard și conectori unificați pentru conectare.

Arhitectura deschisă permite Modernizare(Actualizare), adică actualizarea unui computer prin simpla înlocuire a unui dispozitiv cu altul fără a afecta orice altceva.

În loc de un dispozitiv învechit, au pus unul nou cu parametri mai buni și îl conectează la același conector. Sistemul de operare înregistrează noul dispozitiv și determină cele mai bune drivere pentru acesta. Dacă nu se află în interiorul sistemului de operare, atunci driverele necesare sunt preluate de pe medii externe sau de pe Internet. După aceea, computerul începe să lucreze cu parametri care sunt de câteva ori mai buni. O procedură simplă și eficientă.

Înlocuirea unor dispozitive hardware cu altele cu caracteristici mai bune se realizează într-o anumită măsură în orice dispozitive tehnice, dar nicăieri nu ajunge la o asemenea amploare ca în tehnologia computerelor. De exemplu, este dificil să ne imaginăm o mașină în care piese noi ale motorului și transmisiei sunt puse în locul celor învechite, drept urmare puterea mașinii crește de mai multe ori.

Actualizarea are limitele sale și nu puteți pune toate cele mai recente pe un computer foarte vechi. Din când în când, apar standarde fundamental de conexiune noi, vechile magistrale de sistem nu se mai produc, standardele dispozitivelor de bază, cum ar fi, de exemplu, placa de bază, se schimbă. Și apoi upgrade-ul devine lipsit de sens, este mai ușor să cumperi un computer nou.

Platforma IBMPC are o arhitectură deschisă, în timp ce Apple are una închisă.

Arhitectura deschisă ¾ este exact ceea ce a permis platformei IBM să ocupe o poziție de lider în producția de computere și să învingă concurenții la un moment dat. Și acum computerele bazate pe platforma IBM sunt dominante în lume.

Cu toate acestea, IBM însăși, prin introducerea unei arhitecturi deschise pentru produsele sale, a rezolvat cu succes problemele tactice, dar a pierdut strategic. Dispozitivele cu arhitectură deschisă pentru calculatoarele IBM au început să fie realizate de sute de companii din întreaga lume - în America, Europa, Asia. Nu există interdicții legale în acest sens. Și arhitectura autobuzului deschisă din punct de vedere tehnic face ca acest lucru să fie destul de ușor.

Drept urmare, IBM a încetat să fie singurul lider în producția de tehnologie de calcul. A devenit doar una dintre marile corporații din primii cinci producători.

Introducere După ce am aflat capabilitățile în 3DMAX ale plăcilor video moderne, este timpul să rulăm aceleași teste pentru a compara platformele hardware moderne cu un singur procesor.
În acest moment, pe piața de masă există doar două familii de procesoare care pot fi considerate „promițătoare” - platformele Socket478 și Socket462 (SocketA). Nu voi lua în considerare platformele „învechite” bazate pe procesoare Socket370 și Socket423, deoarece nu are sens să cumpăr sisteme cu un singur procesor bazate pe aceste procesoare pentru a funcționa în 3DMAX.
Desigur, sistemele deja achiziționate bazate atât pe procesoare Socket370 bazate pe nucleul Tualatin, cât și pe un cache L2 de 512Kb, precum și sistemele bazate pe procesoare Socket423 mai vechi vă permit să lucrați productiv în 3DMAX. Cu toate acestea, costul acestor sisteme „învechite” le face astăzi neprofitabile de cumpărat, deoarece sistemele bazate pe aceste procesoare nu au un avantaj de performanță sau sunt chiar inferioare sistemelor bazate pe procesoare din familiile Socket478 și Socket462 la același preț. Aceasta este o consecință a politicii Intel de înlocuire a liniilor de procesoare „învechite” cu altele noi, „promițătoare”, care se manifestă printr-o actualizare mai rapidă a liniilor de procesoare „promițătoare” și, în consecință, o reducere mai rapidă a prețurilor pentru procesoarele acestor „promițătoare”. " linii.
Cele mai productive chipset-uri pentru procesoarele Socket478 și Socket462, plăci pe care sunt disponibile în prezent spre vânzare, sunt i850 și Apollo KT266A. Nu are sens să asamblați platforme bazate pe plăci de chipset i845D cu suport pentru memorie PC2100 DDR SDRAM, deoarece memoria PC800 RDRAM costă în prezent la fel sau chiar mai ieftin decât PC2100 DDR SDRAM, oferind în același timp performanțe semnificativ mai mari.

Deci, în acest articol vom lua în considerare performanța unui sistem bazat pe o placă cu un chipset i850 (Abit TH7II) și procesoare Pentium4 - 2.2GHz, 2.0GHz cu un cache de nivel al doilea de 512Kb (nucleu Northwood) și procesoare Pentium4 - 2.0 GHz, 1,7 GHz cu un nivel al doilea cache de 256 Kb (nucleu Willamette). În primul rând, ne interesează creșterea performanței, care poate fi obținută prin dublarea cache-ului L2. dacă o creștere a frecvenței de ceas oferă un câștig de performanță comparabil.
Pentru comparație cu acest sistem, am ales o platformă formată dintr-o placă de bază bazată pe chipset-ul Apollo KT266A (Epox 8KHA+) și un procesor AthlonXP 2000+ (viteza reală de ceas este de 1667Mhz). Am luat un singur procesor pentru Socket462 din cauza faptului că AMD este cu mult în urma Intel în procesul de creștere a frecvenței de ceas a procesoarelor sale, iar frecvența de ceas a acestui procesor „de top” este chiar mai mică decât frecvența de ceas a Pentium4 junior. procesor considerat în acest material.

Descrierea configurațiilor hardware

Pentru a evalua performanța vitezei, am folosit aceleași teste ca în recenziile anterioare. Permiteți-mi să vă reamintesc că aceste benchmark-uri sunt recomandate pentru testare în 3D Studio MAX de către producătorul programului însuși.
Începând cu acest articol, m-am abținut de la testarea cu anti-aliasing activat, deoarece toate plăcile video moderne efectuează anti-aliasing fără pierderi de performanță.

Platforma #1:

Procesor – Pentium 4 2.2GHz (512Kb L2), Pentium 4 2.0А GHz (512Kb L2), Pentium 4 2.0GHz (256Kb L2), Pentium 4 1.7GHz (256Kb L2).
Placă de bază - Abit TH7II (i850)
Memorie – 1024 Mb PC800 RDRAM

Platforma #2:

Procesor - AthlonXP 2000+ (1667Mhz)
Placă de bază - Epox 8KHA+ (Apollo KT266A)
Memorie – 1024 Mb PC2100 SDRAM
Placă video - NVIDIA GeForce4 Ti4600 (versiunea Detonator 27.51)
Hard Drive – 20 Gb IBM DTLA 7200rpm

Software:

Windows 2000 SP2
3ds max 4.26 (redare OpenGL), 1280x1024 32 biți

Testarea caracteristicilor vitezei atunci când lucrați în ferestre de proiecție

1 . Primul etalon este un „test de stres” – animația scenei este redată în patru ferestre de proiecție. Cu toate acestea, metoda de redare este diferită. În cele două ferestre de sus, scena este reprezentată ca „Wireframe” (adică în modul „wire” sau „wireframe”), în stânga jos „Smooth + HighLights” + „Edged Faces” (în modul umbrit cu marginile selectate ), în partea dreaptă jos - „Smooth + HighLights”:

Această scenă conține foarte puține poligoane - doar 28 de mii, totuși, datorită redării simultane a animației în toate cele patru ferestre, fps-ul „total” este foarte mic.

Poligoane: 28868
Surse de lumină: 1
Mod: Wireframe, Smooth + Highlights

Cu afișarea simultană a animației în toate cele patru ferestre de proiecție, cea mai mare parte a sarcinii de redare a scenei cade pe pachetul de memorie CPU. După cum vedem, în acest benchmark, procesorul AMD merge bine, confirmându-și ratingul. Câștigul din creșterea cache-ului de al doilea nivel în procesoarele Intel este foarte mic și se ridică la aproximativ 5%

2 . Al doilea etalon este o scenă cu șapte obiecte geometrice de bază, cu o complexitate totală de zece mii de poligoane.

Șase obiecte sunt statice, unul se mișcă încet în jurul scenei, „trecând prin” alte obiecte. Acest benchmark verifică corectitudinea afișării „intersecției” obiectelor și viteza cu care se pot descurca driverul și hardware-ul plăcii video.

Poligoane: 9712
Surse de lumină: 1
Mod: Smooth + Highlights

Spre deosebire de precedentul, acest benchmark, în acest caz, încarcă magistrala AGP și arată viteza portului AGP al plăcii de bază. În cazul implementării incorecte a AGP, valoarea fps din acest benchmark scade la aproximativ 80-100.
Astfel, vedem că implementarea AGP este bună pe ambele platforme. Cu toate acestea, în acest benchmark, creșterea memoriei cache dă o creștere mult mai mare decât în ​​precedentul - până la 20%.

3 . Scena celui de-al treilea benchmark conține o minge care se mișcă foarte încet pe un fundal de 15.000 de poligoane.

Mingea nu intersectează alte obiecte nicăieri. Deoarece mingea se mișcă foarte încet, șoferul „corect” va face foarte puține schimbări în fiecare cadru. Cu alte cuvinte, acest benchmark testează capacitatea plăcii video de a nu redesena obiecte care nu pot fi reîmprospătate în fiecare cadru.

Poligoane: 15653
Surse de lumină: 1
Mod: Smooth + Highlights

Acest benchmark este similar cu cel precedent, iar rezultatele sistemelor sunt, de asemenea, similare cu rezultatele prezentate în benchmarkul anterior - AthlonXP 2000+ demonstrează din nou „onestitatea” ratingului său și dublarea cache-ului L2 în Pentium4 oferă o creștere vizibilă a vitezei.

4 . Acest benchmark arată capacitatea unei plăci video de a gestiona geometrie foarte complexă. Benchmark-ul arată performanța plăcilor video în modul Smooth+HighLights în scene cu geometrie complexă.

Poligoane: 200270
Surse de lumină: 1
Mod: Smooth + Highlights

În acest benchmark geometric, rezultatul depinde de puterea FPU-ului (deoarece este necesar să se calculeze geometria complexă) și de lățimea de bandă a memoriei (deoarece este necesar să se deseneze suprafețe în modul Smooth + HighLight). În primul, Athlon are un avantaj clar, totuși, lățimea de bandă RDRAM este mult mai mare, astfel încât platforma Socket462 arată un rezultat mai mic decât sistemul Pentium4 2.0GHz.

5 . Al cincilea benchmark testează capacitatea plăcilor video de a procesa geometrii extrem de complexe. De data aceasta, numărul de poligoane aproape s-a dublat și s-a ridicat la aproape 376.000. Casele stau acum pe aceeași „suprafață”.

Acest benchmark este capabil să „aducă în genunchi” orice placă video - fps-ul mediu nu depășește trei cadre. Fișierul în sine a fost creat, desigur, nu la fps=3, casele au fost create separat în fișiere diferite, iar la „instalarea pe sol”, partea nefolosită a geometriei a fost „dezactivată” pentru a crește performanța.

Poligoane: 376875
Surse de lumină: 1
Mod: Smooth + Highlights

Într-un benchmark geometric mai dificil, situația este similară cu cea precedentă, însă, cu o creștere a geometriei procesate, influența memoriei cache scade, iar influența unității FPU crește.

6 . Testarea de referință a vitezei de procesare a mai multor surse de lumină. Deoarece majoritatea plăcilor video nu acceptă mai mult de 8 lumini, acest test și încă două ulterioare conțin 8 surse de lumină de diferite tipuri. În acest test, 8 surse de lumină SpotLight, în mișcare, luminează un fel de „asteroid”:

Trebuie remarcat faptul că afișarea luminii create de Spotlights este un proces mult mai intensiv în resurse decât afișarea luminii create de lumini Omni și Direcționale.

Poligoane: 39600
Surse de lumină: 8
Mod: Smooth + Highlights

7 . Același „asteroid”, doar că acum este iluminat de opt surse direcționale de lumină. Luminile direcționale sunt „mai lente” decât Omni, dar „mai rapide” decât luminile Spotlight.

Poligoane: 39600
Surse de lumină: 8
Mod: Smooth + Highlights

8 . Din nou același „asteroid” și din nou opt surse de lumină. Acum acestea sunt lumini de tip Omni, cele mai rapide lumini din 3DMAX.

Poligoane: 39600
Surse de lumină: 8
Mod: Smooth + Highlights

În standardele de iluminare, AthlonXP 2000+ arată rezultate comparabile cu cele ale Pentium4 2.0GHz. Câștigul de performanță din creșterea memoriei cache nu depășește 10%.

9 . O scenă cu geometrie „luminoasă” și o singură sursă de lumină, doar patru mii și jumătate de poligoane, ocupând întreaga fereastră de proiecție, este un etalon de viteză de rasterizare în modul Smoth + Highlights.

În timpul mișcării camerei, placa video trebuie să rasterizeze poligoane mari și mici (în raport cu dimensiunea ecranului)

Poligoane: 4684
Surse de lumină: 1
Mod: Smooth + Highlights

În benchmark-ul de rasterizare, AthlonXP 2000+ a arătat un rezultat slab - mai mic decât cel al unui Pentium4 cu aceeași frecvență de ceas (1700Mhz). Acest lucru se explică prin faptul că în acest benchmark totul depinde de rata de transfer de date pe magistrala procesor-memorie.

10 . Benchmark care arată viteza plăcilor video cu texturi. Fișierul conține o mulțime de texturi și un minim de geometrie. Reperul este o minge rotativă, cu 48 de texturi suprapuse pe fețele sale.

Geometria minimă și texturile maxime ale acestei scene arată viteza maximă de procesare a texturii de către placa video.

Poligoane: 224
Surse de lumină: 1
Mod: Smooth + Highlights

11 . Cameră complet texturată în care camera se mișcă înăuntru. Acest benchmark este cel mai apropiat de aplicațiile reale, deoarece conține o mulțime de texturi, geometrie complexă și mai multe surse de lumină. Acest benchmark arată capabilitățile plăcilor video atunci când procesează scene complexe în modul Smooth + Highlight.

Poligoane: 12413
Surse de lumină: 8
Mod: Smooth + Highlights

12 . „Valurile” texturate animate arată viteza cu care texturile sunt procesate și modificate.

Poligoane: 880
Surse de lumină: 1
Mod: Smooth + Highlights

În cele trei benchmark-uri de textură, sistemele trebuie să calculeze texturi rotative (în primul benchmark de textură), să corecteze texturile staționare cu o cameră rotativă (în al doilea) și să deformeze textura (în al treilea).
Nu este greu de ghicit că, în primul benchmark de textură, lățimea de bandă a memoriei și dimensiunea cache-ului sunt cele mai importante - de aceea Athlon „nu se ridică” la Pentium4 2.2GHz.
Corecția texturii este efectuată de FPU, așa că în al doilea benchmark Athlon2000+ se apropie de Pentium4 2.2GHz. De asemenea, creșterea memoriei cache oferă o creștere de 15%.
Calcularea deformării texturii este, de asemenea, gestionată de FPU, iar în acest benchmark, AthlonXP 2000+ are performanțe mai bune decât Pentium4 2.2GHz.

13 . Benchmark-ul măsoară viteza de lucru în modul Wireframe. 111 mii de poligoane în modul wireframe vor fi un test serios al oricărei plăci video moderne.

Poligoane: 111270
Surse de lumină: 1
Mod: Wireframe

Acest benchmark de textură conține aceeași scenă ca benchmark-ul #4, totuși, spre deosebire de al patrulea benchmark, aici această scenă este redată în modul Wireframe. Prin urmare, în acest benchmark, totul depinde de puterea FPU-ului - Ahtlon arată un rezultat comparabil cu rezultatele procesoarelor Pentium4 care funcționează la 2GHz, iar creșterea cantității de memorie cache în acest test nu dă nicio creștere a vitezei.

Toate benchmark-urile de mai sus sunt recomandate pentru testarea plăcilor video de către producătorul 3DMAX, cu toate acestea, după cum am văzut, ele testează capacitățile plăcilor video în funcție de funcții individuale și nu există teste „generale” printre ele. Așa că am adăugat un alt reper - aceasta este o scenă cu opt lumini, 61371 poligoane și multe avioane transparente. Complexitatea acestui fișier este destul de tipică pentru astăzi, întregul fișier, împreună cu texturile, durează mai mult de 6Mb. Animația este construită pentru cea mai bună testare posibilă - camera se mișcă prin cameră, captând toate obiectele. Iată cum arată primul cadru după randarea finală:

Am folosit această scenă pentru a testa plăcile video în ambele moduri Wireframe și Smoth+Highlights. Prin urmare, avem două repere:

14 . Scenă în modul Wireframe

Poligoane: 61371
Surse de lumină: 8
Mod: Wireframe

Deoarece scena din acest benchmark este afișată în modul Wireframe, ca și în benchmark-ul anterior, cantitatea de memorie cache nu are un efect vizibil, iar rezultatul AthlonXP2000+, datorită FPU-ului puternic, s-a dovedit a fi egal cu rezultatul. de Pentium4 2.2GHz, care rulează la o frecvență mai mare de 50% și are de două ori mai multă memorie cache.

15 . Aceeași scenă în modul Smooth+HighLight

Poligoane: 61371
Surse de lumină: 8
Mod: Smooth + High Light

Deoarece scena este redată în modul Smooth+HighLight, rezultatele Athlon nu sunt la fel de bune ca în benchmark-ul anterior. Cu toate acestea, rezultatele AthlonXP 2000+ sunt egale cu cele ale Pentium4 2.0GHz, iar Athlon își confirmă din nou ratingul.
Memoria cache de 512Kb în loc de 256Kb, în ​​acest benchmark, ca în majoritatea benchmark-urilor cu geometrie „medie” și modul Smooth + HighLight, vă permite să obțineți o creștere a vitezei cu aproximativ 15%.

Testarea caracteristicilor vitezei în timpul redării finale

Am realizat randarea finală a trei scene din livrarea 3ds max4 cu aceiași parametri, la aceeași rezoluție de 800x600, deoarece procentul rezultatelor platformelor testate este același pentru toate rezoluțiile de la 640x480 la 1600x1200. Iată acele scene:

Tabel cu rezultate (timp în secunde: cu cât mai mic, cu atât mai bine):

Viteza redării finale depinde în primul rând de puterea FPU-ului, așa că în randarea finală, AthlonXP2000+ a „performat” doar puțin mai rău decât Pentium4 2.2GHz.

concluzii

Pe baza totalității rezultatelor la toate operațiunile de testare a benchmark-urilor în ferestrele de proiecție, AthlonXP 2000+ arată rezultate comparabile cu cele ale Pentium4 2.0A GHz. Mai mult, atunci când lucrează în modul Wireframe, AthlonXP2000+, datorită unui FPU extrem de puternic, demonstrează un rezultat apropiat sau egal cu cel al Pentium4 2.2GHz (în ciuda faptului că acesta din urmă funcționează la +50% viteză de ceas și are cache-ul de două ori). Prin urmare, dacă vă petreceți cea mai mare parte a timpului lucrând în modul Wireframe, atunci AthlonXP2000+ este cea mai bună alegere. În testul final al vitezei de randare, rezultatele lui AthlonXP 2000+ sunt, de asemenea, aproximativ egale cu cele ale Pentium4 2.2GHz. Astfel, la prețul procesorului AthlonXP 2000+ la 250 USD. (și cu Pentium4 2.0AGHz și 2.2GHz la prețuri de 350 USD, respectiv 550 USD) și plăci de bază mai ieftine pentru acesta, platforma Socket462 este de departe cea mai profitabilă din categoria „preț-performanță”. Cu toate acestea, cel mai rapid procesor pentru 3DMAX este Pentium4 2.2GHz.
Diferența de performanță a procesoarelor Pentium4 cu cache de 256Kb și 512Kb în marea majoritate a testelor care simulează lucrul în ferestre de proiecție și calculul de randare finală nu depășește 5%, așa că nu are sens să schimbi un procesor cu cache de 256Kb la procesoare noi. cu cache de 512 Kb. Pe de altă parte, cumpărarea de procesoare cu un cache mai mic astăzi este, de asemenea, inutilă - prețurile pentru procesoarele cu cache de 265Kb și 512Kb sunt aproape egale.