Netzwerkkarte mit Puffer

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.

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.

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:
> 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.

Wenn man Probleme kriegen will, die man andernfalls nicht hätte, nimmt 
man Jumbo Frames.

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.

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.

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.

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.