Ergebnisse

Table 5: Latenzzeiten bei variierender Systembelastung

Supplier			CPU	0	0	0	0	1	1	1	1
	HD	0	0	1	1	0	0	1	1
Receiver			NET	0	1	0	1	0	1	0	1
CPU	HD	NET
0	0	0		595	630	590	763	600	710	625	630
0	0	1		945	940	995	645	740	655	825	915
0	1	0		770	2010	735	820	820	1175	860	925
0	1	1		1135	1495	1115	DR	1120	1500	1240	DR
1	0	0		595	675	645	725	600	630	605	685
1	0	1		975	758	1015	DR	660	985	1160	1500
1	1	0		745	920	880	1035	1010	830	855	1005
1	1	1		1235	1240	795	DR	1070	1110	DR	DR

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.