איך אנחנו חוקרים את Windows

במדור «מחקרי Windows» אנו בודקים טענות טכניות קונקרטיות. בכל מאמר אנו מסבירים מה בדקנו, באילו תנאים ועל אילו מערכות חל התוצאה.

קיומו של פרמטר, השפעתו על פעולת המערכת והשיפור בביצועים מחייבים הוכחות נפרדות.

מה נחשב להוכחה

אנו משתמשים במספר סוגים בלתי תלויים של ראיות:

1. תיעוד ראשוני. מסמכים רשמיים של Microsoft, מפרטים ותיעוד של יצרן החומרה או היישום.
2. תצפית סטטית. סימני מימוש בגרסה מסוימת של רכיב. תצפית כזו מוגבלת לבילד שנחקר וכשלעצמה אינה מוכיחה שהנתיב מבוצע בזמן ריצה.
3. תצפית דינמית. אירועי מערכת, מצב רכיבים ועקבות שהתקבלו בתרחיש המתואר.
4. מדידה מבוקרת. השוואה של מדד שנבחר מראש בעת שינוי ידוע והחזרת מצב מאומתת.
5. שחזור. חזרה על התוצאה בהרצה בלתי תלויה, במערכת או בבילד אחרים.

שיטות אוטומציה פנימיות לאיסוף ועיבוד אינן מתפרסמות. הדבר אינו משנה את החובה לחשוף את השאלה הנבדקת, את התצורה, את המדדים, את מספר ההרצות ואת המגבלות.

סטטוסים של חומרים

סטטוס	משמעות
מתועד	ההתנהגות מתוארת במקור ציבורי ראשוני.
נצפה	אירוע או מצב התגלו בסביבה המצוינת.
נמדד	התקבל הבדל מספרי לפי המתודולוגיה המתוארת.
שוחזר	התוצאה חזרה על עצמה באופן בלתי תלוי.
לא שוחזר	האפקט המוצהר לא התגלה בתנאים המצוינים.
אין די נתונים	המתודולוגיה או המדגם אינם מאפשרים להסיק מסקנה.

הסטטוס מתייחס לטענה בודדת, ולא אוטומטית לכל המאמר. אנו לא משתמשים באחוז אמון שרירותי ולא מכנים תוצאה כהוכחה אוניברסלית ללא בדיקה במערכות אחרות.

כיצד נבנה הניסוי

לפני המדידה נרשמים:

• שאלה אחת נבדקת;
• משתנה בלתי תלוי;
• המדד העיקרי והיחידה שלו;
• Windows build, חומרה מהותית, דרייברים וגרסאות יישומים;
• סף בעל משמעות מעשית;
• דרך החזרת המצב ההתחלתי.

אנו משווים בין המצב ההתחלתי למצב המשתנה, ואז בודקים את החזרה. ככל האפשר אנו מחליפים את סדר ההרצות המזווגות. אנו שולטים בחימום, באספקת החשמל, בטמפרטורות ובעומס רקע; אם הדבר בלתי אפשרי, אנו מציינים את המגבלה.

קטעים בודדים של עקבה אחת מראים שינויים לאורך זמן, אך אינם נחשבים לחזרות בלתי תלויות. אין להעביר תוצאה של מכונה וירטואלית אוטומטית למחשב פיזי. כדי להסיק מסקנה לגבי כל ההתקנים של מחלקה אחת אין די בבדיקת התקן אחד.

עמדת click-to-photon פיזית

למחקרי גיימינג אנו משתמשים בעמדת חומרה משלנו. היא מודדת פיזית את מלוא ההשהיה מהאות החשמלי של לחצן העכבר ועד לשינוי הבהירות של פיקסל על המסך, ללא הערכה תוכנתית של מרווח זה.

המסלול העיקרי בנוי כך:

