طبق تعریف رسمی ارائه شده توسط OSHWA.org: "راه حل های سخت افزاری باز راه حل هایی هستند که طراحی آنها عمومی و برای مطالعه، اصلاح، توزیع، فروش باز است. این هم برای خود محلول و هم برای مشتقات و اجزای آن صدق می کند. داده های اولیه پروژه و اجزای آن باید در قالبی ارائه شوند که امکان تغییر بیشتر آنها را فراهم کند. در حالت ایده‌آل، سخت‌افزار باز از ابزارها و مواد به‌راحتی در دسترس، فرآیندهای استاندارد، زیرساخت‌های باز، محتوای رایگان و ابزارهای توسعه منبع باز استفاده می‌کند تا حداکثر آزادی را در استفاده از آن به کاربران بدهد.

در اینجا شایان ذکر است که پلتفرم های سخت افزاری باز برای ارائه ابزارهای توسعه رایگان مورد نیاز نیستند. "ابزارهای توسعه" به طیف گسترده ای از ابزارهای طراحی و اشکال زدایی اشاره دارد، از ابزارهای اندازه گیری (مولتی متر، اسیلوسکوپ ها) و محیط های یکپارچه (IDE)، تا ابزارهای مبتنی بر وب که مدیریت پروژه کاربردی را ارائه می دهند. توجه به این نکته مهم است که بسیاری از پلتفرم‌های منبع باز معروف مانند Arduino، LaunchPad، BeagleBone و STM Nucleo کتابخانه‌های نرم‌افزار رایگان، نمونه کد و حتی کل چارچوب‌ها مانند Arduino IDE یا mbed.org را ارائه می‌دهند.

برخی از ابزارهای توسعه خود پلتفرم های باز هستند که به دلیل هزینه نسبتا کم آنها را بسیار در دسترس می کند. به عنوان مثال می توان به برد اندازه گیری جهانی Red Pitaya با لینوکس اشاره کرد. در واقع Red Pitaya یک مجموعه اندازه گیری است که جایگزین تجهیزات آزمایشگاهی می شود که به دلیل قیمت بالای آن برای کاربران عادی غیرقابل دسترس است. Red Pitaya 125 ورودی آنالوگ MSPS و 100 خروجی KSPS را به خدمات طراح ارائه می دهد. این ابزار همه کاره می تواند به عنوان انواع ابزارهای استاندارد عمل کند، مانند: یک اسیلوسکوپ با پهنای باند حدود 50 مگاهرتز، یک آنالایزر طیف، یک امپدانس سنج LCR، یک آنالایزر Bode، یک تسلیمتر، یک ژنراتور تابع با وضوح 14 بیت، از جمله موارد مناسب برای صدا و غیره. برای نمایش نتایج اندازه گیری، Red Pitaya به تبلت، رایانه شخصی یا تلفن هوشمند متصل می شود. یک ماژول افزودنی حسگر اضافه کنید و می‌توانید Red Pitaya را به بردهای آردوینو و حسگرهای SEEED Studio Grove متصل کنید تا عملکرد این سیستم اندازه‌گیری را بیشتر کنید.

برنج. 1. سیستم اندازه گیری جهانی Red Pitaya نمونه ای از یک پلت فرم سخت افزاری باز است و با حداکثر در دسترس بودن مشخص می شود. Red Pitaya دارای عملکرد اسیلوسکوپ، آنالایزر طیف، امپدانس متر، آنالایزر Bode، تسلامتر، ژنراتور تابع و غیره است.

برد Red Pitaya در سال 2013 در پلتفرم اینترنتی Kickstarter معرفی شد. این به یک اسپین آف برای شرکتی تبدیل شد که ابزارهای شتاب دهنده ذرات را توسعه می دهد. بنابراین Red Pitaya یک ابزار و نرم افزار اندازه گیری و کنترل منبع باز با پشتیبانی از برنامه نویسی بصری است. Red Pitaya توسط Matlab، LabView، Python و Scilab پشتیبانی می شود. با کد منبع باز، قابلیت های Red Pitaya را می توان با ویژگی های اضافی و ابزارهای کمکی ایجاد شده توسط کاربر گسترش داد.

بسیاری از پلتفرم های باز نیز می توانند به ابزارهای توسعه تبدیل شوند. به عنوان مثال، با استفاده از Arduino UNO، می توانید یک تحلیلگر منطق دیجیتال ایجاد کنید. با این حال، شایان ذکر است که این کارکرد اصلی چنین پلتفرم هایی نیست. اساساً، بیشتر راه حل های منبع باز برای کمک به آزمایش، اشکال زدایی و عیب یابی طراحی شده اند. در عین حال، اگر مستندات کامل و دقیقی برای آن وجود نداشته باشد، حتی بهترین برد اشکال زدایی نیز بی فایده است.

رایج ترین ابزارهای مورد استفاده در هنگام کار با پلتفرم های سخت افزاری باز را در نظر بگیرید.

1. اولین ابزار طراحی شاید مهم ترین و کم «فنی» باشد. این یک مداد معمولی است. این مداد است که به شما امکان می دهد ایده های تصور شده را فوراً روی کاغذ "تجسم" کنید، نتایج آزمایش را علامت گذاری کنید و تغییرات را اصلاح کنید تا ماه ها یا حتی سال ها بعد تصویر کامل پروژه را بازیابی کنید.
2. تجهیزات. این شامل طیف گسترده ای از ابزارها، از ابزارهای اندازه گیری (مولتی متر، اسیلوسکوپ ها) گرفته تا سازمان دهنده ها برای ذخیره سازی قطعات الکترونیکی است. متأسفانه، تجهیزات بسیار رایگان است، اما اگر به جامعه توسعه دهندگان نزدیک هستید، قرض گرفتن یک یا آن دستگاه اندازه گیری مشکلی نخواهد داشت. علاوه بر این، بسیاری از ابزارها در حال حاضر از طریق فروشگاه های آنلاین در دسترس هستند و با قیمت های بسیار پایین به فروش می رسند.
3. برنامه نویسی در کد بومی آسان نیست، بنابراین از کامپایلرها و مفسرها برای ایجاد نرم افزار تعبیه شده استفاده می شود که به توسعه دهندگان اجازه می دهد با استفاده از زبان های سطح بالا برنامه بنویسند یا حتی برنامه نویسی گرافیکی انجام دهند.

محیط های مجتمع (IDE) ابزار دیگری برای توسعه نرم افزارهای تعبیه شده است. IDE ها پلتفرم های نرم افزاری هستند که یک ویرایشگر کد منبع، یک کامپایلر/مفسر، یک دیباگر، یک ابزار اتوماسیون ساخت و گاهی اوقات ابزارهای تست را ترکیب می کنند. بسیاری از محیط های یکپارچه به شما امکان می دهند کد را اشکال زدایی کرده و عملکرد آن را در دستگاه های واقعی تجزیه و تحلیل کنید. ابزارهایی برای کمک به تجسم دستگاه و اجرای شبیه سازی ها قبل از مونتاژ نمونه اولیه وجود دارد. IDE ها تا حد زیادی فرآیند توسعه را بهینه و سرعت می بخشند.

ابزارهای توسعه و ویرایش نرم افزار معمولاً برای هسته های پردازنده خاص ایجاد می شوند. برای اکثر بردها، سازندگان مشخص می کنند که از کدام محیط توسعه استفاده کنند.

انواع اصلی IDE مورد استفاده برای ایجاد نرم افزار تعبیه شده را در نظر بگیرید:

1. محیط‌های توسعه یکپارچه رایگان (IDE)، مانند Arduino IDE، Energia IDE برای TI LaunchPads، که می‌توانند آزادانه از وب‌سایت سازنده دانلود و بر روی رایانه شخصی شما نصب شوند.
2. IDE های آنلاین که نیازی به نصب بر روی رایانه شخصی ندارند، اما نیاز به دسترسی به اینترنت دارند. مزایای آنها این است که نیازی به به روز رسانی ندارند و فضای هارد دیسک شما را اشغال نمی کنند. نمونه ای از این برنامه ها Mbed.org است.
3. محیط های توسعه پولی همانطور که در بالا ذکر شد، کامپایلرها به شما امکان می دهند با نوع خاصی از هسته های پردازنده و به طور دقیق، با مجموعه خاصی از پردازنده ها / میکروکنترلرهای خاص کار کنید. به عنوان مثال، اگر یک جفت پردازنده با هسته ARM ® Cortex ® -M4 استفاده شود، ممکن است وضعیتی باشد که یک پردازنده توسط IDE پشتیبانی شود و دومی پشتیبانی نشود. بنابراین، قبل از خرید یک IDE، باید بررسی کنید که پردازنده هدف در لیست دستگاه های پشتیبانی شده باشد. نمونه هایی از محیط های توسعه پولی، به عنوان مثال، Keil از ARM و IAR Embedded Workbench از IAR Systems هستند.
4. آزمایش‌های رایگان محیط‌های پولی با محدودیت زمانی. بسیاری از IDE ها مانند IAR و Keil دارای دوره آزمایشی رایگان با دوره آزمایشی رایگان محدود هستند. پس از پایان دوره آزمایشی، برنامه مسدود شده و نیاز به خرید مجوز دارد.
5. نسخه های رایگان محیط های پولی با عملکرد محدود. نسخه های محدودی از محیط های پولی با عملکرد کمتر وجود دارد. نمونه ای از چنین محیطی ساخت Keil برای میکروکنترلرهای STM32L0 با محدودیت اندازه کد است.
6. محیط های رایگان و متن باز، مانند راه حل های مختلف گنو. نمونه ای از یک محیط رایگان Eclipse IDE است. Eclipse IDE به شما امکان می دهد پلاگین هایی را برای پشتیبانی از زبان های برنامه نویسی مختلف، به ویژه C++ یا Python اضافه کنید. شایان ذکر است که در بیشتر موارد، کامپایلرهای رایگان از نظر کیفیت بهینه سازی کد، از همتایان تجاری پایین تر هستند. با این حال، این شکاف به مرور زمان در حال کاهش است.
7. میکروکنترلرها به صورت برنامه ریزی نشده از سازنده می آیند. برای "سیستم افزار" فیزیکی برنامه ها، یک دستگاه خاص - یک برنامه نویس مورد نیاز است. استثنا میکروکنترلرهایی هستند که دارای بوت لودر (بوت لودر) داخلی هستند. بوت لودر یک برنامه داخلی کوچک است که به شما امکان می دهد میکروکنترلرها را با استفاده از یکی از رابط های محبوب USB، UART، CAN و غیره برنامه ریزی کنید.

گزینه های برنامه ریزی میکروکنترلرها را بدون بوت لودر داخلی در نظر بگیرید.

• بسیاری از بردهای محبوب (مانند LaunchPad و Nucleo) دارای برنامه نویس داخلی هستند. این به شما امکان می دهد آنها را از طریق USB به رایانه متصل کنید و برنامه نویسی کنید.
• برای بردهایی که برنامه نویس داخلی ندارند، باید از برنامه نویسی درون مدار (In-System Programming، ISP) استفاده کنید. این به یک برنامه نویس خارجی نیاز دارد. معمولاً برنامه نویس از طریق پورت USB یا COM به رایانه شخصی و از طریق یک رابط برنامه نویسی ویژه (SWIM، JTAG، SPI، UART و غیره) به میکروکنترلر متصل می شود. به عنوان مثال می‌توان به برنامه‌نویس ST-LINK/V2-1 برای میکروکنترلرهای STM32/STM8 از ​​STMicroelectronics، برنامه‌نویس‌های Atmel برای میکروکنترلرهای AVR، برنامه‌نویس‌های میکروچیپ برای میکروکنترلرهای PIC اشاره کرد.

