אסף גליל
תחילת שנות השמונים הגדירו שלוש חברות מובילות Intel Xerox ו-(DEC) את סטנדרט Ethernet IEEE 802.3. סטנדרט זה – ועשרות סטנדרטים שהתווספו אליו שינו לנצח את יכולות התקשורת למחשב.
המחשב האישי “נולד” באותה התקופה. פרט לעליה בביצועי המעבד והגידול העצום בזכרון הנדרש – עלתה בהתמדה המהירות של החיבור לרשת. מחשבי ה-PC XT הראשונים ו-PC AT שבאו אחריהם – לא הכילו כרטיס תקשורת ל-Ethernet. בתחילה היה חיבור ל-Ethernet נחלתם של מחשבים גדולים ובינוניים. בהמשך חדרה הטכנולוגיה למחשבים האישיים – וכיום לכל מחשב אישי ישנו לפחות מימשק אחד בקצב של 1 Giga Bit Per Second – ומחשבים לשימושים מסחריים משתמשים בקצבים גבוהים אף יותר.
התפתחות הדרישות מה-Ethernet
כפי שכל אחד מאיתנו יודע – הדרישה החשובה ביותר מהממשק ל-Ethernet הוא המהירות שלו – וניתן לחוש בהבדל משמעותי בזמן הורדה והעלאה של קובץ בתלות במהירות.
מאידך – ה-Ethernet הפך אמצעי זול ונוח מבחינת זמינות כבלים, מתגים ותוכנה – למטרות שונות מאשר הורדה והעלאת קבצים. מה שמשותף ליישומים חדשים אלה הוא שהאינפורמציה החשובה נמצאת במספר קטן של packets (לרוב אחד) ושחשוב מאד עד כמה מהר ומדויק יוכלו המשלוח והקבלה להתבצע מהזמן שפקודה בתוכנה דורשת זאת.
דרישות כאלה של הפעלת Ethernet אינן יכולות להתבצע מעל מערכות הפעלה – General Purpose Operating Systems
(GPOS) – כמו Windows או Linux.
כאן נדרשת מערכת הפעלה שמנגנוני התזמון שלה מאופיינים על ידי התכונה: Preemptive Event Driven Scheduling או במילים אחרות מערכות הפעלה לזמן אמת.
בין מערכות ההפעלה מהטיפוס הנ”ל בולטת INtime בכך שהיא מספקת את הדרישות של דטרמיניסטיות לרכיבי I/O ולתהליכים המפעילים אותם, ומאפשרת ליתר התהליכים – ורכיבי ה-I/O שמופעלים על ידיהם שאינם דורשים דטרמינסטיות – להמשיך לפעול מתוך Windows. אחד היישומים שבהם השילוב הזה מאוד מקובל הוא יישומים שבהם נדרש Deterministic Ethernet.
היישומים שהתפתחו מעל
Deterministic Ethernet
יישומים אלו מומשו בעבר באמצעים שונים, מורכבים ויקרים. העברתם
לסביבה כמו זו של INtime הפכה אותם לעשירים ביכולות וזולים בהרבה במחיר.
סימולטורים ומכשירי בדיקה: נדרש לשלוח למכשיר נבדק packets בתזמון מדויק ולקבל מהמכשיר הנבדק תגובה שיש למדוד בדיוק.
הרחבת I/O: כמו במוצרי DAQ של חברת UEI: כל ה-I/O “יושב” על יחידה חיצונית ומשם יוצאים כל המימשקים. היחידה מצידה מחוברת למחשב באמצעות Ethernet. הדרישה היא לתקשורת בעיכובים קצרים ביותר וקבועים, כדי לדמות עד כמה שאפשר את המצב המקורי שבו ה-I/O היה מחובר ל-PC ישירות.
Industrial Busses כמו Ethercat: טיפול ברמת ה-Frame הבסיסי של ה-Ethernet בצורה מהירה ומדויקת. המטרה היא שיחידות חיצוניות יוכלו לקבל ולתת את האינפורמציה שתאפשר להם להשלים חוגי בקרה.
מערכות Trading: נדרש לקבל אינפורמציה ב-packet שמגיע לרוב
ב-Multicast, לחשב במהירות את התגובה הנדרשת ולשלוח אותה בזמן הקצר ביותר האפשרי כדי לבצע את הטרנזקציה.
מכשירי הקלטה: נדרש לקבל רצף של frames שמגיעים במהירויות גבוהות, לעיתים אף לנתח אותם, ולאחסן אותם על דיסק מבלי לאבד אף packet.
Front End למערכות שמייצרות מידע במהירויות גבוהות – למשל מערכות מכ”מ: דומה ליישום של מכשיר הקלטה, אלא שהמטרה אינה להקליט אלא לנתח באלגוריתמים מתמטיים וליצור output לביצוע – בהתאם לסוג המכ”מ.
המשותף ליישומים החדשים
התקשורת הנכנסת יכולה להגיע לרמה 2 מבחינת מודל 7 השכבות: רק המידע וכתובת ה-MAC מגיעים. או ברמה 4 שבה מגיעה גם אינפורמציה בצורת TCP או UDP. עבור כל צורות ההגעה, חשוב שיעבור זמן קצר וקבוע בין כניסת ה-frame לזמן שהיישום מתחיל לטפל בו. אותו הדין לגבי תקשורת יוצאת: נדרש זמן קצר וקבוע מהזמן שהמידע מוכן עד ליציאת
ה-packet לקו. חשוב לציין שחשוב שהטיפול יהיה ברמת האפליקציה להגדלת הגמישות בפיתוח – ולא ברמת ה-driver.
מדוע צריך מע”ה לזמן אמת ליישומי התקשורת הנ”ל?
בישומים הנ”ל – הגעת frame או packet הינן ארוע שחייב להיות מטופל בהקדם האפשרי. מצד שני הטיפול ב-packet אינו מוגדר מראש ובכל יישום מבוצע לפי דרישות שונות. הטיפול בנתונים המגיעים חייבים להתבצע ברמת האפליקציה, ולהיעזר בכלים הנוחים ביותר ליצירה וניפוי שגיאות. כלומר – מצד אחד – בהגיע הפסיקה על הגעת הנתונים נדרשת הפסקה מיידית של כל המשימות האחרות ומצד שני נדרש לכתוב את הטיפול ברמת הישום בצורה גמישה ובאפשרויות נוחות ל-debug. במערכות כמו Linux או Windows הזמנים הקשורים להגעה וליציאת frame אינם קבועים. לעיתים הם קצרים ולעיתים הם ארוכים – כך שעלולים להיגרם “פספוסים”: היישום אינו מספיק לטפל ב-frame וכבר מגיע ה-frame הבא, או שה-frame יוצא באיחור ביחס ל-Trigger.
איך מטופלת תקשורת ה-Ethernet במע”ה INtime?
INtime הינה מערכת הפעלה מלאה לזמן אמת. מע”ה זו “נולדה” כ-17 שנים לפני יציאת Windows NT – ושורשיה הם מע”ה שתוכננה מראש להיות Real Time Multi Tasking OS בעלת Preemptive Event Driven Scheduling.
התשתית של INtime מאפשרת לכותב אפליקציה, לפתח באמצעות Visual Studio תהליכים (processes) על ידי קביעת priorities מתאימים – ולקבל את המעבד לביצוע במינימום הפרעות.
אם מסתכלים על מפת התהליכים של INtime כשאין יישום שכתב הלקוח, רואים שתי עובדות חשובות שנראות שונות לחלוטין ממה שרואים למשל ב-Windows Task Manager:
העובדה הראשונה היא שאחוז ה-CPU שצורכת מערכת ההפעלה לפני הטענת תוכנת לקוח, הוא הרבה פחות מ-1%.
העובדה השניה היא שהתהליכים שמערכת ההפעלה מנהלת – גוזלים את ה-CPU למשך זמנים קצרים מאד – מיקרו שניות בודדות מידי פעם. כך שברור שאם תידרש מערכת הפעלה זו להטעין ולהריץ תוכנת לקוח – גם במקרה הקיצוני של קונפליקט עם דרישת משאבים על ידי מערכת ההפעלה שלא למטרת היישום – יהיה עיכוב קטן ביותר ליישום הלקוח.
באיור מספר 1 מצורפת תמונת תהליכי INtime – במצב שאף תהליך של לקוח לא רץ. ציר ה-X מראה את הזמן במילישניות. בציר ה-Y מצד שמאל מופיעים
ה-processes וה-threads של מערכת ההפעלה. ניתן לראות בבירור שרוב הזמן – thread בעל token מספר 268 (ה-Idle thread של INtime) הוא זה שרץ. מידי פעם ישנן “גזילות” של המעבד לזמנים קצרים ביותר.
המבוגרים שביננו יזכרו במיקרו-בקרים הוותיקים (6800, 8051 ושכמותם). המיקרו-בקר חיכה ל-interrupt ואז ביצע את המשימה שלו מיידית וללא הפרעה. אולם “לוקסוס” כזה לא קיים היום. דרישות הפרויקטים עלו, ובכל יחידת זמן מבצעות מערכות ההפעלה משימות רבות שמטרתן לתחזק את השירותים שמבטיחים מענה לדרישות הנוספות הללו. כך קורה כשמגיע trigger למשימה דחופה לביצוע כל המשימות האחרות חייבות בזמן קצר ביותר “לפנות את הבמה”.
אם נתרכז ביישום של קליטת “הפצצה” שמגיעה מכיוון הרשת. כל UDP packet נקרא על ידי INtime והוא מפוענח ונכתב בזכרון. המשאבים הדרושים מצד המחשב לטיפול הם ה-Ethernet Driver של הכרטיס, ה-IP Stack והיישום שמטפל ב-packet. כדי לא לאבד אף packet על תהליכי הקליטה להיות קצרים (הזמן תלוי במהירות המעבד) וקבועים באורכם. אם יחרוג משך הטיפול ב-packet מזמן מסוים עקב הפרעות של דורשי שרות אחרים, יתכן ונאבד את ה-packet הבא.
ל-INtime ישנה תשתית מצויינת לטפל במצב הזה.
באיור מספר 2 רואים את ניתוח הזמנים
ב-INtime ביישום של קליטת “הפצצה” של Byte UDP Packets שמגיעים כל 300 מיקרושניות.
למרות שהמחשב שעליו הרצנו את היישום הוא חלש יחסית (Hardware Thread אחד במעבד I3) הרי הטיפול ב-packet יציב בזמן ואינו מופרע על ידי תהליכים אחרים במחשב – לא של INtime ולבטח לא של Windows. במשך כ-90 מיקרושניות מטופל ה-packet על ידי thread של
ה-Stack ועל ידי היישום. ביתר הזמן המעבד נמצא ב-idle thread שלו –
שה-Handle שלו כאמור לעיל הוא 268. במילים אחרות – ניתן לקבל את כל משאבי המעבד לטובת המשימה הנדרשת.
היכולת לראות בדיוק של מיקרו שניות איפה “מבלה” המעבד – הוא מרכיב חשוב ביותר במערכת הפעלה לזמן אמת. והכלי INscope שמסכיו הוצגו כאן מספקים את היכולת הזו במע”ה INtime.
איך נעזרים בריבוי ליבות בצורה של AMP ליישומי התקשורת הנ”ל?
במערכות גדולות – משתמשים במספר גדול של Ethernet ports. כאמור ה-IP Stack הינו process מורכב שכאשר נדרש לפעולות מורכבות – הוא “צורך” כמות גדולה של משאבי CPU.
בריבוי ליבות, INtime רצה כמערכת הפעלה מלאה על כל ליבה ומתקשרת עם ליבות אחרות. צורת עבודה כזו קרויה
() Asymmetrical Multi Processing. זאת להבדיל מ-Symmetrical Multi Processing () שפועלת במערכות כמו Windows או Linux. ב-SMP ישנה ליבה אחת שמבצעת את פעולות ה-scheduling של מערכת ההפעלה, וליבות אחרות שבצורה דינמית מריצות processes שאותן מנהלת הליבה השולטת.
אם ניקח למשל מעבד של 8 ליבות שמריץ Windows ניתן להקצות עד 7 ליבות
ל-INtime. קונפיגורציה אחרת היא שכל 8 הליבות יריצו את INtime. חשוב לציין שאותו הקוד ירוץ בשתי הקונפיגורציות.
ניקח למשל את הקונפיגורציה האחרונה של 8 ליבות שכולן מריצות INtime – ניתן לשם ב-PC שני כרטיסי רשת של 4 ports כל אחד. בקונפיגורציה הזו כל ליבה נטענת במערכת הפעלה מלאה ו-IP stack מלא. מבנה ה-AMP מאפשר שבריבוי ליבות ובריבוי Ethernet Ports – יכולה כל ליבה להריץ את ה-IP Stack המלא ולטפל ב-port נוסף. פתרון זה מאפשר הגדלה לינארית של יכולת העיבוד עם ריבוי הליבות. כל אחת מהליבות מספקת זמן תגובה קצר ויציב לכל כניסת packet. הקשר בין הליבות יכל להתבצע במגוון שיטות של Global Objects מסוג Shared Memory ,Semaphore וכו‘.
איך מבצעים Scaling במספר רב של ממשקים ליישומי התקשורת הנ”ל?
בכל תכנון מערכת עם INtime ישנן כמה קונפיגורציות אפשריות. ניתן להחליט על הקונפיגורציה כבר בתחילת הפרויקט, וניתן לדחות את ההחלטה למועד שבו ישנו קוד רץ. מלכתחילה הקוד המפותח יוכל בצורה דינמית להתאים עצמו לפעול על מערכת במספר ליבות משתנה, ובאופן ביזור משתנה.
במצבים מסוימים חשוב לכלול בפתרון גם מחשבי PC שכל הליבות שלהם מוקצות לביצוע משימות בזמן אמת – כפי שתואר לעיל במחשב בן 8 הליבות. במקרים כאלה – אותו הקוד המפותח יכול לרוץ גם על מחשבי PC שעליהם Windows אינו מותקן כלל, ואת השירותים – במידה ונדרשים -מקבלת התוכנה המפותחת מ-PC שמריץ Windows ומחובר על ה-LAN. היכולת הזו להריץ אותו הקוד בקונפיגורציות בעלות מספר ports ומספר ליבות ומספר מחשבים שונה – מאפשרים scaling לקונפיגורציות מגוונות בשימוש באותו הקוד.
איך משתמשים באותו ה-port ל-INtime ול-Windows?
כשמע”ה Windows קיימת ב-PC לצידה של INtime, ניתן לבצע בה את כל ה-processes שאינם דורשים דטרמיניסטיות. באם רוצים גם להשתמש ב-Ethernet Port – ניתן כמובן להפריד את ה-ports לכאלה המופעלים על ידי INtime וכאלה המופעלים על ידי Windows. מאידך – ניתן לבצע Bridge שדרכו תדברנה שתי מערכות ההפעלה בשני IP שונים מעל אותו ה-port.
איך מקטינים את זמן הטיפול בפרוטוקול של המידע הנכנס?
INtime משתמש ב-IP Stack שבנוי על Open Source Network 7 BSD. זה מאפשר לבחור מתוך כמות עצומה של פונקציות לטיפול ב packet. מאידך – אם המטרה היא לקבל את ה-payload וכל הנושאים האחרים אינם חשובים – הרי שניתן לעבוד ב-INtime בפרוטוקול הקרוי High Performance Ethernet (). כשמפעילים את ה-API של המימשק, זמן הטיפול ב-packet הוא מיקרו שניות בודדות – וה-jitter הוא
כמיקרו שניה.
איך משתמשים באותו ה-port גם ל-IP וגם ל-HPE?
בחלק מהיישומים מעוניינים בכך ש-frames מסויימים יקבלו “טיפול מהיר” – באמצעות HPE וכל היתר – יקבלו טיפול של ה-Stack המלא – שניהם על אותו ה-port. זה אפשרי בהגדרת המימשק בצורה מסוימת הקרויה Connector Device. ה-packet הנכנס מטופל על ידי תכנת הלקוח או מועבר ישירות לטיפול ה-Stack.
יכולת זו מספקת מענה ליישומים רבים כמו Firewall, שילוב BUS תעשייתי באותו ה-port שבו משתמשים למטרות תקשורת IP רגילה ועוד. ברמת ה-HPE מתבצעים חלקי היישום שדורשים זמני תגובה קטנים ומדוייקים תוך מיקרושניות בודדות. איור מספר 3 מציג את הקונפיגורציה הזו הקרויה Connector Device.
לסיכום
עקב הזמינות של מרכיבי חומרה לתקשורת מבוססת Ethernet – עולה השימוש בהם למטרות שונות מהכוונה המקורית של העברת קבצים. בשימושים החדשים הללו במערכות משובצות, מחייבות הדרישות צורת ניהול שאפשרית רק במערכות הפעלה לזמן אמת.
INtime מספקת מיגוון פתרונות שמקלים על המתכנן ומאפשרת לבנות מערכות רבות עוצמה במחיר נמוך.
על המחבר
אסף גליל הינו מהנדס יישומים של חברת TenAsys והחברה שבבעלותו היא הנציגה בארץ של החברה האמריקאית TenAsys – מפתחת תוכנת INtime. לאסף למעלה משלושים שנות נסיון בפעילות בשוק ה-Embedded.
