[Hardware] APU.1C/D (PCEngines) Fakten und Erfahrungen

JeGr

Ebenfalls wieder meines (Un)Wissens nach ist die SSD von PCengines nicht langsam, sondern lediglich in Kompatibilität mit der APU gerade rausgenommen worden. Sprich die mSATA SSD ist momentan nicht kompatibel mit der APU (da war was mit AHCI vs. ATA Port etc. blafasel und DMA Schreib Timeouts). Da ich aber nicht weiß ob du von mSATA oder echtem SATA redest, ist das recht ungenau.

Gruß

PCengines hat eine mSATA SSD im Shop zur Auswahl. Ich habe danach gegoogelt und dort stand in den Reviews, dass man eine andere SSD wählen sollte. Dann habe ich eine Kingston gefunden und dort stand, dass Kingston nicht gut sei (was SSDs betrifft).

Daher meine Frage nach einer Empfehlung für das APU-System.

JeGr

Meines Erachtens nach ist das Vergleichen von Geschwindigkeiten von SSDs bei pfSense o.ä. Sachen totaler Unfug.

Warum? Weil das System genau 1x bootet (im Optimalfall). Das geht von SSD eh schon schneller als SD oder CF Karten (oder lausigen USB Sticks). Ansonsten werden Logs geschrieben oder ähnlich kleine Dateien. Nirgends auf der pfSense gibt es Datenmengen (mal vom Extremfall von Squid mit Videocache abgesehen), die so groß sind, dass es so extrem darauf ankäme, dass das Device die SSD auch ausreizen kann. Meistens ist die "lahmste" SSD trotzdem noch ein vielfaches Schneller als das war im Normalfall abgerufen wird.

Das Einzige was mit "gut oder nicht so gut" wirklich betitelt werden könnte ist eben, ob die SSD mit dem System zusammenspielt. Da kommt es lediglich darauf an, ob wir von normalem SATA Bus reden (da dürfte es recht egal sein) oder mSATA. Und bei letzterem gibt es m.W.n. eh kleinere Probleme bei der APU, sonst hätte der Hersteller (pcengines) nicht seine eigene msata SSD für die APU momentan auf inkompatibel gesetzt. Ich muss mal den Post hier rauskramern aber im englischen Teil stand dazu erst was.

Grüße

Mir geht es genau um den letzten Punkt den du angesprochen hast. Die Geschwindigkeit ist zweitrangig. Mir geht es um das Zusammenspiel und die Zuverlässigkeit.

"msata16a on shipment hold. Some customer reported problems leading to data loss, e.g. with Sophos UTM. We suspect that it is related to the TRIM function included in modern file systems (e.g. Linux EXT4).
We have finally received a firmware update from our supplier. Customers may return modules to us for firmware reprogramming (data is lost), or for full credit.

Modules reprogrammed by us can be recognized by a + mark on the label." (von pcengines.ch). Demnach liegt es an der Firmware der SSD selbst und nicht grundsätzlich an mSATA (zumindest verstehe ich das so).

JeGr

Da es in den pcEngines Foren aber generell um mehrere PCIe mSATAs geht, würde ich eher die Firmware/BIOS der APU beäugen:

http://www.pcengines.info/forums/?page=post&id=E28DC941-B196-4F3B-A359-526BE6133450
http://www.pcengines.info/forums/?page=post&id=ABA956D4-4B76-4002-9BBE-DAC78DFFE22E

Bei der msata16 scheint es evtl nur um TRIM zu gehen, es gibt aber auch Fälle bei denen TRIM disabled war. Ansonsten las ich dort schon von anderen Usern mit APUs und Kingston mSATA SSDs die problemlos liefen. Es hängt wohl momentan auch von der APU Firmware ab.

Zitat von PCengines:

Problem mit dem SSD-Controller bzw. dessen Firmware.

Mit msata16a gab es Probleme, bei msata16b wurde in der Firmware die
TRIM-Funktion abgeschaltet.

Inzwischen verwenden wir einen anderen Controller, Phison statt
Skymedi, und es herrscht Ruhe…

JeGr