برنج. 2. STM32 Nucleo نمونه بارز یک پلت فرم باز است. بردهای Nucleo دارای یک دیباگر ST-LINK/V2-1 داخلی هستند (با رنگ قرمز مشخص شده است)

1. دیباگرها دیباگر مجموعه ای از ابزارها است که به برنامه نویسان اجازه می دهد تا بر اجرای برنامه نظارت کرده و خطاهای موجود در کد را پیدا کنند. دیباگر از سه قسمت اصلی تشکیل شده است: بخش نرم افزاری که در IDE اجرا می شود، بخش سخت افزاری که در میکروکنترلر پیاده سازی می شود و بخش سخت افزاری که در دستگاه خاصی پیاده سازی می شود که به آن دیباگر نیز می گویند. در اینجا شایان ذکر است که برای همه میکروکنترلرهای مدرن، برنامه نویس و دیباگر نشان دهنده یک دستگاه هستند. بنابراین، به عنوان مثال، برای برنامه نویسی و اشکال زدایی STM32 / STM8، برنامه نویس / دیباگر ST-LINK / V2-1 کافی خواهد بود.

بیایید به برخی از عناصر و ابزارهای کلیدی مورد استفاده در هنگام اشکال زدایی سیستم های تعبیه شده نگاه کنیم:

• GDB یا GNU Debugger نرم‌افزارهای رایجی هستند که برای کار با زبان‌های برنامه‌نویسی مختلف استفاده می‌شوند. بسیاری از آنها از "حالت راه دور" پشتیبانی می کنند، که به شما امکان می دهد دستگاه در حال رفع اشکال را با استفاده از برنامه ای که روی رایانه شخصی اجرا می شود، کنترل کنید.
• JTAG رابطی است که در ابتدا برای آزمایش سیستم های تعبیه شده توسعه داده شد، اما بعداً "دفاکتو" به استاندارد صنعت تبدیل شد. در حال حاضر، JTAG به طور گسترده ای از جمله در سیستم عامل های باز استفاده می شود.
• نقاط شکست برای شکستن برنامه ها در مکان های مناسب استفاده می شود. این تابع برای بررسی دقیق زمینه، به عنوان مثال، وضعیت پورت های ورودی / خروجی، محتویات رجیسترها و غیره ضروری است. یکی دیگر از ویژگی های مفید دیباگرها امکان اشکال زدایی مرحله به مرحله برنامه است.
• Open OCD (Open On-Chip Debugger) یک بسته منبع باز است که اشکال زدایی داخلی، برنامه نویسی درون مدار و تست را برای انواع مختلفی از پلتفرم ها ارائه می دهد و Open OCD را برای بسیاری از تولیدکنندگان تراشه جذاب می کند. Open OCD از بسیاری از دیباگرها از جمله JTAG پشتیبانی می کند.

1. ابزارهایی برای ردیابی اشکال و کنترل نسخه

• داشتن ابزار ردیابی اشکال برای پلتفرم های باز، صرف نظر از تعداد توسعه دهندگان و کاربران، ضروری است. ابزارهای ردیابی اشکال زیادی وجود دارد. به عنوان مثال Bugzilla یا Mantis BT را می توان به صورت رایگان دانلود و بر روی سرورها نصب کرد و خدماتی وجود دارد که می توانند با هزینه اسمی هاست ارائه دهند.
• سیستم‌های کنترل نسخه ابزار دیگری هستند که برای پلتفرم‌های باز بسیار مهم است، به خصوص که پلتفرم‌های باز شامل چندین کاربر و توسعه‌دهنده هستند که با هم کار می‌کنند. ابزارهایی مانند Git و Subversion، نسخه‌سازی و سیستم‌های مدیریت محتوا محبوب هستند. سرویس‌هایی مانند GitHub میزبانی محتوای پروژه، ردیابی اشکال و بررسی کد مشترک را ارائه می‌کنند.

پلتفرم های سخت افزاری باز به ساده سازی فرآیند توسعه و کاهش قابل توجه هزینه آن کمک می کند. در عین حال، این پلتفرم باید ابزارهای توسعه و اشکال زدایی قابل اعتماد و ارزانی داشته باشد، در غیر این صورت بعید است که علاقه ای را در بین کاربران برانگیزد.

به جای نتیجه گیری، یک بار دیگر فکر کنید

اغلب، توسعه دهندگان خود را محدود می کنند تا در یک پردازنده یا میکروکنترلر متخصص شوند. البته، مطالعه کامل همه رجیسترها و ویژگی های هسته پردازنده یک امتیاز بزرگ برای یک پروژه خاص است. با این حال، شایان ذکر است که فناوری ثابت نمی‌ماند و توانایی تطبیق سریع با پلتفرم‌های مختلف، مهارتی بسیار ارزشمندتر از دانستن تمام پیچیدگی‌های یک راه‌حل است. پروژه های باز این آموزش در مقیاس بزرگ را با کاهش هزینه ها و زمان بسیار ساده می کند. سعی کنید با آردوینو تجربه کسب کنید، دست خود را روی میکروکنترلرهای PIC بگذارید، با یک برنامه نویس خارجی کار کنید! این فرآیند خودآموزی حتی می‌تواند به شغلی، به عنوان مثال، دانش‌آموزان بی‌تجربه، اگر در هر انجمنی «روشن» شوند، کمک کند. تسلط بر راه‌حل‌ها و معماری‌های مختلف، مهارت‌های خودآموزی شما را تقویت می‌کند، که کلید یک حرفه طولانی و موفق خواهد بود.

آماده سازی اولیه

- همه لطفا کمربند ایمنی را ببندید و علائم سیگار کشیدن روشن نشده است. بنشینید و از سواری خود لذت ببرید.

بنابراین، به ترتیب.
آزمایش در تمام مراحل عمر تجهیزات انجام می شود. تست می تواند اولیه (برآوردن)، جزء، عملکردی، بارگذاری، تولید و حتی آزمایش بر روی مشتریان باشد.

حتی در مرحله توسعه تجهیزات، یک مهندس به این فکر می کند که چگونه فرزندان خود را احیا کند. تخته ها با نقاط تست، کانکتورهای رفع اشکال، جامپرها، ردپا برای قطعات یدکی و موارد مشابه پاشیده می شوند. مجموعه ای از قابلیت های تست تعبیه شده در تجهیزات DFT (Design for Testability) نامیده می شود. بردی که در فاز DFT منتشر می‌شود، می‌تواند دو برابر بیشتر از بردی که در گردش آزاد می‌شود، اجزا داشته باشد. به طور طبیعی، با پیروی از اصل "این کار می کند - آن را لمس نکنید"، سپس هیچ کس آن را بازسازی نمی کند، و کاربر نهایی با گیج، صندلی های خالی مادربرد را از فروشگاه بررسی می کند و تئوری های توطئه مختلفی در مورد هدف آنها ارائه می دهد.

بنابراین، هیئت مدیره ما از کارخانه گرفته شد - بعد چه باید کرد؟ خوب، البته - آن را به یک پریز وصل کنید و تمام دود سفید را از آن خارج کنید.

- همه برای اولین بار می افتند.

عکس از اینترنت، ما هیچ تخته سوخته ای پیدا نکردیم، اما من اعتراف می کنم - گاهی اوقات این کار انجام می شود. تاریخچه ای طولانی در حافظه من وجود دارد که یک معمار سیستم کنجکاو نشست و به طور تصادفی کانکتورهایی را انتخاب کرد که فاز، نول و زمین را به آن وصل کند (خب، او وقت نداشت به مدار نگاه کند)، و توسعه دهنده بعد از آن نشست. به او و رنگ پریده را گرفت.

اما معمولا همه چیز متفاوت است. مرحله اول آزمایش، فراخوانی است (به طور معمول "احیای").

تولد احیا

- نئو بیدار شو...

برای آوردن، معمولاً 3-5 نمونه ساخته می شود (با فرض اینکه حداقل دو نمونه در هذیان اشکال زدایی از بین می روند). اگر دستگاه حاوی تراشه های گران قیمت باشد، روی یکی از نمونه ها نصب نمی شوند. Fab ممکن است به شما پیشنهاد دهد در طلا صرفه جویی کنید - در هیچ موردی موافقت نکنید (خب، فقط باید زیاد و اغلب لحیم کاری کنید).

تخته بدون تراشه اولین کاندید برای کشتار است. توالی روشن شدن، تنظیم مجدد، رتبه بندی ولتاژ و غیره را بررسی می کند. سپس چنین هیئت مدیره ای اهدا کننده عضو و / یا محل آزمایشی برای آزمایش انواع فرضیه ها است. همچنین، قبل از اینکه چیزی را روشن کنید، باید:

• منبع تغذیه زمین را زنگ بزنید، اغلب یک اتصال کوتاه در آنجا وجود دارد.
• برد را به صورت بصری بررسی کنید - قطبیت خازن ها در آنجا به راحتی معکوس می شود ، تراشه ها وارونه هستند ، تراشه هایی وجود دارد ، می توانید به راحتی اجزای غیرفعال را پیدا کنید که پاره شده اند.
• به طور جداگانه مطالعه کنید - و آیا اجزایی را روی برد قرار داده اید که خواسته اید نصب نشود (هک زندگی: روی اولین نمونه ها ماسک سیاه نسازید - نمی توانید ببینید که آیا مقاومت های تراشه روی آن نصب شده است یا خیر).

ما به اندازه کافی با اولین قربانی بازی کرده ایم - می خواهیم دود را از صفحه مبارزه بیرون بیاوریم. در این مورد، لازم است یک پایلوت با دکمه قطع برق و تصویرگر حرارتی ذخیره شود. در صورت برخورد 220 ولت به دست ها (خوب، یا فقط دست ها مشغول هستند)، خلبان باید زیر ساق پا قرار گیرد و می توانید اتصال کوتاه را در تصویرگر حرارتی مشاهده کنید.

اما به طور کلی، هنگامی که برای اولین بار آن را روشن می کنید، معمولاً نباید بترسید - به احتمال زیاد روشن نمی شود، زیرا احتمالاً فراموش کرده اید که قطعاتی را که پاهای آنها در طراحی مخلوط شده است را دوباره لحیم کنید. :

و چند سیم را لحیم کنید:

چسب داغ همه چیز ما است، بهترین دوست یک توسعه دهنده، تقریباً مانند نوار چسب در زندگی روزمره.
درست بعد از درمل:

و چکش هایی که باید قلاب ها را به تخته بکوبند همیشه منظم بیرون نمی آیند.

گاهی لازم است برای بیمار رادیوگرافی یا توموگرافی انجام شود. به نظر می رسد این است:

به نظر می رسد که اسکن فیلم خیلی آسان نیست. با گوشی جلوی پنجره فیلم گرفته شده است.

به طور خاص، هیچ چیز در این تصویر قابل مشاهده نیست - همتا نکنید. ولی به طور کلی در ایکس ری می توان عدم لحیم کاری، ترک و این جور چیزها را دید.

