Frage Intel vs AMD (cyclictest)

[Peter_Pan123]

Hallo,

ich habe mir zum Test den neusten AMD Server (Shangai) zugelegt. Zu meinem erschrecken musste ich feststellen das irgendwie der cyclictest komplett andere Werte ausgibt als ein Intel Server. Hat jemand eine Idee woran es liegen kann > Kernel ist jeweils der 2.6.26er mit gleicher Config (nur Treiber etc angepasst).

Intel:
# ./cyclictest -a -t -n -p 99
0.52 0.40 0.46 1/199 14388

T: 0 (14381) P:99 I:1000 C: 7567 Min: 2 Act: 3 Avg: 2 Max: 8
T: 1 (14382) P:98 I:1500 C: 5045 Min: 1 Act: 2 Avg: 2 Max: 16
T: 2 (14383) P:97 I:2000 C: 3784 Min: 1 Act: 2 Avg: 2 Max: 5
T: 3 (14384) P:96 I:2500 C: 3027 Min: 1 Act: 2 Avg: 2 Max: 4
T: 4 (14385) P:95 I:3000 C: 2523 Min: 1 Act: 2 Avg: 2 Max: 6
T: 5 (14386) P:94 I:3500 C: 2162 Min: 2 Act: 2 Avg: 2 Max: 13
T: 6 (14387) P:93 I:4000 C: 1892 Min: 1 Act: 2 Avg: 2 Max: 9
T: 7 (14388) P:92 I:4500 C: 1682 Min: 2 Act: 2 Avg: 2 Max: 15

AMD:
# ./cyclictest -a -t -n -p 99
0.32 0.54 0.63 2/158 26674

T: 0 (26667) P:99 I:1000 C: 7449 Min: 5 Act: 7 Avg: 10 Max: 32
T: 1 (26668) P:98 I:1500 C: 4966 Min: 5 Act: 8 Avg: 10 Max: 39
T: 2 (26669) P:97 I:2000 C: 3725 Min: 5 Act: 9 Avg: 12 Max: 47
T: 3 (26670) P:96 I:2500 C: 2980 Min: 6 Act: 8 Avg: 9 Max: 24
T: 4 (26671) P:95 I:3000 C: 2483 Min: 6 Act: 15 Avg: 13 Max: 33
T: 5 (26672) P:94 I:3500 C: 2129 Min: 7 Act: 12 Avg: 14 Max: 39
T: 6 (26673) P:93 I:4000 C: 1863 Min: 7 Act: 13 Avg: 11 Max: 25
T: 7 (26674) P:92 I:4500 C: 1656 Min: 6 Act: 7 Avg: 12 Max: 36

Gruß

[storm]

Die rt-tools sind, wie der Name schon sagt, Werkzeuge für Tests zum realtime-Verhalten eines Systems. Du hast deine Tests bei leerlaufenden Systemen absolviert, was wenig Aussagekraft hat. Natürlich kann das schon sein, dass in diesem speziellen Fall das Intel-System schneller ist. Aber ich denke nicht, dass der Einsatzzweck der 8-Kern-Maschine das Warten auf Arbeit ist, oder? *g

Siehe auch hier:

Running cyclictest without creating appropriate real-time stress conditions is rather meaningless, since the execution of an asynchronous event from idle state is normally always quite fast, and every - even non-RT system - can do that. The challenge is to minimize the latency when reacting to an asynchronous event, irrespective of what code path is executed at the time when the external event arrives. Therefore, specific stress conditions must be created before cyclictest is executed to create a meaningful result of the worst-case latency of a given system.

Sieht allerdings das Verhältnis unter (ordentlicher) Last auch so aus, dann würd ich auch erschrecken. Was für Systeme sind das denn (also Hersteller/Boards/Speicher/etc.)?

Achso: und bitte nicht pi_stress zum Testen aufrufen ohne wenigstens mit --help die Argumente anzuschauen. Besser erstmal in den Kopf der Quelldatei schauen. Meine Kiste hier hat erstmal jegliche Kommunkation mit der Außenwelt eingestellt, als ich das gemacht hab. :/

ciao, storm

[omgwtfbbq]

Meine Kiste hier hat erstmal jegliche Kommunkation mit der Außenwelt eingestellt, als ich das gemacht hab. :/

Prozessor wird zu heiss ODER man hat zu sehr an der Taktzahl rumgedreht ODER es werden fehlerhafte Hardware-Treiber eingesetzt ODER die CPU ist defekt. Ein System darf in funktionierendem Zustand niemals "die Kommunikation einstellen" bzw. einfrieren, da ist definitiv was vermurkst

Deswegen benutzen Übertakt0r-Kiddies ja auch gerne Prime und Derivate davon: nur bei absoluter und möglichst kompletter Auslastung sieht man, ob das System funktioniert

Pan: Nimm ruhig Pi oder meinetwegen auch die Suche nach der Frage zur Antwort "43" - es spielt nur für die Art der Auslastung eine Rolle, optimalerweise stellt man sich selbst ein Komplettpaket zusammen