Hallo, zurzeit bereite ich gerade mein Thema für meine Bachelorarbeit vor, welches die Entwicklung eines hardwarebasierten Lastgenerators für Internet-Protokolle sein soll. Dabei stellt sich für mich die Frage, ob dieses überhaupt mit meinen Vorstellungen und Vorgaben realisierbar ist. Im Enddefekt soll zunächst ein einfacher Lastgenerator mit einem FPGA-Board realisiert werden, der möglichst schnell (am besten 10GBps) vorher gespeicherte Pakete über Ethernet „rausbläst“. Da meine Hochschule eine natürlich kosten günstige Realisierung bevorzugt, haben meine Recherchen ergeben, dass für hohe Geschwindigkeiten vorgesehene Boards sehr teuer sind, deshalb wäre meine Idee einen 10_GB-PHY-Chip (z.B. von Broadcom BCM84823) über einen fertigen Core von Xilinx(http://www.xilinx.com/products/intellectual-property/XAUI.htm) anzusteuern, der aufSpartan-6-LXT-FPGAs mit GTP-Schnittstelle läuft und ca. 100 Euro kostet.(http://www.xilinx.com/products/intellectual-property/XAUI.htm) Hat jemand vielleicht schon einmal ähnliches versucht, oder weiß ob so etwas mit einem selbst designten Board überhaupt funktionieren kann? Desweiteren wollte ich fragen, ob es überhaupt möglich ist einen einzelnen PHY-Chip zu kaufen? Würde mich über Hilfe sehr freuen!
Steht in eurer Uni nicht ein ungenutzter Rechner rum, der sich einspannen lässt? Ist aus meiner Sicht sehr viel einfacher, den als "Lastgenerator" zu verwenden, als die Hardware selber zurechtzusuchen...
Naja, schau dir das DE2-115-Board von Altera an, da sind bereits zwei betriebsfertige Gigabit-Schnittstellen drauf aufgebaut. Und dort sind dann entsprechend zwei nackte PHY verlötet, sodass du MAC aufwärts im FPGA konstruieren kannst. Das Board kostet für Educational irgendwo um 200 Euro. Alternativ guck dich auf diversen Netzwerkkarten um, ein IDE-Bus ist durchaus zu bewältigen. Mit 10GB/s wirds dann aber schon etwas eng. 10GB/s wird überhaupt ziemlich eng. Da musste schon ordentlich was vorlegen auf deinem FPGA.
Ich denke schon das irgendwo ein ungenutzter Rechner herumsteht... Dennoch ist der Wunsch meines Proffs dies mit einem "FPGA" zu realisieren. Das Thema ist grob so festgelegt. Wichtig dabei ist ihm die Geschwindigkeit von 10GBps. Falls das nicht klappt bleibt für mich noch immer die Notlösung ein fertiges günstiges Board zu nehmen und Geschwindigkeiten von 100-MBits/s zu erreichen( was sicherlich auch nicht so schwer sein dürfte). Aber ich würde gerne die erste variante! :-)
Björn schrieb: > Ich denke schon das irgendwo ein ungenutzter Rechner herumsteht... > Dennoch ist der Wunsch meines Proffs dies mit einem "FPGA" zu > realisieren. Das Thema ist grob so festgelegt. Wichtig dabei ist ihm die > Geschwindigkeit von 10GBps. Falls das nicht klappt bleibt für mich noch > immer die Notlösung ein fertiges günstiges Board zu nehmen und > Geschwindigkeiten von 100-MBits/s zu erreichen( was sicherlich auch > nicht so schwer sein dürfte). Aber ich würde gerne die erste variante! > :-) 1Gibt liegt dazwischen und ist auch auf dem SP601 als Phy drauf. Der Sinn der ganzen Übung ist mir noch nicht ganz klar. Sollte doch erst einmal eine Ethernetverbindung realisiert werden. Einfach die Daten rauszuschmeißen ist kein Problem, nur wie willst du die Paket auswerten und bewerten?
Kann ja mal über den Daumen peilen. Das gibt 10GBit/s an Nutzdaten netto. Angenommen, du musst diese Daten stets neu kodieren und/oder auswerten, d.h. du kannst sie nicht einmalig in einen Puffer im PHY/MAC-Chip schreiben und dann nur noch die Übertragung anstoßen: Dann müsstest du 10GBit/s vom FPGA zum Chip bringen. Weiter angenommen, dass du den Chip mit einem 64 Bit breiten Datenbus anfahren kannst, was schon recht unwahrscheinlich ist: Das ergibt einen Rahmentakt von gut 150MHz. Das FPGA müsste also schonmal an die 150 MHz bringen, um allein die Datenmenge herumschaufeln zu können. Und dann hast du die Daten noch nichtmal angepackt. Rechnen mal in konventionellen Protokollen mit 8-Bit breiten Bytes: Dann müsstest du die Rahmen mit über 1GHz erzeugen! Da wird ziemlich viel parallelisiert werden müssen...
Ich habe schon einige Tests mit solchen Geräten durchgeführt, solange die Lasttreiber kein vollständiges und "vernüftiges" TCP implemtieren können die Ergebnisse nur Schrott sein. Es seiden es sollen nur Switches auf Durchsatz ohne QOS und ähnliche Spielereien getestet werden. Versuch deinem Prof klarzumachen das der Ansatz nichts taugt, die Dynamik von TCP unter Last kann auch nur von echtem TCP erzeugen. Und komm bloss nicht auf die Idee eigenes TCP zu bauen, dafür brauchst du Jahre.
Naja, mit IP-Cores ist da einiges zu holen. Das ändert aber nichts an den Datenraten :-)
Und die IP-Cores implementieren vollständiges TCP mit slowstart, windowscaling, fast retransmit, nagle, SACK, congestion control, etc. und den ganzen anderen TCP Goodies ? Ohne diesen Kram taugt der Lastgenerator nicht die Bohne.
Tester schrieb: > Und die IP-Cores implementieren vollständiges TCP mit slowstart, > windowscaling, fast retransmit, nagle, SACK, congestion control, etc. > und den ganzen anderen TCP Goodies ? Das müsste man halt herausfinden. Darum bekommt man bei der Bachelorarbeit ja nur ein vorläufiges Thema. Ich denke aber, dass der TCP-Kram sich nicht sonderlich gut direkt in Hardware gießen lässt, ist ja doch eher was für einen Mikroprozessor. Und da wird es wohl auch hinlaufen. Für Mikroprozessoren gibts dann wieder TCP-Stacks zu Haufe. > Ohne diesen Kram taugt der Lastgenerator nicht die Bohne. Ohne ein Gegenstück taugt der Generator auch herzlich wenig. Ist ja nicht grad sonderlich repräsentativ für die Netzinfrastruktur selbst, Pakete en masse ins Rohr zu kippen, die nirgendwo ankommen. Als Test für die Kapazität einer Maschine am anderen Ende zusammen mit dem Netz ok, aber dann sind wir wieder am Ausgangsproblem.
Ich habe hier das DE-2 Board mit 2* 1GBit am laufen. Für eine richtige Last sind das zu wenig Daten. Bei 10GBit sind wir am recherchieren. Ein 10G-Phy und die parallel geschalteten Serdes-Transceiver eines Altera Cyclone IV sollten dafür ausreichen. So hat man uns jedenfalls beraten. Eine richtige Last sollte allerdings sinnvolle Dinge tun und konfigurierbar sein. Dazu reicht ein MAC-Core nicht aus, es muss noch einiges drum herum geschrieben werden. Es muss das IP-Protokoll implementiert werden. Auch wird eine Oberfläche zur Detaileinstellung der Last nötig sein. All das sprengt den Rahmen einer Bachalorarbeit. Persönlich würde ich einen schnellen Rechner nehmen, eine 10GBit Ethernetkarte, und den Rest durch Software erledigen. Da erreicht man die beste Flexiblität. Schneller zu implementieren ist das auch. -- ... Bei Bachlor muss ich immer an die Pfeife aus dem Fernsehen denken ...
>Bei Bachlor muss ich immer an die Pfeife aus dem Fernsehen denken
Jaja die "Privaten" ziehen auch alles in den Dreck...
@Björn Ich halte es zwar fuer ausgemachten Unsinn einen FPGA fuer sowas zu benutzen, wenn man noch nichtmal genau weiss was man genau testen will. Besonders ist mir unklar was Pakete "rausblasen" fuer einen Sinn haben soll. Aber ok, es gibt da ein sehr sehr guenstiges FPGA board mit 10Gbit, ist zwar ein aelterer FPGA, aber fuer 156 Mhz reicht es. http://netfpga.org/ Ein FPGA board mit extra PHY zu bauen kostet erstmal ein paar tausend. Der Distributor von Broadcom wird dir hoechstwahrscheinlich keinen Chip verkaufen. Gruss Christian
Ein PC und eine 10GB-Karte könnte im Ergebnis billiger und nervenschonender sein. Einfach die Pakete im Speicher zusammenbauen und dann (notfalls per eigenem Treiber) per DMA rausblasen. Ich mach ja sonst auch jeden Mist im FPGA aber hier ist es a) nicht zielführend und b) in einer typischen BA-Bearbeitungszeit (4Monate?) IMO nicht sinnvoll realisierbar.
Georg A. schrieb: > Einfach die Pakete im Speicher zusammenbauen und > dann (notfalls per eigenem Treiber) per DMA rausblasen. In keinster Weise zielführend, ohne TCP-State-Maschine und congestion control macht das keinen Sinn.
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.