به طور جداگانه، شایان ذکر است که به بالا آمدن مادربردها اشاره می شود، زیرا به طور متفاوت انجام می شود. نمونه های مادر DFT معمولاً زیاد سفارش داده می شوند - حدود 20 قطعه. گران است، بنابراین یک استراتژی در اینجا وجود دارد.

توسعه دهندگان گرفته می شوند و به کارخانه فرستاده می شوند. حدود 5 تخته مونتاژ می شود و نوار نقاله متوقف می شود. سپس توسعه دهندگان حدود 30 دقیقه فرصت دارند تا برد را روشن کنند (برای سیستم های x86، معیار موفقیت بارگذاری بایوس است). اگر همه خوش شانس باشند، بقیه نمونه ها جمع آوری می شوند. در غیر این صورت، تولید لغو می شود و توسعه دهندگان به خانه می روند تا فکر کنند. پولی که برای PCB خرج می شود از بین می رود، اما قطعات در انبار منتظر تلاش بعدی هستند.

بسیار خوب - ما هیئت مدیره خود را راه اندازی کرده ایم، و حتی سایرین را راه اندازی کرده ایم که باید با آن کار کنند. بعدش چی؟ غرفه را جمع می کنیم.
و بعد احتمالاً انتظار دارید این را ببینید؟

همه اینها برای معاونان وزیر است. یک پایه واقعی باید از چوب و بلوط مونتاژ شود و به شکل زیر باشد:

- نگفتم آسونه نئو فقط گفتم حقیقته.
(یک لیوان برای وزنه تعادل، یک قلم نمدی - به طوری که رادیاتور محکم بنشیند - در آنجا با سیم پیچ می شود)

این گروه ترکان در حال ازدحام در آزمایشگاه هستند:

و همه شروع به دوختن سفت‌افزار، برنامه‌های خود می‌کنند و با اسیلوسکوپ به همه جا می‌زنند.
گاهی اوقات در این فرآیند یک درخواست مودبانه وجود دارد "همکار عزیز لطفا آهن لحیم کاری را از دست من بردارید - خیلی گرم است" یا "خیلی مهربان باشید - وقتی برد را به شاسی پیچ می کنم دوباره منبع تغذیه را روشن نکنید."

در مورد خاص ما، هدف اصلی از بررسی سازگاری چندین دستگاه این است که بفهمیم آیا PCI Express کار می کند یا خیر، آیا با استاندارد مطابقت دارد یا خیر. شما اساساً می توانید بدون هر چیز دیگری زندگی کنید. معمولاً عملکردی که در قطعه آهن گذاشته می شود اضافی است. تن‌ها پین GPIO، اتوبوس‌های I2C/SPI، حسگرهای حرارتی، یخ‌ها و موارد دیگر، به عنوان یک قاعده، بدون ادعا باقی می‌مانند، زیرا اشکال‌زدایی آنها به آخرین لحظه‌ای که هرگز فرا نمی‌رسد موکول می‌شود.

به طور طبیعی، ما تجهیزات اندازه گیری به ارزش چندین میلیون روبل برای هر مناسبت زندگی نداریم - این برای وامپ است. نرم افزار تست سازندگان قطعات برای کمک به ما عجله دارد. تقریباً تمام تراشه های مدرن با رابط های پرسرعت دارای یک اسیلوسکوپ دیجیتال در داخل هستند. متکی به نرم افزار تخصصی است که به شما امکان می دهد شهادت آن را بخوانید. ما شروع می کنیم و به نمودارهای چشمی نگاه می کنیم. این را می بینیم:

گاهی اوقات ما یک چشمک زدن خطرناک را می بینیم:

و گاهی اوقات ما ماهی مرکب را می گیریم:

ماهی مرکب خطرناک ترین هستند. اینها اعوجاج های غیر خطی هستند و اکولایزرهای داخلی قادر به مقابله با این موضوع نیستند. ماهی مرکب به این معنی است که جایی در کانال ارتباطی چیزی بسیار بد وجود دارد - یک via بسیار طولانی، یک افت امپدانس قابل توجه، نوعی ناهمواری در طول موج 1/4 یا 1/2 برخی از هارمونیک ها در باند مفید، و غیره مشابه.

ممکن است متوجه شوید که ماهی مرکب کمی شبیه کاری است که با سیگنال DFE دریافتی در اکولایزر گیرنده PCIe انجام می دهد. اما در این مورد، این هنوز یک ماهی مرکب است و نتیجه عملیات DFE نیست (نرم افزاری که ما استفاده می کنیم نمی تواند نتیجه عملیات DFE را نمایش دهد).

به طور جداگانه باید در مورد نرم افزار تست گفت که می تواند بسیار موذیانه نیز باشد. به عنوان مثال، برای عکسبرداری از نمودارهای چشمی، از دو نسخه از یک برنامه استفاده می کنیم - یک نسخه تصاویر را ترسیم می کند، اما مقادیر باز شدن چشم را نمی نویسد، نسخه دوم برعکس عمل می کند.

خوب، بله - اگر قصد دارید با استفاده از رابط I2C از چشم عکس بگیرید - فراموش کنید، بسیار بسیار کند خواهد بود. فقط درون باند. مشکل این است که برای حذف داخل باند، دستگاه شما باید یک پیوند PCIe کار با رایانه ای که نرم افزار آزمایشی در آن اجرا می شود داشته باشد، که زمانی که سخت افزار شما در یک اسلات استاندارد PCIe نصب نشده باشد، بسیار مشکل ساز است. و نکته خنده دار این است که قبلاً باید حداقل یک پیوند کاری در کانالی که در حال رفع اشکال هستید و دقیقاً در حالتی (gen2 / 3) که در آن نیاز دارید داشته باشید (زیرا در حالت های مختلف چشم های مختلف وجود دارد و اکولایزرها متفاوت عمل می کنند. ). بدون پا، بدون لینک کارتون، بدون چشم - این طوری می خواهید، و بیرون بروید.

درباره نحوه خروج از PCIe - قبلاً جداگانه نوشتم.

به طور کلی، در هنگام توسعه یک سرور، البته پشتیبانی از سوی سازندگان اجزای مورد استفاده بسیار مهم است، زیرا امروزه پیچیدگی تراشه‌های حتی نسبتا ساده به حدی است که امکان بررسی کامل و رفع اشکال سیستم وجود ندارد. بدون استفاده از چیزهای آزمایشی ساخته شده در آنها. ژنراتورهای ساعت، رگولاتورهای ولتاژ، کنترل‌کننده‌های شبکه، سوئیچ‌های PCI Express، درایورهای مجدد - همه اینها دارای ابزارهای داخلی برای پیکربندی، عیب‌یابی هستند و به مجموعه خاصی از برنامه‌ها و کابل‌ها برای اتصال برای پیکربندی و آزمایش کامل نیاز دارند، که بدون آن توسعه به سادگی غیرممکن می‌شود. .

در روند انجام بازرسی، گاهی اوقات معلوم می شود که جایی مشکلی دارد. و سپس فرآیند هیجان انگیز بومی سازی خطا آغاز می شود تا بتوان آن را در ویرایش بعدی برطرف کرد. و خوب است اگر این "نه" به طور مداوم تکرار شود - پس به طور معمول پیدا کردن اینکه دقیقاً علت خطا چیست دشوار نیست. اما گاهی اوقات اوضاع خیلی بدتر است. به عنوان مثال، در برخی از نمونه‌های تخته‌ها، در طول یک دوره آزمایشی طولانی، خطاهای منفرد غیرقابل اصلاح روی اتوبوس رخ می‌دهد (که اصلاً نباید باشد). و در اینجا اغلب لازم است از روش "نگاه نزدیک تر" استفاده شود - یعنی فقط بنشینید، به طور فرضی به مدار نگاه کنید، حدس بزنید دقیقاً دلیل آن چیست، سعی کنید این دلیل فرضی را در مدار از بین ببرید و از قبل بررسی کنید تست می کند که آیا ما درست حدس زدیم یا نه.

ما چند سال پیش با این مشکل مواجه شدیم، زمانی که آزمایش‌های NVIDIA (بله، بسیاری از تولیدکنندگان مجموعه‌های آزمایشی خاصی را ارائه می‌کنند که به شما امکان می‌دهد مواردی را که از نظر برنامه‌نویسی در دسترس نیستند با استفاده از ابزارهای استاندارد بررسی کنید) خطاهای منفرد نادری را در طول اجراهای طولانی (روزانه یا بیشتر) روی برخی از بردها نشان داد. . . سپس معلوم شد که همه چیز ردیابی ناموفق ساعت مرجع (100 مگاهرتز) است - اگرچه قبل از اینکه به این موضوع برسیم، چیزهای زیادی بررسی شد، از کیفیت منبع تغذیه شروع شده و با نمودارهای چشمی برای همه تمام می شود. خطوط

و اتفاقاً خوب است. بزرگترین کابوس یک توسعه دهنده زمانی است که همه چیز به یکباره کار می کند. این فقط یک چیز است - یک معدن در جایی دفن شده است که پس از ارسال 100500 قطعه تجهیزات به مشتری کار می کند. واقعیت این است که در فرآیند جستجوی علت برخی از مشکلات جهانی، چندین فرضیه آزمایش می شود و به عنوان یک قاعده، بسیاری از نقص های کوچک آشکار می شود که به مشکلی که به وجود آمده مربوط نمی شود. هیچ مشکل بزرگی وجود ندارد - شما موارد کوچک را پیدا نخواهید کرد. مشتریان شما آنها را برای شما پیدا خواهند کرد.

بررسی لیست

- تمام کاری که می کنم این است که او به من می گوید.

پس از اتمام تست های مؤلفه، آزمایش عملکردی آغاز می شود - بررسی عملکرد مجموعه به عنوان یک کل و عملکرد صحیح همه عملکردهای داخلی. این معمولا توسط QA انجام می شود. دامنه خلاقیت در اینجا، البته، بسیار گسترده است، اما به طور کلی، تأکید اصلی بر عملکرد صحیح سیستم هنگام اجرای سناریوهای استفاده استاندارد است. در اینجا، خطاهای شناسایی شده ممکن است از قبل هم ماهیت سخت افزاری و هم نرم افزاری داشته باشند، بنابراین مهم است که در وهله اول متوجه شوید دقیقاً چه چیزی باعث خطا شده است. اغلب، اولین فرضیات می تواند گمراه کننده باشد، یعنی یک مشکل سخت افزاری واضح در نگاه اول می تواند ناشی از عملکرد نادرست سیستم عامل باشد. بخش قابل توجهی از تست عملکردی بررسی نحوه برخورد سیستم با خطاهای مختلفی است که ممکن است در حین کار رخ دهد. ابزارهای مدرن اشکال زدایی به شما این امکان را می دهند که خطاها را به طور مصنوعی به رابط های استاندارد پردازنده تزریق کنید، زیرا در سطح سخت افزار ایجاد بسیاری از آنها به طور عمدی کاملاً مشکل است (خوب، تراشه های حافظه را در لحظه پاره نکنید یا خطوط اتوبوس PCI Express را کوتاه نکنید) .

آه… من نگفتم که تست عملکردی به معنای یک سیستم مونتاژ شده و آماده برای مبارزه نیست. در اینجا نیز همه چیز به آرامی پیش نمی رود. در برخی موارد، معلوم شد که ما کابل های OcuLink با طول مورد نیاز را در انبار نداریم، و سرور به نظر می رسد جرات دارد.