@Ben: Bitte mal alles lesen, was ich schreibe. Dein Zitat bezieht sich nur auf die generellen Probleme der msata16a. Die hatte generell ein Problem mit TRIM. Was ich sage ist, dass es mehrere andere mSATA Devices gibt, mit der die APU je nach BIOS/Firmware Version ebenfalls Probleme zu haben scheint, und es mehr als einmal nun im Gespräch war, ob SAGE, der Lieferant der Firmware bzw. des BIOS da was vergeigt hat (was niemand wundern würde nach der bisherigen Performance…)

Bitte verstehe meine Kommentare nicht als Gegenaussagen zu deinen, sondern als Ergänzungen zu diesem Thema.

JeGr

Kein Problem, ich wollte nur für die Mitleser des Themas darlegen, dass es mit dem Bios/FW der APU wohl hie und da etwas hakt, auch im Zusammenhang mit mSATA SSDs und das nicht (nur) an der SSD liegt/liegen muss :)

trollmar

Hi,
super Thread!!

Hat jemand Erfahrungen was mit dem Apu1d4 board an OpenVPN durchsatz zu erwarten ist?
Ich habe irgendwo gelesen das zumindest bei IPSec ungefähr 50Mbit drin sind.
Hat da schon jemand Erfahrungen sammeln können?

Stroker

Also ich hab seit 2 Wochen das APU1D4, einer Kingston 30gb mSATA SSD und pfSense 2.1.5 am laufen.
Außer dass ich Anfangs nur zwei der drei Interfaces gesehen habe, was nachdem ich das Board eingeschickt habe auf magische Art und Weise behoben wurde, läuft alles wie geschmiert.