1. חוט מולחם לקו הלחצן השמאלי של Logitech G PRO X SUPERLIGHT מהדור הראשון. החזית החשמלית מפעילה טיימר Arduino Uno.
2. אותה לחיצה עוברת דרך בקר העכבר, USB, Windows, המשחק, תור הרינדור, GPU והמסך.
3. חיישן אור המוצמד למסך עוצר את הטיימר כאשר הבהירות של אזור הבדיקה חוצה סף שנבחר מראש.
4. תוצאה אחת מכילה את מלוא מרווח ה-click-to-photon במילישניות.

התחלה כזו כוללת במכוון את העיבוד בבקר העכבר ואת ה-click debounce שלו, אך אינה כוללת את התנועה המכנית של הלחצן עד לסגירת המגע. אנו לא מפחיתים את השהיית העכבר מהערך הסופי. במתודולוגיה העדכנית של מדידות בלתי תלויות של RTINGS עבור G PRO X SUPERLIGHT מצוין 2.5 ms בכבל ו-3.1 ms דרך receiver. ה-click latency הנמוך שנמדד הופך את העכבר הזה לחלק יציב ומתאים של העמדה, אך אינו הופך את התוצאה להשהיה טהורה של Windows או של המשחק.

מיקרו-בקר HID נפרד בפורמט Arduino Nano יכול לשלוח לחיצות ל-Windows אוטומטית. מסלול זה משמש כאשר יש צורך להסיר הבדלים של לחיצה ידנית ולחזור על אות הכניסה בקצב מבוקר. הוא עונה על שאלה אחרת ואינו מתערבב עם סדרות שמתחילות מהקו הפיזי של לחצן העכבר.

ב-CS2 משתמשים במפת workshop בשם BXLAT, שבה לחיצה גורמת לשינוי צפוי באזור הבדיקה. תרחיש חזותי דומה מיושם ב-Valorant. מיקום חיישן האור, הרזולוציה, תדר המסך, מגבלת FPS, מצב display scaling, presentation mode וסף האור נרשמים לכל הסדרה המושווית.

התקן הנוכחי דורש לא פחות מ-300 לחיצות תקפות לכל מצב. בסדרות חדשות אנו שומרים ממוצע, סטיית תקן, מינימום, מקסימום, אחוזונים, כולל P90, והתפלגות לבניית גרפים. הפעלות שגויות, חריגות מזמן ההמתנה וערכים מחוץ לטווח שנקבע מראש מסומנים ונלקחים בחשבון בעת בדיקת התאמת הסדרה.

המחקרים בעמדה זו נערכים כבר כמה שנים, ופורמט האחסון השתנה במהלך הזמן הזה. בטבלה הציבורית של מדידות היסטוריות יש סדרות של 300 לחיצות וסדרות מוקדמות יותר של 100. עבור חלק מהבדיקות הישנות נשמרו רק AVG, STDDEV, MIN ו-MAX; P90 או גרפים חסרים אינם משוחזרים מאגרגטים ומסומנים במפורש כלא זמינים. סדרות חדשות יפורסמו עם סטטיסטיקה מורחבת.

מה מתפרסם בתוצאה

המאמר מכיל:

• תשובה קצרה;
• הטענה הנבדקת;
• תחום המחקר;
• מתודולוגיה ומספר עקבות בלתי תלויות;
• ערכי מדדים ופיזור;
• מסקנות מאומתות ולא מאומתות;
• מדדים שהוחרגו או זוהמו;
• מגבלות;
• המלצה מעשית ללא הבטחה לתוצאה זהה;
• אישור החזרת המצב;
• מקורות ציבוריים ראשוניים ותאריך הבדיקה.

אם התוצאה לא אישרה המלצה פופולרית או פונקציה של BoosterX, היא עדיין יכולה להתפרסם. קיומה של הגדרה במוצר אינו הוכחה ליעילותה.

כיצד לבדוק בעצמך

חלק ניכר מהתצפיות הדינמיות במחקרינו משוחזר בכלים ציבוריים: Sysinternals ProcMon לעקבות מערכת ו-WinDbg עם סימבולים ציבוריים של Microsoft. מסלול הבדיקה הבסיסי נראה כך.

