From eacbf5bb4d57af21c731f41251015d3b991ad490 Mon Sep 17 00:00:00 2001 From: guest Date: Fri, 30 Nov 2007 13:41:25 +0000 Subject: final version, initial import git-svn-id: svn+ssh://mecka.net/home/svn/rtcorba-thesis@1 cba7306a-a4a0-4afd-bcb4-bd19f8a24309 --- diplomathesis/node51.html | 372 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 372 insertions(+) create mode 100644 diplomathesis/node51.html (limited to 'diplomathesis/node51.html') diff --git a/diplomathesis/node51.html b/diplomathesis/node51.html new file mode 100644 index 0000000..ac45aec --- /dev/null +++ b/diplomathesis/node51.html @@ -0,0 +1,372 @@ + + + + + +Ergebnisse + + + + + + + + + + + + + + + + + + + + +

+Ergebnisse +

+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Table 5: +Latenzzeiten bei variierender Systembelastung
SupplierCPU00001111
HD00110011
ReceiverNET01010101
CPUHDNET         
000 595630590763600710625630
001 945940995645740655825915
010 77020107358208201175860925
011 113514951115DR112015001240DR
100 595675645725600630605685
101 9757581015DR66098511601500
110 745920880103510108308551005
111 12351240795DR10701110DRDR
           
+ +

+Tabelle 5 stellt die gemessenen Latenzzeiten in (jeweils ansteigende + absteigende Flanke bei 400 Hz) bei variierender Systembelastung dar. DR bedeutet: +, eine korrekte Übertragung des Signals ist nicht mehr möglich. Die blau hervorgehobenen Werte zeigen, dass die CPU Auslastung die Echtzeitübertragung nicht beeinflußt. Die grünen Werte zeigen, dass der Supplier auch unter Belastung korrekt arbeitet. Die roten Werte signalisieren, dass der Receiver unter HD und, oder NET Last noch nicht korrekt arbeitet. + +

+Die nun beschriebenen Oszilloskop Screenshots sind Beispiele für die in Tabelle 5 farblich hervorgehobenen Erkenntnisse: + +

+ +

+ +

+
+ +
Figure 13: +Receiver u. Supplier o. zusätzl. Systemlast
+ [width=7.5cm]./img/v1/0100.jpg +
+
+
+
+
+ +
Figure 14: +Receiver o. zusätzl. Systemlast; Supplier mit CPU Last
+ [width=7.5cm]./img/v1/0136.jpg +
+
+
+
+
+ +
Figure 15: +Receiver o. zusätzl. Systemlast; Supplier m. CPU, Netz u. HD Last
+ [width=]./img/v1/0108.jpg +
+
+
+
+
+ +
Figure 16: +Receiver m. Netzlast; Supplier o. zusätzl. Last
+ [width=]./img/v1/0116.jpg +
+
+
+
+
+ +
Figure 17: +Receiver u. Supplier m. CPU, Netz u. HD Last
+ [width=]./img/v1/0213.jpg +
+
+
+
+
+ +
Figure 18: +Receiver m. CPU u. HD Last; Supplier m. CPU, Netz u. HD Last
+ [width=]./img/v1/0149.jpg +
+
+
+
+ +

+Abbildung 13: Ohne zusätzlich produzierte Systemlast beträgt die Latenzzeit kontinuierlich 300 s. Da alle an der Kommunikation beteiligten Prozesse sehr hoch priorisiert sind, dürfte in einem Echtzeitsystem eine Auslastung der Resourcen durch niedriger priorisierte Tasks die Latenzzeit nicht bedeutend verändern. + +

+Abbildung 14: Eine Auslastung der Supplier CPU beeinflusst die Latenzwerte nicht. + +

+Abbildung 15: Volle CPU Last, ein flood Ping und dauerhaftes Lesen von der Festplatte auf dem Supplier beeinträchtigt das Real-time Verhalten nicht. + +

+Abbildung 16: Ein flood ping auf den Receiver beeinträchtigt dessen Antwortverhalten. Vermutung: Priority Inversion bei der Abarbeitung von Netzwerkpaketen. + +

+Abbildung 17: Wird auf beiden Systemen Netz- CPU- und HD-Last erzeugt wird das Signal nicht mehr korrekt übertragen. Eine fehlerfreie Übertragung des Signals ist nicht mehr möglich sobald +. + +

+Abbildung 18: Ohne flood ping auf den Receiver kann das Signal korrekt übertragen werden. + +

+


+ +Subsections + + + + + + +
+Manuel Traut +2007-02-25 +
+ + -- cgit v1.2.3