Probleme hatte ich bisher nur mit manchen Konfigurationen, was aber alles auf meine Unwissenheit zurück zu führen war.
Zum OpenVPN Durchsatz kann ich momentan leider relativ wenig sagen, da die Kiste leider nur an einem 16 Mbit ADSL Anschluss hängt :(.
Die Gegenseite ist leider virtualisiert, sodass sich auch hier keine aussagekräftigen Ergebnisse liefern lassen.

Gruß

blessing

Aus den Spezifikationen gehen keine Änderungen zwischen APU.1C und APU.1D hervor. Gleicher Prozessor, gleicher Speicher, gleiche Schnittstellen…

Weiß jemand worin der Fortschritt liegt?

GruensFroeschli

http://www.pcengines.ch/apu1d.htm

Revision notes:
• No stuff J12 SPI header to allow easier 2.5" SSD installation.
• Change bias supply for U7 VMEM / VTT regulator to V5A to fix suspend/resume support.
• Add CE, FCC symbols.

FireBurnsHot

@trollmar:

Hi,
super Thread!!

Hat jemand Erfahrungen was mit dem Apu1d4 board an OpenVPN durchsatz zu erwarten ist?
Ich habe irgendwo gelesen das zumindest bei IPSec ungefähr 50Mbit drin sind.
Hat da schon jemand Erfahrungen sammeln können?

Das würde ich auch ganz gerne wissen. Kann dazu jemand etwas sagen ? 50Mbit sind eigentlich recht wenig für mich (bei OpenVPN werden es ja weniger sein)

JeGr

50Mbit sind eigentlich recht wenig für mich (bei OpenVPN werden es ja weniger sein

Für welchen Anwendungsfall? 50MBit/s encrypted traffic ist schon ganz erheblich. Es gibt eigentlich nicht viel Szenarien wo man das braucht ohne dass man ganz andere Hardware Dimensionen berücksichtigen sollte (DC<->DC Backbone Connection bspw.)
Und weshalb sollte es da mit OpenVPN weniger sein?

FireBurnsHot

Im Moment habe ich eine 50er Leitung und da würde mir in der Tat 50 reichen, nur kaufe ich mir ungern Hardware um die dann ein halbes Jahr später in die Tonne zu schmeißen weil sie underspect ist.

Mein Verständnis war immer, dass OpenVPN SSL VPN und daher mehr Ressourcen verbraucht als IPSec VPN. Deshalb meine Aussage, wenn IPSec nur 50Mbit schafft wird OpenVPN weniger "durch lassen". bzw. die Hardware nur weniger Durchsatz schaffen.

Da ich im Moment 99,9% meines Traffic durch den VPN Tunnel schicke, würde ich ungern bei einer 50er (später vielleicht 100er) Leitung nur ein 30er Tunnel aufbauen, bei dem der CPU mir fast abbrennt weil er ständig auf 100% läuft, verständlich, oder ?

Daher die Fragen ob schon jemand was zum Durchsatz sagen kann.

JeGr

dass OpenVPN SSL VPN und daher mehr Ressourcen verbraucht als IPSec VPN

Nö, so pauschal kann man das nicht sagen, da auch OpenVPN inzwischen genau wie IPSec von Hardware Crypto profitieren kann und nicht so sehr unter Performance leidet wie man ihm gerne nachsagt. Ich bin aber nicht 100% up2date was die Implementation von OpenVPN und IPSec unter 2.2 bringen wird in Bezug auf die APU. Bei Geräten die AES-NI bspw. unterstützen wird ein gehöriger Leistungsschub erwartet.

Da ich im Moment 99,9% meines Traffic durch den VPN Tunnel schicke, würde ich ungern bei einer 50er (später vielleicht 100er) Leitung nur ein 30er Tunnel aufbauen, bei dem der CPU mir fast abbrennt weil er ständig auf 100% läuft, verständlich, oder ?

Nunja ob ich es verständlich finde, 99% des Traffics durch VPN zu pulsen - nein, finde ich nicht. Aber das ist deine Sache. Ich würde es ggf. verstehen, wenn man damit bspw. ein Datacenter-grade Backbone baut und somit den Traffic innerhalb aller Datacenter nur verschlüsselt laufen lässt. Aber für privat halte ich 99,9% des Traffics über irgendein VPN zu fahren für unsinnig. Persönliche Meinung. Anyway.

Dann wirst du aber auch mit einer APU nicht glücklich werden und brauchst entsprechend Hardware, die auch Hardware Crypto Beschleunigung unterstützt (AES-NI o.ä.) und da fängt es sinnvoll bei sowas wie einem C2000er Atom an (C2758 bspw.). Der hat dann genug Power um nicht nur 100, sondern sogar aktuell bis zu 200MBit/s verschlüsselt per OpenVPN zu schicken. Mit dem neuen Release 2.2 wird er mit einigen Tweaks vielleicht sogar Richtung Gigabit kommen.

Gruß

FireBurnsHot

Danke für die ausführliche Erklärung ! 8)

Ich schau mich mal um, aber werde wohl erstmal bei meinem Desktop hängen bleiben.

hornetx11

Moin liebe Mitstreiter,

es war sehr interessant den Beitrag zu lesen.

Eine Frage stellt sich mir aber doch.
@JeGr

Du schriebst:

@JeGr:

… und da fängt es sinnvoll bei sowas wie einem C2000er Atom an (C2758 bspw.). Der hat dann genug Power um nicht nur 100, sondern sogar aktuell bis zu 200MBit/s verschlüsselt per OpenVPN zu schicken. Mit dem neuen Release 2.2 wird er mit einigen Tweaks vielleicht sogar Richtung Gigabit kommen.

Ist der C2758 wie z.B. auf einem Supermicro A1SRi-2758F, abgesehen vom single PF, für den produktiven Einsatz mit einer Standard Version (2.1.5) und den Anpassungen in der /boot/loader.conf.local aus Tuning and Troubleshooting Network Cards

kern.ipc.nmbclusters="131072"
hw.igb.num_queues=1
hw.igb.fc_setting=0

einsetzbar?

Hier im Forum finde ich recht widersprüchliche Aussagen.

MfG

JeGr

Wir haben das genannte Board bzw. die Appliance von Supermicro laufen (als primary) und eine APU als Backup Device und fahren darüber einen gerouteten Gigabit Link. Der ist zwar sicher nicht immer voll ausgelastet, aber bislang hatten wir mit dem Gerät bis auf die Startschwierigkeiten, die man mit dem Troubleshooting Settings umgeht, keine Probleme. Und im Cluster mit der APU haben wir wenigstens noch ein halbwegs kräftiges Gerät als Fallback.

Grüße