איך תביאו לשיא את הביצועים והדטרמיניסטיות של היישום שלכם – על ידי שימוש במע”ה לזמן אמת INtime מעל מעבדי אינטל מרובי ליבות

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

יכולת עיבוד נמדדת במספר פקודות המחשב בשנייה שמסוגל המעבד להריץ
מערכות הפעלה למחשבים מטיפוס General Purpose Operating Systems או GPOS מציעות שיטה שקרויה SMP – Symetrical Multi Processing לצורך הגדלת יכולת עיבוד. בשיטה זו מנגנון תזמון מרכזי שרץ בליבה אחת מחלק לפי אלגוריתם מיוחד את התהליכים לליבות ומאפשר מקביליות מסוימת בין הרצת התהליכים.
יכולת התגובה היא מושג יותר מורכב שאינה מטופלת על ידי GPOS, וכוללת שני פרמטרים – Latency – כמה זמן עובר מהבקשה לטיפול על ידי ההתקן החיצוני עד לתחילת הטיפול בתכנית שרצה על המעבד.
Jitter – ה-worst case של הסטייה
מה-latency.
התכונה של latency ו-jitter – נמוכים, קרויה דטרמיניסטיות או במילים עממיות: עד כמה ניתן לסמוך על כך שהמערכת תגיב בזמן הנדרש תמיד. המעבדים כיום מהירים הרבה יותר מבעבר ודעה שגויה שרווחת היא ששיפור הביצועים עקב שכלולי המעבדים – משפר את ה-latency וה-jitter. מרכיב האמת בהנחה זו הוא : ממוצע ה-latency אכן קטן במעבר למעבד יותר מהיר – אך ה-jitter שהינו ה-worst case של ה latency אינו משתנה כמעט בכלל – גם אם המעבד מהיר יותר.
לצורך מתן דטרמיניסטיות, מערכת ההפעלה חייבת להיות מטיפוס Real Time Operating System ובמעבר לעיבוד בריבוי ליבות הקונפיגורציה האופטימלית היא של – Asymetric Multi Processing או AMP בה כל ליבה מריצה עותק מלא של מערכת ההפעלה.

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

איך ניתן להבטיח דטרמיניסטיות על ידי מערכת ההפעלה
דרישה לדטרמיניסטיות חייבת להילקח בחשבון בתחילת תכנון מערכת ההפעלה. זו אינה תכונה שניתן להוסיף לאחר מכן. יתר על כן דרישה כזו סותרת לעיתים דרישות אחרות ממערכת ההפעלה וכשתכונות אחרות חשובות יותר אין מנוס אלא לוותר על הדטרמיניסטיות. זו הסיבה שהתפתחו מערכות הפעלה לזמן אמת – RTOS שמלכתחילה מדגישות דטרמיניסטיות כתכונה העיקרית שלהן.
מערכות הפעלה רבות מסוגלות להריץ משימות רבות. כל משימה מתקדמת בביצוע כאשר מערכת ההפעלה מאפשרת לה לקבל את המעבד לצורך ריצה.
במערכות מעשיות שפועלות מול מכונה עשויות להיות משימות רבות שדורשות דטרמיניסטיות ולא ניתן לייחד ליבה למשימה אלא להשתמש במערכת הפעלה שיועדה להיות דטרמיניסטית.
אחת ממערכות ההפעלה הללו הינה INtime של חברת TenAsys. פרט להיותה מערכת הפעלה לזמן אמת ותיקה ואמינה במיוחד – היחודיות שלה היא בשילובים האפשריים בסביבת הפיתוח ובסביבת הריצה עם Windows.

מושג העדיפות של
ה-thread
כמו בחיי היום יום – כדי להענות לבקשה למשימה, על האדם להיות ערני כל הזמן (לא להזדקק להפסקות ארוכות שבהן הוא “מושבת” מפעילות), ולהיות מסוגל להפסיק את מה שעושה ולהתחיל לטפל במשימה הדחופה יותר.
אם יתמהמה – המשימה תיכשל…