و به دلایلی، در چنین پیکربندی، در طول آزمایش بار، همه چیز شروع به گرم شدن بیش از حد کرد. ما هنوز در تعجب هستیم که چرا. کابل ها داغ شدند، حدس می زنم.

آیا می توانید در هر دست دو هندوانه حمل کنید؟

- تو "سریع تر از این هستی. فکر نکن که هستی، بدان که هستی...

در برخی موارد، به موازات آزمایش عملکرد، آزمایش بار شروع می شود - مهم است که مطمئن شوید که سرور به درستی در حالت های عملیاتی شدید ادامه می دهد. علاوه بر این، آزمایش‌های بار هم در رابطه با زیرسیستم‌های فردی (دیسک‌ها، حافظه، پردازنده‌ها، I/O) و در کل سیستم انجام می‌شود. به عنوان یک قاعده، آزمایش های محلی به شما امکان می دهند یک ماژول خاص را بیشتر از آنچه که می توان با حداکثر بار روی کل سیستم انجام داد، بارگذاری کنید.

علاوه بر این، ابزارهای اشکال زدایی سازنده پلتفرم سخت افزاری (به عنوان مثال، Hardware Tests Executive از IBM) در اینجا کمک می کند. بنابراین، می‌توان پردازنده را به حالت‌های کاملاً محدود هدایت کرد که اساساً هنگام اجرای برنامه‌های واقعی غیرقابل دستیابی هستند. مشکلات اصلی شناسایی شده در طول آزمایش بار عبارتند از گرمای بیش از حد، بی ثباتی منبع تغذیه یا حداکثر اضافه بار جریان، خطاها در حین کار فعال با رابط های ورودی / خروجی.

معیارها نیز به کمک می آیند. زیرا زمانی که مقادیر واقعی معیارها با مقادیر پیش‌بینی‌شده بسیار متفاوت است، مشکلی پیش آمده است. یک دلیل خوب برای اینکه تخته را با چوب فشار دهید.

در مرحله آزمایش، ما عمدتاً از میکروبنچمارک ها استفاده می کنیم:
برای پردازنده ها، اینها معمولاً بارهای تک رشته ای هستند، مانند spec2006(الان در حال حاضر speccpu2017), پارسک، اما به طور کلی تعداد زیادی از آنها از مونتاژ هسته لینوکس و فشرده سازی وجود دارد ( lzma, gzipقبل از ضرب ماتریس ها و محاسبه تبدیل فوریه سریع ( fftw).
برای چندین سال، هیچ چیز برای حافظه تغییر نکرده است: جریان,RAMspeed SMP, lmbench.

برای دیسک ها: فیو, یوزون.

اگر تمام تست های عملکردی و بارگذاری با موفقیت پشت سر گذاشته شوند، هنوز تعدادی چیز وجود دارد که باید بررسی شوند - پایداری عملکرد در کل محدوده دما، مقاومت در برابر لرزش، بررسی سازگاری با مجموعه خاصی از اجزای استاندارد (حافظه، دیسک، کنترلرهای PCI Express).

P.S.: پس از اینکه همه چیز را بررسی کردیم و از آزمایش های عملکردی اولین ویرایش سرور خوشحال شدیم، سه سرور به طور ناگهانی در آزمایشگاه ما فرو ریخت. ما شروع به بررسی منبع تغذیه کردیم و در خط 1.2 ولت (منبع تغذیه گذرگاه PCIe پردازنده ها) این را دیدیم:

من توجه شما را متمرکز می کنم - یک سلول 500 میلی ولت. مقدار اسمی 1.2 ولت است. مقاومت در مدار جبران یکی از VRM ها اشتباه شده است. با چنین منبع تغذیه، تمام تست های بار، معیارها، برشته کردن و سایر موارد مشابه با موفقیت پشت سر گذاشته شد و طراحی با خوشحالی به ویرایش دوم رفت.
بنابراین، هنگامی که یک صفحه نمایش مرگ به طور ناگهانی بر روی رایانه دنج خانگی شما از یک برند معروف ظاهر می شود، نباید فکر کنید که این مطمئناً "باگ ویندوز" است.

فناوری های مجازی سازی در حال حاضر در بسیاری از حوزه های فناوری اطلاعات، هم در محیط تولید و هم توسط علاقه مندان و کاربران خانگی برای کارهای مختلف استفاده می شود. چندین سیستم مجازی در حال اجرا به طور همزمان بر روی یک ماشین فیزیکی به طور قابل توجهی انعطاف پذیری زیرساخت فناوری اطلاعات را افزایش می دهد و کارایی استفاده از منابع سخت افزاری را افزایش می دهد. تست نرم افزار یکی از رایج ترین موارد استفاده برای پلتفرم های مجازی سازی است. جای تعجب نیست که ماشین های مجازی ویژگی های مفید زیادی دارند که زمان توسعه و آزمایش را به میزان قابل توجهی کاهش داده و کارایی این فرآیندها را افزایش می دهد.

در مدل کلاسیک توسعه نرم‌افزار، برنامه‌نویسان و مهندسان کیفیت نرم‌افزار در اکثر مواقع مجبور بودند یک محصول نرم‌افزاری را تقریباً در کل زمان توسعه روی یک پلتفرم آزمایش کنند و فقط در پایان آن را در سیستم‌عامل‌های مختلف و محیط‌های کاربری آزمایش کنند. به نام تست پیکربندی، تست تنظیمات). علاوه بر این، تعداد زیادی کامپیوتر فیزیکی در اختیار بخش‌های آزمایش و توسعه وجود نداشت و بر روی یک دستگاه، در یک سیستم عامل، نصب چندین نسخه از یک محصول نرم‌افزاری به طور همزمان غیرممکن است. که برنامه توسعه یافته باید در تعامل باشد. در نتیجه، در نرم افزار، به ویژه تیم های توسعه کوچک، اغلب خطاهای مربوط به ویژگی های پیکربندی کاربر وجود داشت، زیرا زمان و منابع کافی برای آزمایش پیکربندی کامل وجود نداشت. علاوه بر این، مهندسان با کیفیت مجبور بودند زمان زیادی را صرف استقرار مجموعه ای از محصولات نرم افزاری بر روی میزهای آزمایش و پیکربندی کار خود در زیرساخت شبکه کنند.

البته یکی از جدی ترین مشکلات در توسعه نرم افزار این است که در مراحل اولیه توسعه، مونتاژ یک محصول نرم افزاری در حین کار می تواند آسیب های جبران ناپذیری به سیستم وارد کند (مثلاً درایورهای مختلف دستگاه). بنابراین باید برنامه ریزی برای بازیابی سیستم عامل ها و تنظیمات آنها پس از خرابی از نسخه پشتیبان تهیه و زمان قابل توجهی را برای بازیابی آنها صرف کرد.

لازم به ذکر است که مشکل دیگری نیز وجود دارد که در توسعه نرم افزار بسیار رایج است و نیاز به صرف زمان قابل توجهی برای حل آن دارد. همه برنامه نویسانی که تجربه تعامل با تیم های تست را دارند وضعیت زیر را می دانند: در سیستم ردیابی اشکال، تستر نقصی را برطرف می کند که برنامه نویس به هیچ وجه نمی تواند آن را تکرار کند. پس از اینکه برنامه نویس وضعیت مشکل را حل شده تنظیم کرد، تستر او را به دستگاه خود فرا می خواند و به صورت بصری خطا را نشان می دهد. در این شرایط کار به جایی می رسد که برنامه نویس مجبور است تعداد زیادی دیباگر و مزخرفات غیرضروری دیگر را روی دستگاه تستر نصب کند و عیب را "گیر" کند و کار تستر را به طور کامل متوقف کند. اگر زمان حذف ابزارهای برنامه نویسی توسط تستر را به این اضافه کنیم، وقت تیم را از دست خواهیم داد.

علاوه بر این، ویژگی های کار برخی از محصولات نرم افزاری مستلزم بررسی کار آنها در شرایط خاص (میزان مختلف رم، پهنای باند کانال ارتباطی، فرکانس پردازنده و غیره) است. در این حالت، تیم آزمایش ممکن است پیکربندی سخت افزاری مورد نیاز را در اختیار نداشته باشد (اگر به ده هارد دیسک نیاز داشته باشیم چه می شود؟). هنگام تعیین نیازهای سیستم یک محصول برای چنین عواملی، این نیاز می تواند حیاتی باشد.

در خاتمه برشمردن لیستی از مشکلاتی که در فرآیند توسعه و آزمایش به وجود می آیند، باید یک مورد دیگر ارائه شود. اغلب چنین وضعیتی وجود دارد که لازم است مونتاژ یک محصول نرم افزاری "برای دود" بررسی شود (به اصطلاح تست دود، تست دود)، که به معنای اجرای سریع مهم ترین آزمایش ها است. اما اگر در حال توسعه اپلیکیشنی باشیم که به نسخه های مختلف اینترنت اکسپلورر نیاز دارد، چه؟ در این صورت زمان زیادی برای بارگذاری سیستم مناسب که نسخه مورد نیاز در آن نصب شده است صرف می شود.

با خلاصه کردن شرایط توصیف شده، اجازه دهید مشکلاتی را که اغلب در فرآیند توسعه و آزمایش محصولات نرم افزاری با آن مواجه می شوند، خلاصه کنیم:

• نیاز به آزمایش نرم افزار در پیکربندی های کاربر بیشتر از آنچه برای آزمایش رایانه های فیزیکی موجود است
• هزینه های زمانی زیادی برای استقرار و پیکربندی میزهای آزمایشی حاوی اجزای مختلف بسیار زیاد که تعامل شبکه بین آنها فراهم می شود.
• هزینه های زمان زیادی برای ایجاد نسخه های پشتیبان از سیستم ها و تنظیمات آنها و همچنین بازیابی پس از خرابی به دلیل عملکرد ناپایدار مجموعه های محصول نرم افزاری
• عدم توانایی بازتولید نقص یافت شده توسط آزمایشگر در دستگاه توسعه دهنده و از دست دادن زمان برای یافتن آن، رفع آن
• نیاز به آزمایش برنامه در یک محیط سخت افزاری که در دسترس تیم آزمایش نیست
• نیاز به آزمایش یک محصول نرم افزاری در شرایطی که نیاز به جابجایی سریع بین تنظیمات کاربر دارد

اگر محاسبه کنید که چقدر زمان و منابع برای حل این مشکلات صرف می شود، رقم بسیار بسیار چشمگیری به دست می آورید که وقتی به صورت پولی بیان شود، بخش نسبتاً زیادی از بودجه پروژه را تشکیل می دهد.

فناوری های مجازی سازی که به درستی در فرآیند توسعه و آزمایش به کار می روند، می توانند هزینه های نیروی کار را به میزان قابل توجهی کاهش دهند و کارایی فرآیند را به میزان قابل توجهی افزایش دهند که بر کیفیت محصول نرم افزاری منتشر شده تأثیر مثبت خواهد گذاشت. بنابراین به طور خاص مجازی سازی به شما این امکان را می دهد که این کار را انجام دهید:

• آزمایش‌کنندگان در فرآیند کار با ماشین‌های مجازی می‌توانند تعداد نامحدودی پیکربندی کاربر را روی ماشین فیزیکی خود ایجاد کنند و در صورت لزوم، مناسب‌ترین مورد را در حال حاضر راه‌اندازی کنند.
• پس از ایجاد، پیکربندی های چند ماشینی را می توان با استفاده از ابزارهای پلتفرم مجازی سازی پیکربندی کرد و به سادگی به سخت افزارهای دیگر منتقل شد، بدون نیاز به پیکربندی مجدد آنها
• یک ماشین مجازی را می توان با کپی کردن یک پوشه یا ایجاد یک عکس فوری از وضعیت ("عکس فوری") پشتیبان گیری کرد.
• پس از یافتن یک باگ توسط یک تستر، یک ماشین مجازی با یک نقص تکرار شونده می تواند به یک توسعه دهنده منتقل شود، در حالی که منابع برای آزمایش بیشتر آزاد می شود.
• به دلیل پیکربندی انعطاف پذیر پارامترهای محیط سخت افزار ماشین مجازی (مقدار RAM، تعداد پردازنده های مجازی، محدودیت منابع) می توان به سرعت شرایط لازم برای آزمایش را ایجاد کرد.
• توانایی بازگشت سریع به حالت ذخیره شده یک ماشین مجازی با پیکربندی لازم یا جابجایی بین چندین سیستم مهمان که به طور همزمان در حال اجرا هستند، زمان تست را کاهش می دهد.

همه راه حل های فوق را باید در پرتو این واقعیت در نظر گرفت که یک ماشین مجازی با نرم افزار نصب شده در آن یک شی بسیار انعطاف پذیر است که هم می تواند به سرعت بر روی ماشین های مشتری از یک مخزن متمرکز قالب های پیکربندی کاربر مستقر شود و هم به صورت انعطاف پذیر پیکربندی شود. تا حد امکان در رابطه با تنظیمات مهمان سیستم و محیط آن. قابلیت حمل آسان به سایر سخت افزارها و استقلال از پلتفرم سخت افزاری یکی از مزیت های کلیدی ماشین های مجازی است.

ماشین ابزار مجازی برای آزمایش و توسعه

هنگام پیاده‌سازی زیرساخت مجازی برای اهداف توسعه و آزمایش نرم‌افزار، ابتدا باید مناسب‌ترین، مطمئن‌ترین و کارآمدترین بستر مجازی‌سازی را انتخاب کرد که تمامی الزامات فرآیند توسعه در یک سازمان را برآورده کند. دو روش رایج برای استفاده از ماشین های مجازی برای آزمایش محصولات نرم افزاری وجود دارد:

• استقرار مدیریت نشده ماشین‌های مجازی روی ماشین‌های مشتری یا سرورهای آزمایشی، که در آن آزمایش‌کننده‌ها یا پیکربندی‌های مورد نیاز خود را ایجاد می‌کنند یا الگوهای سیستم مجازی را از یک کتابخانه مرکزی قالب‌های مجازی (سرور فایل) روی رایانه‌های خود کپی می‌کنند. مزیت این روش ارزان بودن راه حل است، شما می توانید از یکی از بسیاری از سیستم های مجازی سازی رایگان (VMware Server، Virtual PC، VirtualBox و غیره) استفاده کنید. معایب اصلی - استقرار خود به خود ماشین های مجازی باعث ایجاد تضاد در زیرساخت شبکه، عدم کنترل استفاده از مجوزها برای سیستم عامل ها و نرم افزارهای کاربردی، ناتوانی در ادغام با محیط IT موجود سازمان می شود.
• استقرار مدیریت شده سیستم های مجازی از کتابخانه های متمرکز قالب های مجازی، با کنترل کامل بر استفاده از ماشین های مجازی در زیرساخت فناوری اطلاعات شرکت. از مزایای این رویکرد می توان به توانایی حل تضاد بین سیستم های مجازی و فیزیکی در شبکه، کنترل استفاده از مجوزها، امکان نظارت بر استفاده از زیرساخت های مجازی و ایجاد فضای مشترک بین شرکت کنندگان مختلف در فرآیند توسعه و آزمایش، اشاره کرد. ادغام در زیرساخت واقعی IT شرکت. عیب اصلی این روش هزینه بالای راه حل ها است. نمونه هایی از محصولاتی که استقرار مدیریت شده ماشین های مجازی را ارائه می دهند: VMware LabManager، VMLogix LabManager، Microsoft System Center Virtual Machine Manager.

پلتفرم‌های مجازی‌سازی که اکنون تعداد زیادی از آنها در بازار وجود دارد، با سرعتی سریع در حال توسعه هستند و مجموعه‌ای از ابزارها را برای بهبود کارایی فرآیند توسعه و آزمایش در اختیار کاربران قرار می‌دهند. برای حل هر یک از این مشکلات، پلتفرم های مجازی سازی فروشندگان مختلف ابزارهای خاص خود را دارند که به کاربران اجازه می دهد محصولات نرم افزاری را به طور موثر در ماشین های مجازی آزمایش کنند.

1. ایجاد بسیاری از تنظیمات سفارشی

   اگر فضای دیسک آزاد زیادی در دستگاه تستر وجود داشته باشد، با استفاده از پلتفرم مجازی سازی، می توانید تعداد نامحدودی سیستم مجازی ایجاد کنید که هر کدام می توانند در صورت تقاضا بوت شوند، بدون اینکه فعالیت کاری کارگر در سیستم میزبان متوقف شود. ماشین های مجازی همچنین می توانند بر روی سرورهای تست تخصصی مبتنی بر پلتفرم های VMware ESX Server، XenEnterprise یا Virtual Iron استفاده شوند. در عین حال می توان حقوق خاصی را به کاربران سیستم های مجازی اختصاص داد و همچنین منابع فیزیکی سرور قابل استفاده توسط یک کاربر خاص محدود است. یک سرور فایل با قالب های مجازی می تواند ماشین های مجازی از پیش نصب شده را که برای آزمایش سرورها یا ایستگاه های کاری مستقر شده اند، ذخیره کند. در این مورد، شما باید ویژگی های استفاده از ماشین های مجازی را مطابق با مجوز در نظر بگیرید. در بیشتر موارد، هر ماشین مجازی به مجوز جداگانه نیاز دارد، اما استثناهایی وجود دارد: به عنوان مثال، مجوز Windows Server 2003 Datacenter Edition به شما امکان می دهد تعداد نامحدودی از نمونه های سیستم عامل مجازی را اجرا کنید.

   اگر محیط آزمایشی پیکربندی شده قبلاً روی یک ماشین فیزیکی مستقر شده باشد، می توان آن را با استفاده از محصولات فروشندگان پلت فرم مجازی سازی و توسعه دهندگان شخص ثالث به یک محیط مجازی منتقل کرد. چنین راهکارهایی عبارتند از PlateSpin PowerConvert، VMware Converter، Microsoft Migration Toolkit.

2. ایجاد تنظیمات چند ماشینی روی یک سرور فیزیکی.

   پلتفرم‌های مجازی‌سازی متمرکز بر تست نرم‌افزار (VMware Workstation، Virtual PC، VirtualBox، Xen) به شما امکان می‌دهند کل زیرساخت‌های مجازی را با انواع مختلف شبکه در یک میزبان فیزیکی ایجاد کنید. به عنوان مثال، می‌توانید چندین «بلوک» از سرورهای مجازی (سرور پایگاه داده، سرور برنامه، محیط کلاینت) ایجاد کنید، آداپتورهای شبکه ماشین مجازی را پیکربندی کنید (یک دستگاه می‌تواند چندین، حداکثر ده تا در VMware Workstation داشته باشد)، و یک دسته آزمایش‌شده را اجرا کنید. سرورها در عین حال، پلتفرم های مجازی سازی به شما امکان می دهند آداپتورهای شبکه ماشین مجازی را به بخش های مختلف شبکه مجازی متصل کنید.
   

   پس از ایجاد زیرساخت مجازی آزمایشی، می توانید پارامترهای کانال های ارتباطی بین ماشین های مجازی را پیکربندی کنید.
   

   لازم به ذکر است که شبکه های مجازی در تمامی پلتفرم های مجازی سازی قابل حمل نیستند و گاهی اوقات هنگام انتقال ماشین های مجازی به سخت افزارهای دیگر نیاز به پیکربندی مجدد دارند.

3. پشتیبان گیری از ماشین های مجازی در حین تست

   اگر آزمایش‌کننده‌ها از ماشین‌های مجازی در ایستگاه‌های کاری خود استفاده می‌کنند، می‌توانند با کپی کردن پوشه فایل‌های ماشین مجازی از آنها نسخه پشتیبان تهیه کنند. در صورت خرابی سیستم، نسخه ذخیره شده نیازی به بازیابی ندارد - از قبل برای استفاده کاملاً آماده است. علاوه بر این، بسیاری از پلتفرم‌های مجازی‌سازی به شما امکان می‌دهند چندین عکس فوری از وضعیت یک ماشین مجازی ایجاد کنید، که هر کدام را می‌توانید در چند دقیقه به عقب برگردانید.

   اگر آزمایش روی سرورهای آزمایشی اختصاصی انجام شود، می‌توان از فروشندگان ماشین مجازی مانند vRanger Pro از Vizioncore، VMware Consolidated Backup (VCB) یا Microsoft Data Protection Manager برای Virtual Server 2005 که هنوز منتشر نشده است، برای پشتیبان‌گیری مجازی استفاده کرد. ماشین‌های R2، که به شما امکان می‌دهد بدون توقف از ماشین‌های مجازی پشتیبان‌گیری کنید.

4. نشان دادن نقص به توسعه دهندگان.

   هنگامی که یک نقص پیدا شد، آزمایشگر به سادگی می تواند وضعیت سیستم را که در آن خطا رخ می دهد در یک عکس فوری ذخیره کند و به آزمایش سیستم ادامه دهد. در صورت نیاز به نشان دادن نقص، ماشین مجازی می تواند به توسعه دهنده ای منتقل شود که می تواند بدون ترس از آسیب رساندن به محیط تستر با آن کار کند. علاوه بر این، در پلت فرم VMware Workstation، ماشین های مجازی می توانند به عنوان سرور VNC بدون نیاز به نصب نرم افزار اضافی برای دسترسی از راه دور دسکتاپ عمل کنند.
   

5. پیکربندی انعطاف پذیر محیط سخت افزاری

   اغلب، هنگام تست نرم افزار، به انعطاف پذیری بیشتری از نظر پیکربندی اجزای سخت افزاری نیاز دارید. به عنوان مثال، در هنگام تست استرس (Stress Testing) لازم است عملکرد یک محصول نرم افزاری در شرایط شدید یا محدود (کمبود فضای دیسک، خرابی اتصال به شبکه) بررسی شود. در این صورت، با استفاده از بستر مجازی سازی برای ماشین مجازی، می توانید دستگاه های مجازی جدید اضافه کنید یا منابع اختصاص داده شده به آن را محدود کنید.

   در عین حال، اگر یک دیسک مجازی را در سیستم مهمان اضافه کنیم، می‌توانیم آن را به صورت پویا در حال گسترش ایجاد کنیم که به ما امکان می‌دهد فضای خالی دیسک را ذخیره کنیم و همچنین دیسک‌هایی به اصطلاح Undo ایجاد کنیم که تغییرات آن فقط در حین کار معتبر است. با ماشین مجازی و پس از خاتمه می توان جلسه را لغو کرد که برای تست بسیار راحت است.
   

   از نظر کنترل منابع، بسیاری از پلتفرم های مجازی سازی به شما این امکان را می دهند که منابع یک ماشین مجازی یا مجموعه ای از منابع ماشین مجازی را محدود کنید، که به شما امکان می دهد شرایط واقعی محیط های کاربر را شبیه سازی کنید.

   پلتفرم های مجازی سازی مدرن از استاندارد USB 2.0، تعداد زیادی آداپتور شبکه مجازی در ماشین مجازی، شبیه سازی دیسک های SCSI و نمایش تعداد متفاوتی از پردازنده ها در یک سیستم مهمان از طریق SMP مجازی (Symmetric Multi Processing) پشتیبانی می کنند.

