UDP -> TCP, lastempfindlicher?
-
Super, vielen dank für die infos.
Ich kann dir das gerade nicht sagen, da ich erst montag wieder an den roboter komme(uni).
Ich schau mir dass dann mal an und melde mich
Zur not muss ich wohl nen puffer einbauen, wobei ich dann wieder mir nicht vertrauten code ändern muss(was auf dem leitrechner eine qual ist)
-
Namenloser324 schrieb:
Super, vielen dank für die infos.
Ich kann dir das gerade nicht sagen, da ich erst montag wieder an den roboter komme(uni).
Ich schau mir dass dann mal an und melde mich
Zur not muss ich wohl nen puffer einbauen, wobei ich dann wieder mir nicht vertrauten code ändern muss(was auf dem leitrechner eine qual ist)wobei mir gerade einfällt, dass jaschon ein puffer existiert. Die Nachricht eines Gelenks(die dann tatsächlich via WLAN versendet wird) besteht aus ca. 20-30 Byte, wobei aber eine Nachricht in einen buffer geschrieben wird und dann versendet wird was da drin ist, naja wie gesagt, ich muss mir das morgen genauer anschauen.
-
So guten morgen.
Sitze jetzt wieder dabei und es scheint als wäre nicht der leitrechner schuld sondern der empfänger pc. Das Programm(leider nicht von mir, sonst wüsste ich schneller was vorliegt) welches den empfang managed scheint irgendwo nen ungültigen pointer zu erzeugen und stürzt ab. Daraufhin werden die gelenkdaten auf dem roboter in den buffer auf dem leitrechner gepackt welcher aber wegen des abstürzens des empfängers nicht mehr geleert wird -> er quillt über und alles zerbricht.(fragt mich nicht wieso das so programmiert worden ist) Davor läuft es für ~10 sekunden stabil.
Ich seh mir das jetzt an, falls was ist melde ich mich.
-
SOoo, es scheint wohl definitiv an wxWidget gelegen zu haben, welches zur Programmierung der Visualisierung der Gelenkdaten genutzt wird.
Die Ausgabe der Gelenkdaten in einem Textfenster hat scheinbar auf Dauer das Programm um seinen Lebenswillen gebracht läuft das Tool jetzt doch ohne Probleme.
Muss ich mal nachforschen ob ich was zu häufer Benutzung von Textfeldern in wxWidget finde.
Danke an nwp3
-
wichtiger als das bestaetigen ist dass tcp auch load balancing macht. da die ip packete nicht durchgaengig von sender zu empfaenger geschickt werden, sondern zig knoten im netzt passieren, gibt es unmengen an buffern und verschiedene bandbreiten, es kann sein dass ein server mit 10GBit/s schicken kann, der empfaenger ein 3g modem hat und dann kann der versender nicht flockig 1MB/s schicken und die 'bleiben dann irgendwo', weil der provider nicht 100MB cache pro user anlegen will. deswegen gibt es verschiedene algorithmen die versuchen abzuschaetzen wie schnell verschickt werden darf, natuerlich faengt sowas klein an, hast du also stossweise packete die du schickst, statt gleichmaessig, wird der algorithm jedesmal bei kleinen bandbreiten anfangen und dann hast du weit weniger durchsatz als durchgaengig TCP packete zu schicken, selbst wenn darin nichts steht.
ich weiss ja nicht wie dein robo-server arbeitet, aber das koennte bei tcp gegenueber udp ein nachteil sein.
-
na ja. tcp macht kein load balancing. wenn load balancing passiert, dann ist es egal ob tcp oder udp. sollte das dann nicht flow basiert passieren, hat jemand seine geraetschaften schlecht konfiguriert.
der rest ist auch fraglich, da es fuer den udp burst offensichtlich gereicht hat. ansonsten tcp verbindung offen halten, dann bleiben's die sliding windows auch.
-
tcp schrieb:
na ja. tcp macht kein load balancing. wenn load balancing passiert, dann ist es egal ob tcp oder udp. sollte das dann nicht flow basiert passieren, hat jemand seine geraetschaften schlecht konfiguriert.
du kannst nach "tcp congestion control" suchen um deine wissensluecke aufzufuellen
z.b.
http://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols
-
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun. wie willst du mir was ueber meine wissenluecken erzaehlen, wenn du nicht einmal mit den begrifflichkeiten vertraut bist? also bitte erst seepferdchen machen bevor du mir unwissen unterstellst
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
-
tcp schrieb:
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun.
load balancing ist im englischen allgemein die verteilung von last, auch traffic erzeugt eine last. du versuchst die geschwindigkeit zu maximieren, wie es häufig üblich ist bei load balancing, dabei ziel ist die fehlerquote die durch zuviel traffic entsteht mit starvation die durch zuwenig traffic entsteht so auszugleichen, dass die beste transferrate auszulotet wird.
das ist auch das problem bei tcp, wenn eine transportschicht nicht zuverlässig ist, selbst wenn sie mehr bandbreite zulässt, wird die verbindung als überlastet angesehen und fast alle algorithmen drosseln.
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
diese transferleistung zu erbringen ist eine persönliche herausforderung, versuche sie zu meistern.
-
meisterer schrieb:
tcp schrieb:
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun.
load balancing ist im englischen allgemein die verteilung von last
du schreibst es doch selber. verteilung von last, parallelisierung. dein beschriebenes problem ist rein serieller natur.
meisterer schrieb:
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
diese transferleistung zu erbringen ist eine persönliche herausforderung, versuche sie zu meistern.
load-balancing ist ein feststehender begriff in der telekommunikationsbranche; da kann ich dir leider keinen spielraum fuer interpretationen einraeumen.
-
meisterer schrieb:
...
schon ok, ich brauche keinen verteidiger ;), er hat sicher dem thread starter signifikant geholfen mit seinen beitraegen die rausstellen wo er nicht meiner meinung ist. mehr beitraege werden den thread nicht weiterfuehren ;), bin dann raus hier.
btw. lustige zeichen, proxy? man darf zu seiner meinung stehen... und feige annonym zu sein
-
[quote="rapso"]...wo er nicht meiner meinung ist./quote]
da hast du meine einwaende missverstanden. die industrie schafft standards und vokabular, damit bei solchen angelegenheiten eine meinung irrelevant ist.
-
rapso schrieb:
[...]mit seinen beitraegen die rausstellen wo er nicht meiner meinung ist.
Ich verstehe das Problem nicht so recht. Load Balancing und Congestion Control sind wirklich nicht das selbe, da hat er schon recht.
Aus dem Kontext konnte man schon halbwegs schlieszen, was du wohl meinst, aber tcps Beitraege sind technisch durchaus korrekt.