התכונות החשובות למערכת הפעלה לזמן אמת
1. הגדרת עדיפויות – ל-INtime ישנן 255 רמות עדיפות אפשריות למשימה
2. קבלת ארועים מבחוץ – פסיקות – INtime בנוי לקבל פסיקות מכל הסוגים.(של PCI, PCI Express, ISA).כתיבת התכנה לטיפול בפסיקות ודיבוגה נעשים על ידי Visual Studio.
3. הפסקה מסודרת ומהירה של המשימה הנוכחית לטובת זו הדחופה שדורשת תשומת לב- הושקע מאמץ רב בכתיבת קוד שמבצע זאת במהירות ב-INtime.
במע”ה מטיפוס RTOS – המפתח לשליטה ב-jitter היא מתן העדיפות הנכונה ל-thread.
INtime מסופק עם תכנית בשם jitter שמודדת את הסטייה של ה-latency שלה. היא יוזמת event כל sysem clock (החל מ-50 מיקרו שניות) ומציגה בהיסטוגרמה ב-Windows את הזמן שעבר מכניסתה בפעם הקודמת של האירוע. ניתן לשנות את העדיפות שלה ובכך לבחון את ה-jitter של כל משימה אחרת שתרוץ באותה עדיפות – באותו מצב של עומס משימות המערכת.
כשמגיע הזמן שבו ישנה משימה שמוכנה לריצה (ה-semaphore אליו חיכתה או ה-timer פקע) והיא גם בעלת העדיפות הגבוהה מביו חברותיה שהגיעו “לפרקן”, מתבצע preemption (קטיעה של ה-thread שרץ והחלפתו בחדש).

כדי להמחיש את השפעת העדיפות על ה-jitter נבחן את המקרים הבאים:
נשתמש בתכנת jitter ונשנה את העדיפות שלה לעומת משימת רקע המדמה עומס של המערכת.
נריץ אותה בשלושת המצבים:
1. אין אף משימה אחרת שרצה מעל מערכת ההפעלה – ניסוי A.
2. ישנה משימת רקע מורכבת אחרת שרצה בעדיפות נמוכה יותר – ניסוי B.
3. קימת אותה משימה מורכבת שרצה ברקע, אבל הפעם בעדיפות גבוהה יותר מזו של תוכנית jitter – ניסוי C.
משימת הרקע היא משימה של UDP server ש-Windows UDP client פונה אליה מבחוץ. משימה זו אינה מסונכרנת למשימת הבדיקה של jitter בדומה למצב שה”הפרעות” עלולות להגיע בכל עת. תוצאות שלשת הניסויים A B ו-C, מופיעות באיור מספר 1 על שלשת חלקיו.
ניתן לראות שבניסוי A ו-B ה”שמלה” של ההיסטוגרמה צרה מאד והמספרים מצד שמאל שמראים את מספר הפעמים בה היתה סטיה מ-500 (הזמן במיקרושניות בין בדיקות עוקבות) הוא קטן מאד. מספר אחר חשוב שהתקבל בניסוי A היא jitter (הסטיה המקסימלית) של 47 מיקרו שניות. תוצאה זו מאשרת שאכן אין תהליך של מערכת ההפעלה – או תהליך של חומרת המחשב שמשפיע לרעה על ה-jitter. ואם היינו בוחנים גם את העומס של הליבה שמריצה INtime היינו רואים מספר קטן מ-1%. זהו מצב שונה לחלוטין מזה של Windows שבו רצות משימות מערכת כל העת גם אם אף משימת משתמש לא הופעלה.
תוצאת ניסוי B (ה-jitter הוא 53 מיקרו שניות) דומה מאד לזו של A. הפעם INtime מריץ עוד משימה, אבל כיון שמשימת jitter היא בעדיפות גבוהה יותר הסטיה שלה שלה עדיין קטנה – וכמעט זהה למה שראינו בניסוי A.
בניסוי C הורדנו את העדיפות של תכנת ה-jitter כך ש משימת הרקע היא בעדיפות גבוהה יותר מזו של משימת המדידה. זה גורם ל-jitter של 114 מיקרו שניות – ולהרחבה משמעותית של ה”שמלה” כיון שקורות הרבה הפרעות למשימת המדידה.
עבור ניסוי C ערכנו אותו שוב בשעון מערכת של 50 מיקרו שניות ו”צילמנו” הפרעה כזו על ידי תוכנת Inscope. ה”צילום” מוצג באיור מספר 2. ציר ה-Y הוא ציר שמות ה-Processes וה-threads ששיכים להם. המרחקים בציר הזמן (ציר ה-X) זהים בין 3 ל-4 ובין 4 ל-5 והם כ-50 מיקרו שניות. אבל בין 1 ל-2 “נדחפת” משימה A (שמסומנת בחץ) שבעדיפות גבוהה יותר, כך שהמרחק עבור משימת מדידת ה-jitter (מסומנת בחץ B) בין 1 ל-2 ארוך יותר, ובהתאמה המרחק בן 2 ל-3 (עבור משימת המדידה) קצר יותר. רואים שאחד ה-threads ששייך למשימת הרקע שהיא istack .rta גוזל את ה-CPU ממשימת המדידה – clckjitter.rta. ארועים כאלה בהם משימה בעלת עדיפות גבוהה יותר מזו שרצה “גוזלת” את ה-CPU הם הגורם לעלית ה-jitter.
מהניסוי על שלושת שלביו ניתן להסיק שתי מסקנות:
בבסיסה מספקת INtime סביבה מתאימה להרצת תכניות ב-jitter נמוך.
כיונון מדויק של רמות העדיפות למשימות השונות מסוגל לתת את המענה המתאים לדרישות.
ומה דינן של המשימות שאין להן דרישה
ל-jitter נמוך מסוים?
לטיפול במשימות כאלה שהן ממילא בעדיפות נמוכה – מוגדר מספר עדיפות הקרוי round robin threashold. זהו פרמטר מערכתי הניתן לשינוי. כל הthreads בעדיפות נמוכה יותר מה-threashold הזה ירוצו האחד אחרי השני, אם לא הופסקו בעצמם או על ידי thread בעדיפות גבוהה יותר, למשך זמן במילי שניות (גם הוא פרמטר מערכתי). בסוף אותה יחידת זמן ירוץ thread אחר מאותה קבוצת round robin. בשיטה זו יובטח מצד אחד jitter נמוך למשימות מעל רמת ה threashold – ומצד שני יהיה פשוט לנהל את הthreads שאינם חייבים jitter נמוך.

