Archiv verlassen und diese Seite im Standarddesign anzeigen : PCI Busanbindung über Ethernet - Expertenfrage
Hallo zusammen,
ich bin momentan grad auf der Suche nach einer Möglichkeit zwei Rechner zu koppeln. Der Witz dabei ist, dass das ganze System modualr sein soll.
In der Grundvarainte gibt es ein relativ kleines, passiv gekühltes (und noch zu entwickelndes) Gerät mit Pentium M und ohne Erweiterungssteckplätze (eine Art Tablet PC) mit dem der Nutzer per Touchscreen interagieren kann.
In der Ausbaustufe kann dieses Grundmodul dann an einen größeren Rechner per Kabel "gekoppelt" werden in dem es etliche Erweiterungssteckplätze (PCI, evtl. PCIe) gibt, so dass man dann verschiedenste Karten wie Framegrabber oder RS232 Interfaces anbinden kann.
Die Frage ist nun:
Welche Verbindungstechnik zwischen den 2 Rechner Modulen wäre hier die beste? Gigabit Ethernet? Die mögliche Transferrate von brutto 125MB/s liegt ja im Bereich derer von PCI. D.h. wenn die GBit NICs auf beiden Seiten nicht auch am PCI hängen, müsste sich doch mit einer entsprechenden Softwarelogik auf beiden Seiten ein Paketstrom per UDP Protokoll über den Gigabit Link schleusen lassen, oder? Kann man sowas mit einer Verzögerung <100ms hinbekommen, dass man als Nutzer zwischen Befehlseingabe am kleinen Rechner und der Reaktion am großen Rechner nicht wirklich "hinterherhinkt"? Ich hab sowas schonmal mit dem VLC gemacht und es war nicht wirklich befriedigend...
Die Softwarelogik wäre dann sowas wie eine Relaisstation auf beiden Seiten, die die Paketierung macht und die Steuerbefehle (z.B. "Starte Capturing") an die PCI Karten übergibt.
Hat sowas schonmal jemand gemacht? Gibt es evtl. sogar kommerzeille Lösungen dafür? Gäbe es in euren Augen bessere Lösungen als Gigabit, z.B. Fibre channel, 1394b oder ganz andere?
Kann man evtl. sogar den PCI Bus über ein mehrere Meter langes Kabel nativ anbinden oder bekommt man da bei PCI mit Latenzen und Laufzeiten schon Probleme?
Für PCIe soll es ja den PCIe Cable Standard geben (ich glaub Demirughat da mal was in eienm Posting erwähnt); gibt es Bridges, die zwischen PCI und PCIe hin und her übersetzen können? ODer gibt es evtl. sogar für PCI einen ähnlichen Cable Standard?
Leider hab ich zu der ganzen Thematik im Netz wenig gefunden, d.h. für Links Anregungen und Hinweise wäre ich sehr dankbar!
Demirug
2005-06-24, 08:28:06
Da müsste man erst noch ein paar Details klären.
- Entfernung zwischen den beiden Systemen?
- So wie ich das verstehe verfügt das Erweiterungsystem ebenfalls über eine CPU, oder?
- Hast du beide Systeme die Kontrolle und bestimmst das Featureset?
- Du must zwingend fertige Komponenten nutzen oder besteht die möglichkeit von eigene Entwicklungen?
- Entfernung zwischen beiden Systemen wird max. im Bereich von 4-5m sein.
- ja, beide Systeme haben eine (x86) CPU, das eine Gerät ist auf niedrige Leistungsaufnahme getrimmt, evtl. sogar passiv gekühlt und stellt das Grundgerät dar. Über dieses Gerät habe ich hardwareseitig recht große Kontrolle, d.h. ich kann z.B. basierend auf einem ETX(Express) Modul recht frei bestimmen, was auf dem Baseboard drauf sein soll. Das ganze sollte unter XP embedded laufen, da die GUI Entwicklung und Userschnittstelle etc. auf der Windows API aufsetzt.
Das andere Gerät verfügt als 19" Rechner über grundsätzlich höhere Resourcen, also z.B. auch einen schnellen Prozessor oder viel Speicher. Ich denke da z.B. an eine P4 o.ä. SBC mit (PCI) Backplane, d.h. dieses Gerät kann ich zwar auswählen, aber nicht selber designen. Auch hier ist ein Windows OS von Vorteil, da die Treiber für die zahlreichen Komponenten oft auf Linux nicht exisiteren. Aber grundsätzlich wäre hier Linux oder ein Echtzeitbetriebssystem auch denkbar.
@Demirug: schonmal Danke im Voraus!
Demirug
2005-06-24, 11:31:51
Eine direkte physikalische PCI Bus Verlängerung ist unter diesen Vorraussetzungen nicht realisierbar. Daher müsste man die Funktionen auf logischer Ebene "verlängert" werden. Das wiederum verlangt eigentlich nach einer Service Orientierten Architektur. Da ich aber den kommerziellen Hintergrund sowie den Umfang des Projekts nicht kenne kann ich da schlecht weitere Vorschläge unterbreiten. Dabei wäre die Gefahr zu groß die Aufgabenstellung oder das Buget weit zu verfehlen.
@Demirug: Bis zu welcher max. Länge würde denn eine physikalische Busverlängerung zuverlässig (!) möglich sein, bezogen auf 32-Bit PCI (5V), 64-Bit PCI (3.3V) bzw. PCI Express bzw. wo ist da der Knackpunkt, dass die Länge ein so kritischer Faktor ist? Dämpfung der Signale? Laufzeiten/Latenzzeiten/Laufzeitunterschiede? Ich hab leider bisher mit Bussystemen kaum praktische Erfahrung, daher die Fragen!
Kennst Du grundsätzliche Ansätze, die per Bus-Verlängerung oder auch der angesprochenen Service orientierten Strategie schonmal getestet oder gar implementiert wurden?
Die Kosten sind im Moment zweitrangig, da ich erstmal schauen will, was es auf diesem Feld überhaupt gibt und wie die technischen Hintergründe aussehen. Daher wäre ich auch sehr dankbar über weiterführende Links und Ideen, da es hierzu wie gesagt wenig gute Infos im Netz gibt und Du aufgrund Deiner immer sehr kompetenten Postings bestimmt auch auf diesem Gebiet das nötige Hintergrundwissen hast ;-).
Kommerziellen Hintergrund gibt es im Moment nicht konkret, es handelt sich vielmehr um eine Abschätzung der Machbarkeit bestimmter Konzepte, um ein Rechnersystem zu modularisieren und dabei nicht auf Erweiterbarkeit zu verzichten.
Schonmal tausend Dank!
Demirug
2005-06-27, 11:09:57
Mit entsprechenden Verstärker Elementen ist ein PCI Bus durchaus verlängerbar.
Mir selbst sind zwei Lösungen dafür bekannt.
Über eine PCI Expansion kann der Bus in ein zweites Gehäuse verlängert werden. Die beiden Gehäuse sollten dafür allerdings direkt nebeneinader stehen. Das Verbindungskabel hat nicht die eingangs erwähnten 4-5 Meter. Zudem ist die Erweiterungunit passiv und verfügt über keine eigene CPU. Die Anbindung erfolgt über eine PCI Karte oder PCCardBus Karte.
Bei der zweiten mir bekannten Lösung wird in den eigentlichen PC eine PCI Karte eingebaut und eine Remote Station über Kat5 Kabel angebunden. Diese Remote Station ist passive. Enthält einen USB Controller, eine Soundlösung, sowie 1 oder 2 PCI Slots. Man muss aber auf jeden Fall eine Grafikkarte einbauen. Wir hatten das System schon einmal zu testen waren allerdings sehr unzufrieden mit der Performances.
In beiden Fällen sind die Lösungen aber nicht Hotplugfähig und die getrennte Verwendung ist nicht möglich.
Aufgrund der Aufgabenstellung tendiere ich nach wie vor dazu einen Service orientierten Strategie zu nutzen. Diese hat den Vorteil das man bei der Verbindungstechnik sehr modular bleibt. Nahezu alle Kabelgebundenen und Funktechniken sind denkbar. Für Aufgaben mit geringem Bandbreitenbedarf reicht dann auch durchaus Bluetooth oder ähnliches. Das ganze lässt sich auch leicht auf GPRS oder UMTS ausweiten. Ein weitere Vorteil besteht darin das sich n:m Verbindungen realisieren lassen. Also eine Arbeitsstation kann dann problemloss mehrer Remotesysteme in Anspruch nehmen oder ein Remotesystem kann seine Dienste auch mehr als einer Arbeitsstation zur Verfügung stellen. Realisiert habe ich so etwas in der Art schon einmal für ein System das noch alte ISA Karten zur Kommunikation einsetzten musste die Arbeitsstationen aber moderne PCs ohne ISA Karten waren. Das Konzept funktioniert aber mit jedem Bussystem. Problemmatisch wird es lediglich wenn die Software zwingend direkten Kontakt mit der Hardware braucht und man das ganze nicht virtualisieren kann. In der Regel ist das aber dann eher ein problem der Fehlenden Beschreibung des Interfaces zwischen Software und Hardware. Ist dieses Interface vorhanden kann in aller Regel der Software die Hardware als lokal vorhanden vorgetäuscht werden. In diesem Fall kann dann nur ein alzu strafes Timeing zu problemen führen. Kontrolliert man allerdings auf beiden Seiten die Software und kommt ohne Hardware abhängige Software von dritten aus entstehen diese Probleme nicht.
In Summe ist die Aufgabenstellung allerdings immer noch etwas unkonkret. Es fehlen informationen über mögliche Zielkunden sowie eine Ausarbeitung welche Vorteile sich gegenüber bereits eingeführten Lösungen (z.B. Nodebooks mit Doking Stations) ergeben.
Deine Aussagen decken sich auch mit meinen dürftigen Recherche Ergebnissen bzgl. PCI Bus Erweiterungen. Die oft angebotenen Riser Karten mit Flachbandkabel sind ja nicht sehr vertrauenserweckend, v.a da, wie Du schon sagst Hotplugging damit nicht geht und die PCI Kontaktkämme auch nicht für häufiges Ein-Ausstecken gebaut sind, ganz zu schweigen von möglichen ESD Problemen beim Berühren der (falschen) PCI Kontakte.
Bevor ich die Service orientierte Architektur favorisiere noch eine Frage, ich hoffe Du kannst mir da weiterhelfen:
Wie steht es mit dem PCIe Cable Standard? Hotplug etc. dürfte damit ja eigentlich gehen.
Wie sieht es mit PCIe<->PCI Bridges aus (z.B. die Genesys Logic PCI-PCIe-Bridge GL9701 GigaCourier /SFO), gibt es damit schon Erfahrungen, ob die transparent arbeiten, d.h. dass eine darüber angebundene PCI Karte gar nicht merkt, dass die Übersetzunge PCI<->PCIe<->PCI stattgefunden hat? Immerhin unterscheiden sich PCIe und PCI doch gewaltig, allein schon wg. der parallel-seriell Umsetzung? Kann über EINE PCIe Lane eine PCI Bridge mit z.B. FÜNF PCI ports überhaupt betreiben, oder braucht es da für jeden PCI Slot eine separate PCIe Lane, da ja PCI Express als Punkt-zu-Punkt geschaltet wird und kein richtiger, "klassischer Bus ist"? Oder ist die PCI-PCIe Bridge so intelligent und kann mehrer PCI Ports an einer PCIe Lane verwalten?
Demirug
2005-06-27, 13:19:38
Bevor ich die Service orientierte Architektur favorisiere noch eine Frage, ich hoffe Du kannst mir da weiterhelfen:
Wie steht es mit dem PCIe Cable Standard? Hotplug etc. dürfte damit ja eigentlich gehen.
Wie sieht es mit PCIe<->PCI Bridges aus (z.B. die Genesys Logic PCI-PCIe-Bridge GL9701 GigaCourier /SFO), gibt es damit schon Erfahrungen, ob die transparent arbeiten, d.h. dass eine darüber angebundene PCI Karte gar nicht merkt, dass die Übersetzunge PCI<->PCIe<->PCI stattgefunden hat? Immerhin unterscheiden sich PCIe und PCI doch gewaltig, allein schon wg. der parallel-seriell Umsetzung? Kann über EINE PCIe Lane eine PCI Bridge mit z.B. FÜNF PCI ports überhaupt betreiben, oder braucht es da für jeden PCI Slot eine separate PCIe Lane, da ja PCI Express als Punkt-zu-Punkt geschaltet wird und kein richtiger, "klassischer Bus ist"? Oder ist die PCI-PCIe Bridge so intelligent und kann mehrer PCI Ports an einer PCIe Lane verwalten?
Laut dem Standard sollten die Bridges transparent sein. Die Umwandlung zwischen parallel-seriell sowie zwischen Bus und P2P sollte auch kein Problem sein.
Allerdings befürchte ich bei einer solchen Lösung denoch gewissen Hotplug Probleme. Das PCIe Cabel ist dafür zwar ausgelegt allerdings dürften es einige PCI Geräte Treiber übel nehmen wenn man ihnen die Karte plötzlich wegnimmt.
Eine Sache die man dann auch noch berücksichtigen muss ist das die Station mit den Karten wieder passiv ist. Die Rechenleistung der Arbeitsstation muß dann auch für den Betrieb der zusätzlichen Karten ausreichen.
Die Tatsache mit der fehlenden Hotplug Fähigkeit bei PCI bzw. den Treibern ist natürlich ein Argument wobei man im worst case halt dann die Restriktion einführen muss, dass eben nur im abgeschalteten Zustand verbunden/abgekoppelt werden darf.
Das Argument mit der mangelnden Rechenleistung der kleinen Maschine, um den ganzen Baum an Geräten zu bedienen ist natürlich richtig.
Das bringt mich zu einem verwandten Thema: Wie sieht es denn generell mit "verteiltem" Rechnen aus? Wenn ich einen parallelisierbaren Job habe, sollte es doch im Idealfall möglich sein, ihn am Anfang zu zerlegen und einen großen Teil der zweiten, 'dicken' Maschine per Ethernet zum Rechnen zu geben, die dann am Ende die Ergebnisse zurückliefert. Kann Windows sowas (bei Linux gibt es ja die Cluster), wahrscheinlich eher nicht...
Das Problem wird halt sein, dass sich Prozesse
a) oft nicht vernünftig zerlegen lassen (wg. Abhängigkeiten)
b) bei kleinen Prozessbröckchen die Synchronisation per Ethernet mehr Zeit verschlingt als die Parallelisierung gewinnt. Gibt es für solche Cluster eigentlich noch schnellere Verbindungen als Ethernet, die praktisch eingesetzt werden, um z.B. 2 oder 4 x86-Maschinen zu koppeln?
Demirug
2005-06-27, 17:43:13
Das bringt mich zu einem verwandten Thema: Wie sieht es denn generell mit "verteiltem" Rechnen aus? Wenn ich einen parallelisierbaren Job habe, sollte es doch im Idealfall möglich sein, ihn am Anfang zu zerlegen und einen großen Teil der zweiten, 'dicken' Maschine per Ethernet zum Rechnen zu geben, die dann am Ende die Ergebnisse zurückliefert. Kann Windows sowas (bei Linux gibt es ja die Cluster), wahrscheinlich eher nicht...
Es gibt eine spezielle Windows Version für Cluster. Im Prinzip kann man aber mit jedem OS einen Cluster bauen. Die Syncronisation ist ja eine reine Softwaresache die man auch auf der Ebene der Anwednungssoftware lösen kann.
Das Problem wird halt sein, dass sich Prozesse
a) oft nicht vernünftig zerlegen lassen (wg. Abhängigkeiten)
b) bei kleinen Prozessbröckchen die Synchronisation per Ethernet mehr Zeit verschlingt als die Parallelisierung gewinnt. Gibt es für solche Cluster eigentlich noch schnellere Verbindungen als Ethernet, die praktisch eingesetzt werden, um z.B. 2 oder 4 x86-Maschinen zu koppeln?
Es gibt durchaus schnellere Kommunikationssysteme. Allerdings muss man sich da immer die Preis/Leistungs Frage stellen.
Langsam wird die Sache hier aber etwas esoterisch. Geht es jetzt darum spezielle Hardware (um was es sich dabei auch immer handelt) vorzuhalten oder soll Rechenleistung bei Bedarf zur Verfügung gestellt werden?
Es geht nach wie vor hauptsächlich um die Anbindung von Peripherie, d.h. keine esoterischen Phantasien ;-). Die Geschichte mit den Clustern war nur eine Idee wg. der begrenzt verfügbaren Rechenleistung im Client PC, und ob man die theoretisch auch erhöhen könnte. Wäre natürlich schön, aber das wird wg. der mangelnden Parallelisierbarkeit der Algorithmen eh nicht funktionieren, leider...
Demirug
2005-06-27, 18:09:10
Es geht nach wie vor hauptsächlich um die Anbindung von Peripherie, d.h. keine esoterischen Phantasien ;-). Die Geschichte mit den Clustern war nur eine Idee wg. der begrenzt verfügbaren Rechenleistung im Client PC, und ob man die theoretisch auch erhöhen könnte. Wäre natürlich schön, aber das wird wg. der mangelnden Parallelisierbarkeit der Algorithmen eh nicht funktionieren, leider...
Das hängt von der Art der Arbeiten ab die erledigt werden sollen. Ich hatte mal experimentel einen Imagefilter Dienst gebaut. Dabei hat der schwache Client das Bild und die Filterinformationen an den Server geschickt und das bearbeitete Bild zurück bekommen. Das ganze ist aber eher für Dinge interesant die keine direkte Interaktivität verlangen.
Genau das meinte ich, denn sobald über den Bus zuviel zwischen den beiden Maschinen synchronisiert werden muss wird der Gewinn der Lastaufteilung schnell aufgefressen und das wäre bei meiner Appliaktion wohl der Fall. Aber Yonah/Sossaman kommt ja aller Voraussicht nach nächstes Jahr, dann hat man ja die Kraft der 2 Kerne schon im mobilen Rechner und braucht zumindest zum Rechnen keine zusätzlichen Workstation ;-).
Ich danke Dir auf alle Fälle für den sehr konstruktiven Input! Ich werde jetzt mal weiterschauen, was man konkret machen kann. Wenn es Neuigkeiten gibt, melde ich mich wieder!
Danke
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.