6. با چندین سیستم مجازی به طور همزمان کار کنید.

   این ویژگی به آزمایش‌کنندگان اجازه می‌دهد نه تنها از نمونه‌هایی از سیستم‌های مهمان مختلف هنگام آزمایش استفاده کنند، بلکه به راحتی فایل‌ها را هم بین سیستم عامل میزبان و مهمان و هم بین سیستم‌عامل مهمان با استفاده از مکانیزم Drag&Drop مبادله کنند. در عین حال، برخی از پلتفرم‌های مجازی‌سازی به شما امکان می‌دهند به راحتی فایل‌ها را از طریق پوشه‌های اشتراک‌گذاری شده سیستم میزبان (پوشه‌های اشتراک‌گذاری شده) یا فایل‌های «کشیدن و رها کردن» بین سیستم‌های مهمان (VMware Workstation) مبادله کنید.

   بسیاری از پلتفرم‌های مجازی‌سازی به شما اجازه می‌دهند از یک کلیپ‌بورد مشترک با سیستم میزبان استفاده کنید، که به‌ویژه کپی کردن پیام‌های خطای برنامه در سیستم ردیابی اشکال را بسیار ساده‌تر می‌کند.

ابزارهای توسعه و آزمایش برای استقرار مدیریت نشده

اساس استقرار مدیریت شده ماشین های مجازی راه حل های تخصصی برای ایجاد و نگهداری آزمایشگاه های آزمایش مجازی (Virtual Labs) است که در آن کنترل بر استفاده از سیستم های مجازی توسط گروه های مختلف کاربر، استقرار خودکار ماشین های مجازی به کامپیوترهای پروژه اعمال می شود. مشارکت کنندگان و ایجاد یک محیط کاری مشترک. این راه حل ها بسیار گران هستند (به عنوان مثال، زیرساخت VMware LabManager حداقل 15000 دلار هزینه خواهد داشت)، اما آنها خود را در مقیاس بزرگ توجیه می کنند. شرکت های بزرگی مانند Dell از ماشین های مجازی در آزمایشگاه های مجازی برای آزمایش محصولات نرم افزاری استفاده گسترده ای می کنند. این سیستم‌ها از SAN استفاده می‌کنند، جایی که یک کتابخانه مشترک از قالب‌های مجازی میزبان قالب‌های ماشین مجازی است که بر اساس تقاضا بر روی سرورهای آزمایشی رایگان مبتنی بر پلت‌فرم‌های مجازی‌سازی مستقر می‌شوند. استفاده از آزمایشگاه های مجازی مزایای زیر را به همراه دارد:

• کار با تنظیمات چند ماشینی به عنوان یک ماژول واحد، امکان انتشار این ماژول ها
• کاهش زمان صرف شده برای پیکربندی سیستم ها
• تمایز دسترسی به ماشین های مجازی و نشان دادن عیوب با ارسال لینک به وضعیت مشکل ذخیره شده به عنوان یک عکس فوری از وضعیت سیستم مهمان
• کتابخانه الگوی عمومی با قابلیت حل تعارض شبکه در هنگام استقرار (SID ها، اختصاص آدرس های MAC منحصر به فرد به رابط های شبکه مجازی)
• نگهداری متمرکز و استقرار به روز رسانی ها در محیط های آزمایشی
• مانیتورینگ بار سرورهای آزمایشی

در حال حاضر، محبوب ترین راه حل ها برای استقرار مدیریت شده زیرساخت آزمایش مجازی VMware LabManager (برای پلت فرم سرور ESX) و VMLogix LabManager (برای پلتفرم های Microsoft، VMware و XenSource) هستند.

آزمایشگاه های تست VMware LabManager

VMware به شرکت های بزرگ پیشنهاد می دهد تا از زیرساخت آزمایش مجازی مبتنی بر یک راه حل (توسعه سابق شرکت خریداری شده Akimbi) استفاده کنند، که به شما امکان می دهد ماشین های مجازی را به سرعت بر روی سرورهای آزمایشی مستقر کنید و استفاده از سیستم های مجازی را کنترل کنید، در حالی که فرآیند شبیه به کاربر است. با یک کامپیوتر فیزیکی کار می کند. مدل آزمایشگاه مجازی در زیر ارائه شده است:

علاوه بر تمامی مزایای فوق سیستم های مدیریت آزمایشگاه مجازی، VMware LabManager یکپارچه سازی با ابزارهای تست محبوب را فراهم می کند و توانایی استقرار قالب ها را با چند کلیک ماوس دارد، از پروتکل LDAP پشتیبانی می کند، به راحتی با سایر راه حل های زیرساخت مجازی VMware ادغام می شود و دارای توانایی خودکار کردن عملیات از طریق API خود (رابط برنامه کاربردی). ایراد اصلی این محصول قابلیت سرویس دهی به سرورهای مجازی تنها بر روی پلتفرم های VMware می باشد.

آزمایشگاه های تست VMLogix LabManager

برخلاف راه حل VMware، این محصول از پلتفرم های مجازی سازی از فروشندگان مختلف پشتیبانی می کند. پلتفرم های مایکروسافت (سرور مجازی)، Xen (XenEnterprise) و VMware (سرور و سرور ESX) می توانند به عنوان پایه آزمایشگاه آزمایش مجازی استفاده شوند. علاوه بر این، LabManager VMLogix از نگهداری سرورهای فیزیکی سازمان پشتیبانی می کند. معماری راه حل VMLogix LabManager در زیر نشان داده شده است:

LabManager یک پورتال سلف سرویس را در اختیار کاربران قرار می دهد که از طریق آن کاربران می توانند ماشین های مجازی را از یک کتابخانه متمرکز از قالب های سیستم عامل و ISO و همچنین مدیریت مجوز، تنظیمات منطقه آدرس IP و قابلیت های ممیزی امنیت زیرساخت تست مجازی مستقر کنند. علاوه بر این، VMLogix LabManager همچنین شامل اتوماسیون API، قابلیت‌های استقرار و نگهداری چند ماشینی، و ویژگی‌هایی برای نشان دادن موقعیت‌های مشکل با اشتراک‌گذاری عکس‌های فوری ماشین‌های مجازی است.

نتیجه

مدل سازماندهی فرآیند توسعه و آزمایش با استفاده از ماشین های مجازی می تواند هزینه استقرار محیط های آزمایشی کاربر و پیکربندی محیط های آزمایشی را به میزان قابل توجهی کاهش دهد. طبق آمار، هنگام تست محصولات نرم افزاری بر روی سرورهای فیزیکی و ایستگاه های کاری، این وظایف تا 50 درصد از زمان تیم آزمایش را می گیرد. ماشین‌های مجازی روی پلتفرم‌های فروشندگان مختلف می‌توانند این زمان را چندین برابر، تا 5 درصد از کل هزینه‌های تست، کاهش دهند. افزایش انعطاف پذیری سیستم های مجازی و استقلال آنها از تجهیزات به شما این امکان را می دهد که با آنها مانند بلوک های خاصی که زیرساخت آزمایش مجازی شرکت از آنها ساخته شده است، کار کنید. امکان دسترسی مشترک به عیوب یافت شده برای اعضای تیم توسعه و کاربران محصول می تواند سرعت جستجو و تصحیح خطاها را به میزان قابل توجهی افزایش دهد. در بسیاری از شرکت ها، آزمایش با ماشین های مجازی در حال حاضر به استاندارد واقعی تبدیل شده است.

با این حال، روند آزمایش بر روی سیستم‌های مجازی دارای محدودیت‌هایی است: به عنوان مثال، سیستم‌های مجازی برای تست عملکرد (Testing عملکرد)، و همچنین آزمایش برنامه‌هایی که تقاضاهای زیادی را بر روی منابع فیزیکی رایانه اعمال می‌کنند، توصیه نمی‌شوند. برای سایر انواع تست، زیرساخت تست مجازی یکی از بهترین راه حل ها برای افزایش کارایی فرآیند توسعه و همچنین ساده سازی تعامل بین اعضای تیم است.

پلتفرم های سخت افزاری

سازگاری با پلتفرم سخت افزاریبه این معنی که رایانه ها از گره ها و دستگاه هایی تشکیل شده اند که سیستم فرمان و رمزگذاری داده یکسانی دارند و بنابراین می توان آنها را تعویض کرد. اگرچه این ضروری نیست - اگر دستگاه ها از نظر مشخصات فنی بسیار متفاوت باشند، نمی توان یکی را با دیگری جایگزین کرد. اما برای پلتفرم های سخت افزاری مختلف، همه اجزاء کاملاً متفاوت و ناسازگار هستند.

برای رایانه های شخصی، اکنون تنها دو پلتفرم سخت افزاری رقابتی باقی مانده است: IBM PCو اپل مکینتاش(شکل 3) علاوه بر این، IBMPC به وضوح تسلط دارد، بیش از 90٪ از کامپیوترها متعلق به این پلت فرم هستند. زمانی اپل مکینتاش بیشتر برای گرافیک و انتشار مناسب بود، اما اکنون قابلیت‌های هر دو پلتفرم در اینجا برابر است. با این وجود،

رایانه های اپل ناپدید نمی شوند، اما همچنان مورد استفاده قرار می گیرند.
برای سرورهای با کارایی بالا، یا برعکس - تراشه های اولیه، پلتفرم های سخت افزاری دیگری نیز وجود دارد: SunMicrosystems، Compaq، HewlettPackard و غیره.

در پیکربندی سخت افزاری یک کامپیوتر، نقش مهمی ایفا می کند اصل معماری باز. این ساخت یک کامپیوتر بر اساس یک اصل مدولار است، زمانی که همه دستگاه‌های کامپیوتری یکسان دارای موارد زیر هستند:

1. پروتکل های مورد توافق (استانداردها) برای انتقال داده ها.

2. ابعاد هندسی استاندارد و اتصالات یکپارچه برای اتصال.

معماری باز اجازه می دهد ارتقا دهید(ارتقا) یعنی. به روز رسانی یک کامپیوتر به سادگی با جایگزینی یک دستگاه با دستگاه دیگر بدون تأثیر بر سایر موارد.

به جای یک دستگاه قدیمی، یک دستگاه جدید با پارامترهای بهتر قرار می دهند و آن را به همان کانکتور وصل می کنند. سیستم عامل دستگاه جدید را ثبت می کند و بهترین درایورها را برای آن تعیین می کند. اگر آنها در داخل سیستم عامل نیستند، درایورهای لازم از رسانه های خارجی یا از اینترنت گرفته می شوند. پس از آن، کامپیوتر با پارامترهایی که چندین برابر بهتر هستند شروع به کار می کند. یک روش ساده و موثر.