מעבר לריבוי ליבות
קיימים שלשה מקרים בהם נשקול מעבר למספר ליבות.
1. יכולת העיבוד של ליבה אחת אינה מספיקה.
דרך ה-performace monitor של Windows ניתן לראות את % הליבה שנדרש על ידי INtime והתהליכים שהוסיף המתכנן. מקובל להשאיר קצת spare לפיתוחים עתידיים וכשמגיעים ל 60% ניצול של הליבה שוקלים להוסיף עוד אחת (אם אפשר).
2. קימות משימות רבות שדורשות דטרמיניסטיות – וה-latency ארוך מידי.
באחוזי שימוש גבוהים של ה-cpu, כשיש הרבה משימות שדורשות דטרמיניסטיות קורים מצבים שאפילו אם ה-jitter נמוך – עדיין לוקח זמן ארוך מידי לסיים משימות שצרכות להיות בעלות latency נמוך. במילים אחרות ישנן משימות דומות בדרישותיהן להן, שמונעות ממנה להסתיים בזמן.
3. קימות משימות רבות שדורשות דטרמיניסטיות – וה-jitter גדול מידי. גם באחוזי cpu נמוכים כשיש הרבה משימות שכולן בעדיפויות גבוהות והן אינן מסונכרנות האחת לשניה עלולות להווצר סטיות בתלות במצבים שכמה משימות בעדיפות גבוהה מפסיקות האחת את רעותה.

עבור שלשת המקרים הללו – הדטרמיניסטיות תשתפר אם נחלק את ה-processes לליבות. להבדיל מריבוי ליבות ב-Windows (שיטת SMP) – כל אחת מהליבות מכילה עותק מלא של מערכת ההפעלה על מנגנוניה – והיא אינה תלויה מבחינת הדטרמיניסטיות במה שרץ על ליבות אחרות.
חשוב לציין ששיקולי העברת משימות לליבות אחרות מתיחס גם ל-drivers של ממשקים פיזיים. למשל מהשיקולים שצוינו מפצלים לעיתים כרטיס LAN בן ארבע ports לארבע ליבות שונות. כל אחת מהליבות מריצה את ה-Driver של ה-port בנוסף להרצת ה-IP Stack.

