Gibt es Netzwerkkarten mit einem Empfangspuffer, der vielleicht wie ein FiFo funktioniert und mehrere Pakete zwischenspeichern kann?
Der Sinn davon? Latenz erhöhen? Dürfte vermutlich per Software einfacher gehen.
Carlos schrieb: > Gibt es Netzwerkkarten mit einem Empfangspuffer Gibt es auch welche ohne? Da du in PC Hard and Soft fragst gehe ich mal davon aus das du nicht irgend so eine µC Spielzeug meinst sondern eher ausgewachsene Netzwerkkarten. Schau dir doch einfach mal die Beschreibungen der Hersteller der Chips an. Z.B.: http://www.intel.com/content/www/us/en/embedded/products/networking/ethernet-x550-datasheet.html Dort z.B. mal nach "Packet Buffer" und "Queues" suchen
Das machen viele Intel und Mellanox Ethernet PHYs (z.B. i350). Dabei nutzen sie aber keinen internen Speicher sondern via DMA den RAM des PCs (DMA Coalescing). Das reduziert die Interrupt-Last (Interrupt Moderation) erhöht aber die Latenz.
Timmo H. schrieb: > Das machen viele Intel und Mellanox Ethernet PHYs (z.B. i350). Na die PHYs eher nicht, sondern die Controller.
Vielen Dank für Eure Antworten. Reinhard S. schrieb: > Der Sinn davon? Ich will zwischen zwei Computern Daten per UDP austauschen. Dabei soll ein PC kontinuierlich im 5kHz-Takt Daten an einen Empfangsrechner senden. Es könnte ja vorkommen, dass der Empfangsrechner gerade noch am Auslesen eines Datenpakets beschäftigt ist und das neue Paket dann verloren gehen würde. Irgend W. schrieb: > Gibt es auch welche ohne? Das weis ich nicht. Irgend W. schrieb: > Dort z.B. mal nach "Packet Buffer" und "Queues" suchen Das werde ich mal machen. Ich wusste nicht, nach welchen Stichworten ich schauen muss.
Carlos schrieb: > > Ich will zwischen zwei Computern Daten per UDP austauschen. Dabei soll > ein PC kontinuierlich im 5kHz-Takt Daten an einen Empfangsrechner > senden. Es könnte ja vorkommen, dass der Empfangsrechner gerade noch am > Auslesen eines Datenpakets beschäftigt ist und das neue Paket dann > verloren gehen würde. > Was für Computer sind das? welchen Umfang haben die Daten? Welche Rechenlast verursacht die Auswertung? Muß es UDP sein und wieviel Bandbreite steht der Anwendung am Netzwerk zur Verfügung? Selbst wenn Du Puffer hast - wenn Dein Auswertungssystem nicht in der Lage ist diese Datenpackerl binnen 0,2ms zu verarbeiten helfen Dir all die Puffer nicht das zeitliche Dilemma zu lösen, denn dann laufen halt die Puffer voll, der Stau wird quasi länger.... iaW: Wenn da Probleme sind dann hilft Dir nur mehr Rechenleistung, egal ob das durch bessere Software oder schnellere Prozessoren geleistet wird. Viel Erfolg
MiWi schrieb: > Wenn da Probleme sind dann hilft Dir nur mehr Rechenleistung, Das sollte man noch komplexer sehen. Man sollte den Flaschenhals finden. Selbst wenn die Netzwerkkarte pfleilschnell ist, kann auch die Datenbank oder das Excel gähnend langsam funktionieren weil z.B. RAM fehlt oder andere Prozesse bremsen ...
Carlos schrieb: > Gibt es Netzwerkkarten mit einem Empfangspuffer, der vielleicht wie ein > FiFo funktioniert und mehrere Pakete zwischenspeichern kann? Das tun sie alle, ob auf dem Adapter oder im RAM. Die Operationen zwischen Adapter und Treiber werden durch Programmaktivitäten auf Anwendungsebene nicht behindert. Auch der Network-Stack des Betriebssystems läuft unabhängig davon. Carlos schrieb: > Es könnte ja vorkommen, dass der Empfangsrechner gerade noch am > Auslesen eines Datenpakets beschäftigt ist und das neue Paket dann > verloren gehen würde. Netzwerkadapter und Betriebssysteme arbeiten nicht so primitiv, wie du dir das vorstellst. Mach dir diesbezüglich keine Sorgen.
:
Bearbeitet durch User
MiWi schrieb: > Was für Computer sind das? Es ist ein etwas älterer PC, der mehrere analoge Messkarten eingebaut hat, die leider nicht mehr in einen neuen PC reinpassen. Genaue Bezeichnung muss ich an der Arbeit raussuchen, das weis ich grad nicht genau, der Rechner ist irgendwie aus den Jahren 2005/2007. Der Empfangsrechner ist ein "moderner" PC. Der ältere PC arbeitet im 5kHz-Takt und liest dabei die Werte von den Messkarten aus. Ich möchte diese Werte dann an den anderen Rechner weiterleiten über Netzwerk. Die anfallende Datenmenge ist 64x 16bit - also 128 8bit-Zeichen im UDP-Diagramm. Die beiden Rechner sollen direkt miteinander verbunden werden und nicht über ein großes Netzwerk, wo z.B. auch Computer aus den Büros mit dranhängen. Ich habe deshalb in den Empfangscomputer auch eine zweite Netzwerkkarte eingebaut. Das Versenden der Daten funktioniert bis jetzt problemlos, ich hatte nur Angst, wenn vielleicht der Empfangsrechner mal zu langsam sein könnte, dass er dann ein Datenpaket verpasst.
Hallo Carlos, man kann das doch mal überschlägig ausrechnen: Du willst mit 5 kHz oder alle 200 ns ein UDP-Paket versenden. Ein UDP-Paket wird in einem Ethernet-Frame verpackt. Dieser darf brutto bis zu 1500 Bytes lang sein, das sind 12000 einzelne Bits. Bei Fast Ethernet (100 MBit) dauert ein einzelnes Bit 0,01 ns, der Brutto-Frame ist also ca. 120 ns lang. Jedes UDP-Paket wird also während 60% der verfügbaren Übertragungszeit das Medium für sich beanspruchen. Das "riecht" bei Ethernet schon sehr nach Sättigung und wird wohl höchstens noch funktionieren, wenn Deine Applikation die Ethernetverbindung exclusiv nutzt. Bei Gigabit-Ethernet wären es nur noch 6%. Das klingt schon realisierbarer.
A. K. schrieb: > Netzwerkadapter und Betriebssysteme arbeiten nicht so primitiv, wie du > dir das vorstellst. Mach dir diesbezüglich keine Sorgen Ok, ich könnte das vielleicht einfach mal mit Rampen austesten und das System so für mehrere Stunden laufen lassen, ob es dann überhaupt zu Aussetzern kommt. Ich hatte halt diesbezüglich Angst.
Carlos schrieb: > Die beiden Rechner sollen direkt miteinander verbunden werden und nicht > über ein großes Netzwerk, wo z.B. auch Computer aus den Büros mit > dranhängen. Ich habe deshalb in den Empfangscomputer auch eine zweite > Netzwerkkarte eingebaut. Das Versenden der Daten funktioniert bis jetzt > problemlos, ich hatte nur Angst, wenn vielleicht der Empfangsrechner mal > zu langsam sein könnte, dass er dann ein Datenpaket verpasst. Tips: 1. Gigabit-Ethernet-Karten auf beiden Seiten reinstecken 2. "Jumbo Frames", d.h. große Pakete aktivieren, die dann bis zu 9k groß sein können (normal sind 1500 Bytes) 3. In Deiner Software die Daten so weit sammeln, dass Du möglichst große und dafür möglichst wenig Pakete sendest. Deswegen auch die Jumbo Frames. Wenn Du einen Switch verwendest, muss der natürlich auch Jumbo Frames können. Ansonsten einfach direkt ein Netzwerkkabel verwenden und beide Karten fest auf 1G einstellen (nicht auto). Damit holst DU das Maximum aus der Übertragungsstrecke raus. fchk
scoota schrieb: > Du willst mit 5 kHz oder alle 200 ns so schnell bin ich dann auch nicht :-) - ich glaub, es sind 200.000 ns scoota schrieb: > Dieser darf brutto > bis zu 1500 Bytes stimmt, und ich nutze davon ja grad mal 128 dann. Ich habe sogar Gigabit-Netzwerkkarten verbaut.
scoota schrieb: > Jedes UDP-Paket wird also während 60% der verfügbaren Übertragungszeit > das Medium für sich beanspruchen. Das "riecht" bei Ethernet schon sehr > nach Sättigung und wird wohl höchstens noch funktionieren, wenn Deine > Applikation die Ethernetverbindung exclusiv nutzt. Ehrlich? Ich hätte mit Sättigungs-Symptomen frühstens ab 80% gerechnet.
Frank K. schrieb: > 3. In Deiner Software die Daten so weit sammeln, dass Du möglichst große > und dafür möglichst wenig Pakete sendest. Deswegen auch die Jumbo > Frames. cool. Ich könnte ja auch z.B. über mehrere Zyklen Daten dann sammeln und z.B. nur bei jedem 10. Taktzyklus dann ein Datenpaket an den Zielrechner schicken, um den Traffik zu verringern.
Wenn man Probleme kriegen will, die man andernfalls nicht hätte, nimmt man Jumbo Frames.
Carlos schrieb:
>so schnell bin ich dann auch nicht :-) - ich glaub, es sind 200.000 ns
Oops. Gleich um 3 Zehnerpotenzen daneben. Hatte hier nur einen einfachen
Taschenrechner und bin noch nicht lange wach...
Aber somit extrem günstig für Dein Problem :-)
Beitrag #6091402 wurde vom Autor gelöscht.
Je mehr Daten man in einen Frame packt, desto mehr Daten sind weg, wenn er nicht intakt ankommt. Das ist bei sauberer Physik zwar unwahrscheinlich, aber rechnen sollte man damit schon.
:
Bearbeitet durch User
Die Jumbos sind seit vielen Jahren Standard und laufen in zigtausenden Applikationen 24*7 mit Datenraten am Ethernet Limit, Stichwort GigE Vision. Man muss eben passende Komponenten wählen die auch die Jumbos weiterleiten können oder Punkt zu Punkt verbinden.
Gibt es denn bei dir konkret ein Problem mit dem Packetloss? Ich sehe da eher weniger ein Problem. Dass generell auch mal Pakete ausfallen können, ist unabhängig von der Last natürlich immer zu beachten. UDP erkennt sowas nicht und macht keine Retransmits. Wenn also auf jeden Fall alle Daten sicher ankommen müssen, muss man sich da entweder selbst was stricken oder auf TCP umsteigen, das sich automatisch darum kümmert. Das kümmert sich auch automatisch darum, die Daten in Pakete zu zerteilen und wieder zusammenzusetzen.
:
Bearbeitet durch User
Rolf M. schrieb: > Das kümmert sich auch automatisch darum, die Daten in Pakete zu > zerteilen und wieder zusammenzusetzen. ... und da beginnt so richtig die Arbeit für den Empfänger. Der weiss nämlich erst mal nicht wann ein Paket vollständig ist. Ich habe gehört dass TCP ein Stream ist, ohne Ende, das muss sich der "Benutzer" antun.
Johannes S. schrieb: > ... oder Punkt zu Punkt verbinden. Eben. Es gab eine Zeit, in der Jumbos ein Thema waren. Und es mag sorgfältig abgekoppelte Netze geben, in den das auch heute noch sinnvoll ist. Wenn man allerdings heute normale Netze baut, dann lohnt das i.d.R. nicht. Es gab zwei Motive dafür: Die paar Prozent mehr, die man aus dem Netz holt und die Rechnerlast. Letzteres wird in den dafür üblichen Anwendungen bereits vom Adapter besser erledigt, als Jumbo Frames das je könnten. Ethernets kommunizieren seit langem gerne mit 64kB Frames zwischen Treiber und Adapter, in beiden Richtungen. Aber da die Durchsatzfrage sich in Luft aufgelöst hat, ist das hier kein Thema.
:
Bearbeitet durch User
Hopperla schrieb: > Rolf M. schrieb: >> Das kümmert sich auch automatisch darum, die Daten in Pakete zu >> zerteilen und wieder zusammenzusetzen. > > ... und da beginnt so richtig die Arbeit für den Empfänger. Der > weiss nämlich erst mal nicht wann ein Paket vollständig ist. Ähm, wenn jedes Paket gleich groß ist, würde ich nicht von "so richtig Arbeit" sprechen. Du nimmst dann einfach Häppchen von so vielen Bytes und verarbeitest die. > Ich habe gehört dass TCP ein Stream ist, ohne Ende, das muss > sich der "Benutzer" antun. Bei UDP muss er sich antun, zu erkennen, ob jedes Paket auch angekommen ist, ob sie in der richtigen Reihenfolge angekommen sind u.s.w. Dazu muss er sich erstmal Paketheader ausdenken, die der Sender befüllen muss und anhand derer der Empfänger erkennt, ob es passt. Dann muss dieser eine entsprechende Antwort-Nachricht erzeugen, mit der er dem Sender zurückmeldet, ob alles angekommen ist oder was fehlt, damit dieser ggf. die Daten nochmal senden kann. Und das möglichst so, dass der Sender nicht immer sofort aufhören und warten muss, bis die Antwort vom Empfänger kommt. Das ist 100 mal so viel Arbeit wie das Aufteilen der Datenblöcke bei Verwendung von TCP.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.