جایگزینی برخی از دستگاه‌های سخت‌افزاری با برخی دیگر با ویژگی‌های بهتر تا حدودی در هیچ دستگاه فنی انجام می‌شود، اما هیچ کجا به اندازه فناوری رایانه‌ای نمی‌رسد. به عنوان مثال، تصور خودرویی که در آن قطعات جدیدی از موتور و گیربکس به جای قطعات منسوخ قرار داده شده و در نتیجه قدرت خودرو چندین برابر می شود، دشوار است.

ارتقاء محدودیت‌های خود را دارد و شما نمی‌توانید آخرین‌ها را بر روی یک کامپیوتر بسیار قدیمی قرار دهید. هر از گاهی استانداردهای اتصال اساساً جدیدی ظاهر می شود ، اتوبوس های سیستم قدیمی دیگر تولید نمی شوند ، استانداردهای دستگاه های اساسی مانند مثلاً مادربرد تغییر می کند. و سپس ارتقاء بی معنی می شود، خرید یک کامپیوتر جدید آسان تر است.

پلت فرم IBMPC دارای معماری باز است، در حالی که اپل دارای معماری بسته است.

معماری باز ¾ دقیقاً همان چیزی است که به پلتفرم IBM اجازه می دهد در تولید رایانه جایگاه پیشرو داشته باشد و رقبا را در یک زمان شکست دهد. و در حال حاضر کامپیوترهای مبتنی بر پلتفرم IBM در جهان غالب هستند.

با این حال، خود IBM با معرفی یک معماری باز برای محصولات خود، مشکلات تاکتیکی را با موفقیت حل کرد، اما از نظر استراتژیک شکست خورد. دستگاه‌هایی با معماری باز برای رایانه‌های IBM توسط صدها شرکت در سراسر جهان - در آمریکا، اروپا، آسیا- ساخته شدند. هیچ منع قانونی در این مورد وجود ندارد. و معماری اتوبوس از نظر فنی باز انجام این کار را بسیار آسان می کند.

در نتیجه، آی‌بی‌ام تنها رهبر تولید فناوری رایانه نیست. این تنها به یکی از شرکت های بزرگ در پنج تولید کننده برتر تبدیل شده است.

مقدمه پس از کشف قابلیت‌های 3DMAX کارت‌های ویدئویی مدرن، نوبت به اجرای همان آزمایش‌ها برای مقایسه پلتفرم‌های سخت‌افزاری تک‌پردازنده مدرن می‌رسد.
در حال حاضر، تنها دو خانواده از پردازنده‌ها در بازار انبوه وجود دارند که می‌توان آنها را «امیدبخش» در نظر گرفت - پلتفرم‌های Socket478 و Socket462 (SocketA). من پلتفرم های "منسوخ" مبتنی بر پردازنده های Socket370 و Socket423 را در نظر نخواهم گرفت، زیرا خرید سیستم های تک پردازنده مبتنی بر این پردازنده ها برای کار در 3DMAX منطقی نیست.
البته، سیستم‌هایی که قبلاً بر اساس پردازنده‌های Socket370 مبتنی بر هسته Tualatin و حافظه نهان L2 با ظرفیت 512 کیلوبایت، و همچنین سیستم‌های مبتنی بر پردازنده‌های Socket423 قدیمی‌تر، به شما امکان می‌دهند در 3DMAX به طور سازنده کار کنید. با این حال، هزینه این سیستم‌های "منسوخ" امروزه خرید آنها را بی‌سود می‌سازد، زیرا سیستم‌های مبتنی بر این پردازنده‌ها مزیت عملکردی ندارند یا حتی نسبت به سیستم‌های مبتنی بر پردازنده‌های خانواده Socket478 و Socket462 با قیمت یکسان پایین‌تر هستند. این نتیجه سیاست اینتل برای جایگزینی خطوط پردازنده "منسوخ" با خطوط جدید و "امیدبخش" است که خود را در به روز رسانی سریعتر خطوط پردازنده "امیدبخش" و در نتیجه کاهش سریعتر قیمت برای پردازنده های این "امیدبخش" نشان می دهد. " خطوط
پربازده‌ترین چیپ‌ست‌ها برای پردازنده‌های Socket478 و Socket462، بردهایی که در حال حاضر روی آنها برای فروش موجود است، i850 و Apollo KT266A هستند. مونتاژ پلتفرم‌های مبتنی بر بردهای چیپست i845D با پشتیبانی از حافظه PC2100 DDR SDRAM منطقی نیست، زیرا حافظه PC800 RDRAM در حال حاضر قیمتی مشابه یا حتی ارزان‌تر از PC2100 DDR SDRAM دارد، در حالی که عملکرد قابل‌توجهی بالاتری را ارائه می‌دهد.

بنابراین، در این مقاله عملکرد یک سیستم مبتنی بر برد با چیپست i850 (Abit TH7II) و پردازنده‌های Pentium4 - 2.2 گیگاهرتز، 2.0 گیگاهرتز با حافظه نهان سطح دوم 512 کیلوبایت (هسته نورث وود) و پردازنده‌های Pentium4 - 2.0 را بررسی خواهیم کرد. گیگاهرتز، 1.7 گیگاهرتز با کش سطح دوم 256 کیلوبایت (هسته Willamette). اول از همه، ما علاقه مند به افزایش عملکرد هستیم که می توان با دو برابر کردن حافظه پنهان L2 به آن دست یافت. آیا افزایش در فرکانس ساعت افزایش عملکرد قابل مقایسه ای را ارائه می دهد؟
برای مقایسه با این سیستم، پلتفرمی متشکل از یک مادربرد مبتنی بر چیپست Apollo KT266A (Epox 8KHA+) و یک پردازنده AthlonXP 2000+ (سرعت کلاک واقعی 1667 مگاهرتز) را انتخاب کردم. من فقط یک پردازنده برای Socket462 گرفتم به این دلیل که AMD در روند افزایش فرکانس های کلاک پردازنده های خود بسیار عقب تر از اینتل است و فرکانس کلاک این پردازنده "بالا" حتی از فرکانس کلاک پنتیوم 4 کوچکتر است. پردازنده در نظر گرفته شده در این ماده.

شرح تنظیمات سخت افزاری

برای ارزیابی عملکرد سرعت، از همان تست هایی که در بررسی های قبلی بود استفاده کردم. یادآوری می کنم که این بنچمارک ها برای تست در 3D Studio MAX توسط خود سازنده برنامه توصیه می شود.
با شروع این مقاله، من از آزمایش با فعال کردن آنتی آلیاسینگ خودداری کردم، زیرا همه کارت‌های ویدئویی مدرن بدون کاهش عملکرد، ضدآلیاسینگ را انجام می‌دهند.

پلتفرم شماره 1:

پردازنده – 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).
مادربرد - Abit TH7II (i850)
حافظه - 1024 مگابایت PC800 RDRAM

پلتفرم شماره 2:

پردازنده - AthlonXP 2000+ (1667 مگاهرتز)
مادربرد - Epox 8KHA+ (Apollo KT266A)
حافظه – 1024 مگابایت PC2100 SDRAM
کارت گرافیک - NVIDIA GeForce4 Ti4600 (نسخه چاشنی 27.51)
هارد دیسک - 20 گیگابایت IBM DTLA 7200 دور در دقیقه

نرم افزار:

ویندوز 2000 SP2
3ds max 4.26 (رندر OpenGL)، 1280x1024 32bit

تست ویژگی های سرعت هنگام کار در پنجره های پروجکشن

1 . اولین معیار یک "آزمون استرس" است - انیمیشن صحنه در چهار پنجره نمایش داده می شود. با این حال، روش رندر متفاوت است. در دو پنجره بالا، صحنه به صورت "Wireframe" (یعنی در حالت "wire" یا "wireframe")، در سمت چپ پایین "Smooth + Highlights" + "Edged Faces" (در حالت سایه دار با لبه های انتخاب شده) نمایش داده می شود. )، در پایین سمت راست - "Smooth + Highlights":

این صحنه حاوی چند ضلعی بسیار کمی است - فقط 28 هزار، با این حال، به دلیل پخش همزمان انیمیشن در هر چهار پنجره، "کل" فریم در ثانیه بسیار کم است.

چند ضلعی: 28868
منابع نور: 1
حالت: Wireframe، Smooth+ Highlights

با نمایش همزمان انیمیشن در هر چهار پنجره پروجکشن، بیشتر بار روی رندر صحنه بر روی بسته حافظه CPU می افتد. همانطور که می بینیم، در این بنچمارک، پردازنده AMD به خوبی کار می کند و امتیاز آن را تایید می کند. سود حاصل از افزایش حافظه نهان سطح دوم در پردازنده های اینتل بسیار ناچیز است و تقریباً 5 درصد است.

2 . معیار دوم، صحنه ای با هفت شی هندسی اساسی، با پیچیدگی کلی ده هزار چند ضلعی است.

شش شی ایستا هستند، یکی به آرامی در اطراف صحنه حرکت می کند و از اجسام دیگر "گذر می کند". این معیار صحت نمایش "تقاطع" اشیاء و سرعتی که درایور و سخت افزار کارت گرافیک می توانند با آن کار کنند را بررسی می کند.

چند ضلعی: 9712
منابع نور: 1
حالت: صاف + برجسته

برخلاف قبلی، این بنچمارک، در این مورد، گذرگاه AGP را بارگذاری می کند و سرعت پورت AGP مادربرد را نشان می دهد. در صورت اجرای نادرست AGP، مقدار fps در این معیار به حدود 80-100 کاهش می یابد.
بنابراین، می بینیم که اجرای AGP در هر دو پلتفرم خوب است. با این حال، در این معیار، افزایش حافظه نهان افزایش بسیار بیشتری نسبت به قبلی ایجاد می کند - تا 20٪.

3 . صحنه معیار سوم حاوی توپی است که در پس زمینه 15000 چند ضلعی بسیار آهسته حرکت می کند.

توپ هیچ جا اجسام دیگر را قطع نمی کند. از آنجایی که توپ بسیار آهسته حرکت می کند، راننده "درست" تغییر بسیار کمی در هر فریم ایجاد می کند. به عبارت دیگر، این معیار توانایی کارت گرافیک را در ترسیم مجدد اشیاء غیرقابل تجدید هر فریم آزمایش می کند.

چند ضلعی: 15653
منابع نور: 1
حالت: صاف + برجسته

این معیار مشابه نمونه قبلی است و نتایج سیستم ها نیز مشابه نتایج نشان داده شده در معیار قبلی است - AthlonXP 2000+ دوباره "صداقت" رتبه خود و دو برابر شدن حافظه پنهان L2 را نشان می دهد. Pentium4 سرعت قابل توجهی را افزایش می دهد.

4 . این بنچمارک توانایی یک کارت گرافیک را برای کنترل هندسه بسیار پیچیده نشان می دهد.

چند ضلعی: 200270
منابع نور: 1
حالت: صاف + برجسته

در این معیار هندسی، نتیجه به قدرت FPU (از آنجایی که برای محاسبه هندسه پیچیده ضروری است) و پهنای باند حافظه (از آنجایی که کشیدن سطوح در حالت Smooth + HighLight ضروری است) بستگی دارد. در مورد اول، Athlon یک مزیت واضح دارد، با این حال، پهنای باند RDRAM بسیار بالاتر است، بنابراین پلت فرم Socket462 نتیجه ای کمتر از سیستم Pentium4 2.0GHz نشان می دهد.