איך קובעים מי ירוץ ואיפה?
אם בעקבות אחד מהתנאים שהוזכרו – עברנו למספר ליבות, INtime מספק לנו מספר אמצעים לשיוך ה-processes לליבה המסוימת באחד או יותר מהאופנים הבאים:
1. Autoload: לכל ליבה מוגדרים
ה-processes שנטענים בעלית הליבה.
2. תכנית ב-INtime שמבצעת create process לליבה מסוימת.
3. תכנית ב-windows שמבצעת create process לליבה מסוימת.
הטענת ה-processes בשיטות 2 ו-3 יכולות לחול לא רק בהתחלת הריצה אלא גם תוך כדי הריצה לפי פרמטרים שונים : חלקם סטטיים שמתקבלים מהקונפיגורציה, וחלקם דינמיים שנעזרים במידע שניתן לקרוא תוך כדי ריצה כמו , accounting וכדומה.
כשקובעים סטטית או דינמית איזה processes יטענו לאיזה ליבות חשוב לקחת בחשבון את ה-afinity של ה-processes. כלומר את התהליכים שמתקשרים בצורה תכופה האחד עם השני – מומלץ לשם באותה ליבה.

השאלות הנוספות שמתעוררות כשעובדים בריבוי ליבות בשיטת AMP
1. איך כל ליבה תעביר מידע ו\או תסתנכרן על ליבה אחרת?
INtime מאפשר הגדרת כל אוביקט כגלובלי- כדי לאפשר גישה לאוביקט מתוכנית שרצה באיזושהיא ליבה אחרת – גם מהליבות שמריצות Windows. אוביקטים כמו semaphore או region עשויים לשמש לסינכרון משימות, אוביקטים כמו shared memory mailbox או message queue משמשים להעברת מידע בין הליבות (כולל אלה של Windows). אפשרות אחרת היא להגדיר LAN switch פנימי בין הליבות כאשר לכל ליבה ישנו IP בממשק הקרוי ven0 (כולל גם ממשק דומה ל windows). הקשר בין הליבות יכול להתבצע בכל אופן תקשורת מעל IP: TCP או UDP. איור מספר 3 מתאר את ה-Internal Lan Switch

2. איך כל ליבה יודעת על מצבה של ליבה אחרת?
תהליך הקרוי Distributed System Manager () רץ על כל אחת מהליבות. כל תהליך בכל ליבה יכול להשתמש בשרותים של התהליך הזה. רשימת השרותים כוללת מעקב אחרי הקישוריות בין Windows ל-INtime ובין nodes של INtime לבין עצמם. המעקב כולל התרעות, ניקוי “שאריות” של אוביקטים שסיימו פעולתם וכדומה

סיכום
במערכת רובוטיקה למשל, ברור למתכנן שמערכת ההפעלה שמניעה את זרוע הרובוט חייבת להיות מטיפוס RTOS ולספק דטרמיניסטיות. במספר רב של דוגמאות אחרות, דרישות ה-jitter וה-latency אינן ברורות למתכנן. נוסף על כך גם בגמר הפרויקט אין מודדים זאת כיון שלעיתים המדידה מחייבת ציוד חיצוני מורכב שאינו בנמצא. במקרים אלה כשבוחרים ב-Windows למשל, המוצר עלול לחרוג לעיתים בתגובתו בציר הזמן לארועים חיצוניים, ובחלק מהמקרים יגרם צורך לבצע שינויים כואבים בפיתוח המוצר זמן רב מהתחלתו. INtime – מהיותה מערכת מטיפוס RTOS, בעבודתה בריבוי ליבות בשיטת AMP ובהמצאות כלים שעוזרים למפתח לבדוק ולשנות את ה-latency
ו-jitter – מסוגלת לתת מענה לתכנון prototype שיאפשר למתכנן לבחון ולמדוד מצבי קצה. INtime משתמש גם ב-Windows API כך שניתן להשתמש בקוד INtime בעבודה עם Windows ולהיפך.