1. קריאת הפרמטר — ProcMon. פתחו Options → Configure Symbols וציינו שרת סימבולים ציבורי של Microsoft, כדי שמחסניות יציגו שמות של מודולים ופונקציות. לאחר מכן הוסיפו מסנן Path contains — למשל SystemResponsiveness מתוך HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. לפי אירועי הקריאה ניתן לראות אם הערך נקרא, מתי ועל ידי איזה תהליך.
2. מי קורא — מחסנית הקריאה. לחיצה כפולה על אירוע פותחת את מאפייניו; בלשונית Stack מוצגת שרשרת המודולים — זהו ה“קורא” של הפרמטר. למשל, שרשרת מ-user32.dll אל win32kfull.sys משמעה שעל הערך אחראית תת-המערכת Win32k.
3. התנהגות בזמן ריצה — WinDbg. עם סימבולים ציבוריים של Microsoft ניתן להציב נקודת עצירה על פונקציה מהמחסנית ולראות כיצד הערך הנקרא מיושם.
4. בדיקות סינתטיות. שנו את הערך ומדדו את ההתנהגות הנצפית. למשל, מרווחי כניסת עכבר נמדדים בכלי בדיקה ציבוריים של תדר דגימה.

גבול כן. ניתוח סטטי של בינאריים ועקבות מלאות אינם מתפרסמים במאמרים. המסלול לעיל משחזר את החלק הדינמי של התצפיות שלנו, אך אינו מחליף ניתוח סטטי — מסקנותיו מתייחסות לבילד שנחקר.

גבולות מדידת השהיה

השהיה תוכנתית, עומק תור, מחזור מנוע האודיו, זמן תזמון התהליכון והשהיה פיזית מלאה מתארים גדלים שונים. למשל, תור XAudio2 אינו קובע את כל המרווח מפעולת המשתמש ועד לקול מהרמקול. כדי למדוד אותו יש צורך בציוד חיצוני.

באופן דומה, זמן CPU של תהליך בודד אינו שווה להשפעה הכוללת על FPS, frametime, צריכת אנרגיה או היענות המערכת. מסקנות כאלה נבדקות במדדים נפרדים.

הגנת נתונים

קובצי ETL, PML, יומני אירועים, דאמפים של זיכרון וייצואי רישום מקוריים אינם מתפרסמים כברירת מחדל. עקבות מערכת עשויות להכיל שמות משתמשים, נתיבים, שורות פקודה, כתובות רשת ונתונים רגישים אחרים. Microsoft מזהירה על כך בנפרד בתנאי Sysinternals.

באתר מפורסמות רק טבלאות שנבחרו ידנית ועברו אנונימיזציה. אנו מסירים מזהים ייחודיים של התקנים והתקנות, נתיבים של משתמשים, נתוני חשבונות, מזהי רשת, פרטי התחברות ומידע על תהליכים שאינם קשורים למחקר.

תיקון מסקנות

Windows, דרייברים ויישומים משתנים. כל מאמר מקבל תאריך בדיקה אחרונה ותחום תחולה. אם מדידה חדשה סותרת מסקנה ישנה, המאמר מתעדכן עם הסבר לסיבה. תוצאה ישנה אינה מועברת לבילד חדש אוטומטית.

עצמאות וסימני מסחר

המחקרים מתפרסמים על ידי צוות BoosterX ועשויים להתייחס לפונקציות של המוצר. ניגוד עניינים אפשרי זה נלקח בחשבון בכך שהמתודולוגיה, הערכים הנמדדים, המגבלות והתוצאות השליליות מופרדים מההמלצה המוצרית.

BoosterX Wiki הוא פרסום עצמאי ואינו קשור, מאושר, ממומן או מאושר על ידי Microsoft Corporation. השמות Microsoft ו-Windows משמשים רק לתיאור מדויק של נושא המחקר. לפרטים נוספים: Microsoft Trademark and Brand Guidelines.

היסטוריית שינויים

• 2026-08-24: המתודולוגיה פורסמה.
• 2026-09-20: נוסף המדור «כיצד לבדוק בעצמך»; תוקן הקישור למקור נתוני העכבר.

בדיקת המתודולוגיה האחרונה: 2026-09-20.