5 . معیار پنجم قابلیت‌های کارت‌های ویدئویی را برای پردازش هندسه بسیار پیچیده آزمایش می‌کند. این بار تعداد چند ضلعی ها تقریباً دو برابر شد و تقریباً به 376000 رسید. خانه‌ها اکنون روی همان «سطح» قرار دارند.

این معیار قادر است هر کارت گرافیکی را "به زانو درآورد" - میانگین فریم در ثانیه از سه فریم تجاوز نمی کند. خود فایل ایجاد شد، البته نه با fps=3، خانه ها به طور جداگانه در فایل های مختلف ایجاد شدند و هنگام "نصب بر روی زمین"، قسمت استفاده نشده هندسه "خاموش" شد تا کارایی افزایش یابد.

چند ضلعی: 376875
منابع نور: 1
حالت: صاف + برجسته

در یک معیار هندسی دشوارتر، وضعیت مشابه مورد قبلی است، با این حال، با افزایش هندسه پردازش شده، تأثیر حافظه پنهان کاهش می یابد و تأثیر واحد FPU رشد می کند.

6 . معیار تست سرعت پردازش چندین منبع نوری از آنجایی که اکثر کارت‌های ویدئویی بیش از 8 نور را پشتیبانی نمی‌کنند، این تست و دو تست بعدی شامل 8 منبع نور از انواع مختلف هستند. در این آزمایش، 8 منبع نور SpotLight، در حال حرکت، نوعی "سیارک" را روشن می کنند:

لازم به ذکر است که نمایش نور ایجاد شده توسط Spotlights نسبت به نمایش نور ایجاد شده توسط چراغ های Omni و Directional فرآیندی بسیار پرمصرف تر است.

چند ضلعی: 39600
منابع نور: 8
حالت: صاف + برجسته

7 . همان "سیارک"، فقط اکنون توسط هشت منبع نور جهت دار روشن می شود. نورهای جهت دار نسبت به Omni "کندتر" هستند، اما نسبت به چراغ های Spotlight "سریع تر" هستند.

چند ضلعی: 39600
منابع نور: 8
حالت: صاف + برجسته

8 . دوباره همان "سیارک" و دوباره هشت منبع نور. اکنون این چراغ‌های Omni هستند، سریع‌ترین چراغ‌ها در 3DMAX.

چند ضلعی: 39600
منابع نور: 8
حالت: صاف + برجسته

در معیارهای روشنایی، AthlonXP 2000+ نتایج قابل مقایسه با Pentium4 2.0GHz را نشان می دهد. افزایش عملکرد از افزایش حافظه کش از 10٪ تجاوز نمی کند.

9 . صحنه ای با هندسه "نور" و یک منبع نور واحد، تنها چهار و نیم هزار چند ضلعی، که کل پنجره طرح ریزی را اشغال می کند، معیاری از سرعت شطرنجی در حالت Smoth + Highlights است.

هنگام حرکت دوربین، کارت گرافیک باید چند ضلعی های بزرگ و کوچک (نسبت به اندازه صفحه) را شطرنجی کند.

چند ضلعی: 4684
منابع نور: 1
حالت: صاف + برجسته

در معیار شطرنجی، AthlonXP 2000+ نتیجه ضعیفی را نشان داد - کمتر از Pentium4 با فرکانس ساعت مشابه (1700 مگاهرتز). این با این واقعیت توضیح داده می شود که در این معیار همه چیز به سرعت انتقال داده در گذرگاه حافظه پردازنده بستگی دارد.

10 . معیاری که سرعت کارت‌های ویدیویی را با بافت نشان می‌دهد. فایل حاوی تعداد زیادی بافت و حداقل هندسه است. معیار یک توپ چرخان است که 48 بافت روی صورت آن قرار گرفته است.

حداقل هندسه و حداکثر تکسچرهای این صحنه سرعت پردازش بافت توسط کارت گرافیک را حداکثر نشان می دهد.

چند ضلعی: 224
منابع نور: 1
حالت: صاف + برجسته

11 . اتاق کاملا بافت که دوربین در داخل آن حرکت می کند. این معیار نزدیکترین به برنامه های کاربردی واقعی است، زیرا حاوی بافت های زیادی، هندسه پیچیده و چندین منبع نور است. این بنچمارک قابلیت‌های کارت‌های ویدیویی را هنگام پردازش صحنه‌های پیچیده در حالت Smooth + Highlight نشان می‌دهد.

چند ضلعی: 12413
منابع نور: 8
حالت: صاف + برجسته

12 . "امواج" بافت متحرک سرعت پردازش و اصلاح بافت ها را نشان می دهد.

چند ضلعی: 880
منابع نور: 1
حالت: صاف + برجسته

در سه معیار بافت، سیستم‌ها باید بافت‌های چرخان را محاسبه کنند (در اولین معیار بافت)، بافت‌های ثابت را با دوربین دوار (در دومی) اصلاح کنند و بافت را تغییر شکل دهند (در سومین معیار).
حدس زدن اینکه در اولین معیار بافت، پهنای باند حافظه و اندازه حافظه نهان از همه مهمتر هستند سخت نیست - به همین دلیل است که Athlon تا Pentium4 2.2 گیگاهرتز کار نمی کند.
تصحیح بافت توسط FPU انجام می شود، بنابراین در معیار دوم Athlon2000+ نزدیک به Pentium4 2.2GHz است. همچنین افزایش حافظه کش 15 درصد افزایش می دهد.
محاسبه تغییر شکل بافت نیز توسط FPU انجام می شود، و در این معیار AthlonXP 2000+ بهتر از Pentium4 2.2GHz عمل می کند.

13 . این معیار سرعت کار را در حالت Wireframe اندازه گیری می کند. 111 هزار چند ضلعی در حالت وایرفریم آزمایشی جدی برای هر کارت گرافیک مدرن خواهد بود.

چند ضلعی: 111270
منابع نور: 1
حالت: Wireframe

این بنچمارک بافت دارای صحنه مشابه با بنچمارک شماره 4 است، اما برخلاف معیار چهارم، در اینجا این صحنه در حالت Wireframe رندر می شود. بنابراین، در این بنچمارک، همه چیز به قدرت FPU بستگی دارد - Ahtlon نتیجه ای قابل مقایسه با نتایج پردازنده های Pentium4 که با فرکانس 2 گیگاهرتز کار می کنند را نشان می دهد و افزایش میزان حافظه کش در این تست هیچ افزایش سرعتی را به همراه ندارد.

تمام معیارهای فوق برای آزمایش کارت های ویدئویی توسط سازنده 3DMAX توصیه می شود، با این حال، همانطور که دیدیم، آنها قابلیت های کارت های ویدئویی را با عملکردهای جداگانه آزمایش می کنند و هیچ تست "عمومی" در بین آنها وجود ندارد. بنابراین من یک معیار دیگر را اضافه کردم - این صحنه ای است با هشت نور، 61371 چند ضلعی و بسیاری از صفحات شفاف. پیچیدگی این فایل برای امروز کاملاً معمول است، کل فایل به همراه بافت ها بیش از 6 مگابایت طول می کشد. این انیمیشن برای بهترین آزمایش ممکن ساخته شده است - دوربین در اطراف اتاق حرکت می کند و همه اشیاء را می گیرد. اولین فریم بعد از رندر نهایی به این صورت است:

من از این صحنه برای تست کارت‌های ویدئویی در هر دو حالت Wireframe و Smoth+Highlights استفاده کردم. بنابراین، ما دو معیار دریافت کردیم:

14 . صحنه در حالت Wireframe

چند ضلعی: 61371
منابع نور: 8
حالت: Wireframe

از آنجایی که صحنه در این بنچمارک در حالت Wireframe نمایش داده می شود، مانند بنچمارک قبلی، میزان حافظه نهان تاثیر محسوسی ندارد و نتیجه AthlonXP2000+، به لطف FPU قدرتمند، برابر با نتیجه Pentium4 است. 2.2 گیگاهرتز که با فرکانس 50 درصد بالاتر اجرا می شود و دو برابر حافظه کش دارد.

15 . همان صحنه در حالت Smooth+HiLight

چند ضلعی: 61371
منابع نور: 8
حالت: صاف + نور زیاد

از آنجایی که صحنه در حالت Smooth+HiLight رندر می شود، نتایج Athlon به خوبی معیار قبلی نیست. با این حال، نتایج AthlonXP 2000+ برابر با Pentium4 2.0GHz است و Athlon مجدداً رتبه خود را تأیید می کند.
حافظه نهان 512 کیلوبایتی به جای 256 کیلوبایت، در این بنچمارک، مانند اکثر بنچمارک ها با هندسه "متوسط" و حالت Smooth + HighLight، به شما اجازه می دهد تا حدود 15 درصد افزایش سرعت داشته باشید.

تست مشخصات سرعت در رندر نهایی

من رندر نهایی سه صحنه را از تحویل 3ds max4 با پارامترهای یکسان، با وضوح یکسان 800x600 انجام دادم، زیرا درصد نتایج پلتفرم های آزمایش شده برای همه رزولوشن های 640x480 تا 1600x1200 یکسان است. این صحنه ها:

جدول نتایج (زمان بر حسب ثانیه: هر چه کمتر بهتر):

سرعت رندر نهایی در درجه اول به قدرت FPU بستگی دارد، بنابراین در رندر نهایی AthlonXP2000+ فقط کمی بدتر از Pentium4 2.2GHz عمل کرد.

نتیجه گیری

AthlonXP 2000+ بر اساس مجموع نتایج در عملیات آزمایشی همه معیارها در پنجره های پروجکشن، نتایج قابل مقایسه با Pentium4 2.0A GHz را نشان می دهد. علاوه بر این، هنگام کار در حالت Wireframe، AthlonXP2000+، به لطف یک FPU بسیار قدرتمند، نتیجه ای نزدیک یا برابر با Pentium4 2.2GHz نشان می دهد (علیرغم این واقعیت که دومی با سرعت کلاک +50٪ کار می کند و دو برابر کش دارد). بنابراین، اگر بیشتر وقت خود را در حالت Wireframe صرف می کنید، AthlonXP2000+ بهترین انتخاب است. در تست سرعت رندر نهایی، نتایج AthlonXP 2000+ نیز تقریباً برابر با Pentium4 2.2GHz است. بنابراین، با هزینه پردازنده AthlonXP 2000+ 250 دلار. (و با Pentium4 2.0AGHz و 2.2GHz با قیمت به ترتیب 350 و 550 دلار) و مادربردهای ارزان‌تر برای آن، پلتفرم Socket462 سودآورترین پلتفرم در رده «قیمت-عملکرد» است. با این حال، سریع ترین پردازنده برای 3DMAX پنتیوم 4 2.2 گیگاهرتز است.
تفاوت عملکرد پردازنده‌های Pentium4 با حافظه نهان ۲۵۶ کیلوبایت و ۵۱۲ کیلوبایت در اکثر آزمایش‌هایی که کار را در پنجره‌های پروجکشن شبیه‌سازی می‌کنند و محاسبه رندر نهایی از ۵% تجاوز نمی‌کند، بنابراین تغییر پردازنده با کش ۲۵۶ کیلوبایت به پردازنده‌های جدید منطقی نیست. با کش 512 کیلوبایتی. از سوی دیگر، امروزه خرید پردازنده هایی با حافظه نهان کوچکتر نیز بیهوده است - قیمت پردازنده های با کش 265 کیلوبایت و کش 512 کیلوبایت تقریباً برابر است.