*** Protokolldatei gestartet *** Datum: Mi. Feb 15 19:56:37 2012 [Mittwoch, 15. Februar 2012] [19:56:37] Betreten Sie haben den Kanal #forth-ev betreten (-bernd@p5DCD63B9.dip0.t-ipconnect.de). [Mittwoch, 15. Februar 2012] [19:56:42] Modus Kanalmodi: [Mittwoch, 15. Februar 2012] [20:01:14] Betreten MatthiasT hat den Kanal betreten (~mt@dslb-188-109-222-055.pools.arcor-ip.net). [Mittwoch, 15. Februar 2012] [20:01:25] Hallo Bernd [Mittwoch, 15. Februar 2012] [20:05:14] Hallo, da kommt ja wer. [Mittwoch, 15. Februar 2012] [20:11:24] musste nochmal kurz weg... [Mittwoch, 15. Februar 2012] [20:13:04] Gibt's irgendwas neues? [Mittwoch, 15. Februar 2012] [20:13:18] In Gforth haben wir einen merkwürdigen 32-Bit-GCC/libc-Bug gefunden. [Mittwoch, 15. Februar 2012] [20:13:36] sin/cos/tan etc. machen %edx kaputt, da liegt der TOS. [Mittwoch, 15. Februar 2012] [20:13:42] Eigentlich nicht. Ich bin dabei, ein evaluate basierend auf meinen neuen Refill/source umdefinierei zu basteln [Mittwoch, 15. Februar 2012] [20:14:09] Aber mehr als eine Ideensammlung ist da noch nicht vorhanden [Mittwoch, 15. Februar 2012] [20:14:19] Genauso wie die Locals mit recognizern zu machen. [Mittwoch, 15. Februar 2012] [20:14:54] gcc Bugs scheinen ja grade in Mode zu kommen [Mittwoch, 15. Februar 2012] [20:15:21] Ja, die GCC-Macher sind irgendwie der Ansicht, dass Quality of Implementation keine Rolle spielt. [Mittwoch, 15. Februar 2012] [20:15:49] Die wollen wohl den schlechtesten Compiler bauen, den der C-Standard gerade noch zulässt ;-). [Mittwoch, 15. Februar 2012] [20:17:55] Kann ich wenig beitragen, mein Wissen über Compiler ist eher rudimentär und vermutlich hoffnungslos [Mittwoch, 15. Februar 2012] [20:17:59] naiv und veraltet [Mittwoch, 15. Februar 2012] [20:18:32] Knuth hat das Buch zum Compilerbau auch noch nicht fertig (IIRC) [Mittwoch, 15. Februar 2012] [20:22:00] Ich muss aber auch sagen, Stephen Pelc war auch nicht unbedingt einsichtig, was meine Bug-Reports am VFX betraf. [Mittwoch, 15. Februar 2012] [20:22:52] Erst, als er den Source-Inliner durch einen Token-Inliner ersetzt hat, und das ganze dadurch wartbarer und einfacher wurde, hat er angefangen, zuzuhören. [Mittwoch, 15. Februar 2012] [20:24:49] Wenn das Problem dadurch weniger komplex wird und vor allem nachvollziehbar (soll/ist), sicher eine gute Idee ;) [Mittwoch, 15. Februar 2012] [20:26:06] Ja, ich nörgele ja nicht grundlos herum, sondern weiß, dass es eine bessere Lösung gibt, die nicht nur richtig ist, sondern auch einfacher. [Mittwoch, 15. Februar 2012] [20:26:22] Krazt natürlich trotzdem am Ego ;-). [Mittwoch, 15. Februar 2012] [20:26:34] Wobei mir neulich erst so richtig klar wurde, das ein (hypothetischer) Optimierer für amfort wahrscheinlich wenig Nutzen haben dürfte. Er kann ja nur bis zum VM Level optimieren, den Maschinencode sieht der ja gar nicht [Mittwoch, 15. Februar 2012] [20:27:25] So richtig lohnen wird sich das alles sicher erst, wenn die ganzen stack-shuffles entsorgt werden können "dup if" etc pp [Mittwoch, 15. Februar 2012] [20:28:12] Dazu müsste ich aber das ITC Format aufgeben, wozu ich aber keine große Lust habe (derzeit) [Mittwoch, 15. Februar 2012] [20:28:29] Genau, und bei AVR ist Native Code nicht unbedingt die beste Lösung. [Mittwoch, 15. Februar 2012] [20:29:25] In mancherlei HInsicht schon, der innere Interpreter ist für so Sachen wie DUP und + schon eine ziemliche Hürde, was die Laufzeit angeht. [Mittwoch, 15. Februar 2012] [20:29:41] Das dauert halt. [Mittwoch, 15. Februar 2012] [20:29:58] dafür sind andere Sachen deutlich einfacher. [Mittwoch, 15. Februar 2012] [20:30:40] Und Speed kann ich durch einen neuen Quartz auch erreichen, Batteriebetrieb steht nicht auf meiner Agenda ;) [Mittwoch, 15. Februar 2012] [20:31:11] Nachdem sogar Handys mit VMs arbeiten, statt Native Code auszuführen... ;-) [Mittwoch, 15. Februar 2012] [20:31:31] Wobei es mich schon interessieren würde, was ein Forth Optmierer so alles bei der Übersetzung von Forth-Code nach ... Forth Code machen würde [Mittwoch, 15. Februar 2012] [20:33:29] Naja, da kann er eigentlich nur inlinen. [Mittwoch, 15. Februar 2012] [20:36:05] Für einen native Code Generator mit Optmierer halte ich einen PC für die deutlich bessere Plattform. Da kommt dann ein unverständliches Stück Assembler raus, was man zum Controller pustet. Alternativ irgendein Tethered System [Mittwoch, 15. Februar 2012] [20:36:42] Ja, so ungefähr. [Mittwoch, 15. Februar 2012] [20:37:03] Auf dem 8-Bit-Controller ist Native Code zu kompliziert, um es vor Ort zu erzeugen. [Mittwoch, 15. Februar 2012] [20:37:35] Bei 'nem 32-Bit-"Controller", also ARM oder ähnlich, sieht die Sache wieder anders aus. [Mittwoch, 15. Februar 2012] [20:37:40] Der amforth Assembler ist so groß, der wird seinen eigenen Platzbedarf wohl nie einspielen... [Mittwoch, 15. Februar 2012] [20:37:58] ARM spielt in der PC Liga [Mittwoch, 15. Februar 2012] [20:38:12] Zumindest die Linux-tauglichen Systeme [Mittwoch, 15. Februar 2012] [20:38:50] Ja, den Assembler lasse ich bei meinen Gforth-EC-Systemen auch auf dem Host. [Mittwoch, 15. Februar 2012] [20:39:05] Wer da was in Assembler programmieren will, soll sich ein neues Image cross-compilieren. [Mittwoch, 15. Februar 2012] [20:48:14] Ansonsten bin ich jetzt wohl auf den Trichter gekommen, wie ich das mit der Fairness bei net2o hinkriege. [Mittwoch, 15. Februar 2012] [20:48:21] Flusskontrolle. [Mittwoch, 15. Februar 2012] [20:48:52] Der Slack, also der Füllstand des Buffers, geht jetzt exponentiell (über shift) in die Bandbreite ein. [Mittwoch, 15. Februar 2012] [20:49:38] Und eine Änderung des Slacks nach oben reduziert die Bandbreite zusätzlich. [Mittwoch, 15. Februar 2012] [20:50:03] Also je voller, desto weniger Bandbreite? [Mittwoch, 15. Februar 2012] [20:50:14] Genau. [Mittwoch, 15. Februar 2012] [20:50:39] Könnt klappen. [Mittwoch, 15. Februar 2012] [20:50:40] Wenn der Buffer sich dann wieder leert, gibt's wieder mehr Bandbreite. [Mittwoch, 15. Februar 2012] [20:51:03] Du hast aber immer noch garantierte Zustelle [Mittwoch, 15. Februar 2012] [20:51:08] ung? [Mittwoch, 15. Februar 2012] [20:51:12] oops. Zustellung [Mittwoch, 15. Februar 2012] [20:51:19] Im Prinzip ja. [Mittwoch, 15. Februar 2012] [20:51:24] In der Realität leider nein ;-). [Mittwoch, 15. Februar 2012] [20:51:46] Da mein net2o-client ein User-Programm ist, kann es auch mal länger aufgehalten werden, und dann sind die Pakete weg. [Mittwoch, 15. Februar 2012] [20:53:12] Irgendwann wird der Stack ja als Kernelmodul laufen ;) [Mittwoch, 15. Februar 2012] [20:54:08] Ja, soweit ich das jetzt sehe, ist das auch ziemlich dringend nötig. [Mittwoch, 15. Februar 2012] [20:54:25] Weil ich möglichst präzise Zeiten brauche, wann das Packet tatsächlich weggeschickt bzw. angekommen ist. [Mittwoch, 15. Februar 2012] [20:54:41] Die bekomme ich als User-Programm nicht. [Mittwoch, 15. Februar 2012] [20:55:20] Eigentlich brauch' ich ein ganz anderes Interface als das sendto/recvfrom-Interface. [Mittwoch, 15. Februar 2012] [20:56:32] Beim Senden hätte ich gerne eine Liste von Packets, bei denen ich vorher schon weiß, wann ich sie wohin schicken möchte, und beim Empfangen hätte ich das genau umgekehrt: Einen Speicherbereich, der mit empfangenen Packets gefüllt wird, und eine Liste, wann welches woher eingetrudelt ist. [Mittwoch, 15. Februar 2012] [20:58:00] Mit Jumbo-Frames habe ich auch etwas herumexperimentiert, aber das ist nicht ausgereift. [Mittwoch, 15. Februar 2012] [20:58:05] Ganz naiv: Warum legst Du den Sendetermin vorab fest? (send-not-before oder?) [Mittwoch, 15. Februar 2012] [20:58:28] In einem nicht ganz sauberen Netzwerk wie meinem Heimnetz (Fritzbox kann sie nicht) funktioniert die Path-MTU nicht. [Mittwoch, 15. Februar 2012] [20:58:43] Auch der Empfangszeitpunkt erscheint mir weniger wichtig. Interessanter ist die Reihenfolge im Gesamtstream [Mittwoch, 15. Februar 2012] [20:59:31] Ich mach' ja eine "Datenratenerkennung", indem ich mehrere Bursts (von z.B. 8 Packets) in der vorher festgelegten Datenrate wegschicke. [Mittwoch, 15. Februar 2012] [20:59:49] Da weiß ich dann im Voraus, wann die nächsten 32 Packets auf die Reise gehen sollen. [Mittwoch, 15. Februar 2012] [21:00:14] hmm [Mittwoch, 15. Februar 2012] [21:00:40] Der Empfänger misst dann die Zeit, an der die Packets eintreffen, und rechnet daraus die tatsächlich verfügbare Bandbreite aus. [Mittwoch, 15. Februar 2012] [21:00:58] Die teilt er dann dem Sender mit, der seinen nächsten Burst dann mit dieser Rate verschickt. [Mittwoch, 15. Februar 2012] [21:01:44] Der Sender lässt dann noch den ausgemessenen Slack (also die Pufferfüllung) in die Rechnung einfließen, und fertig ist die Flusskontrolle. [Mittwoch, 15. Februar 2012] [21:01:46] Mal abgesehen von Einzelpaketen ala UDP fallen mir eigentlich nur zwei Stream-Arten ein: so schnell wie möglich (HTTP, FTP) oder festgelegte Packetrate (Audio, Video). [Mittwoch, 15. Februar 2012] [21:02:08] Ja, richtig. Flusskontrolle ist für "so schnell wie möglich". [Mittwoch, 15. Februar 2012] [21:02:56] Die Sender/Empfänger Kommunikation dürfte Einzelpackete umfassen [Mittwoch, 15. Februar 2012] [21:02:58] Und bei Streams kann man die Datenrate einmal am Anfang festlegen, und dann halt einhalten. [Mittwoch, 15. Februar 2012] [21:03:13] Ja, die Kommandos, das sind Einzelpackete, die nicht der Flusskontrolle unterworfen sind. [Mittwoch, 15. Februar 2012] [21:04:24] Wobei ein Kommandopacket mehrere Kommandos enthält (ist ja eine Forth-artige VM). [Mittwoch, 15. Februar 2012] [21:04:28] Was Du noch brauchen wirst, ist ein Stream-Identifier. Der Server kann StreamA vermutlich schneller senden als Stream B [Mittwoch, 15. Februar 2012] [21:04:52] Wenn Client A im LAN steckt und Client B in China ;) [Mittwoch, 15. Februar 2012] [21:05:18] Der Server weiß schon, wem er was schickt, die Fluss-Kontrolle ist pro Verbindung. [Mittwoch, 15. Februar 2012] [21:05:27] ok [Mittwoch, 15. Februar 2012] [21:06:50] Im Moment teste ich mit ausgeschaltetem Retransmit, weil ich natürlich die verlorenen Packets im Auge behalten will. [Mittwoch, 15. Februar 2012] [21:06:51] Flusskontrolle ist auch für Fix-rate Verbindungen nicht uninteressant. Damit man relativ dynamisch (Userland) zwischen Bandbreiten umschalten kann. [Mittwoch, 15. Februar 2012] [21:07:48] aktuelle Bandbreite vs machbare Bandbreite. In beide Richtungen (schneller und langsamer) natürlich [Mittwoch, 15. Februar 2012] [21:07:51] Ja, wobei in dem fall (z.B. Videostream) auch zwischen verschiedenen Auflösungen umgeschaltet werden muss. [Mittwoch, 15. Februar 2012] [21:08:00] Deswegen Userland [Mittwoch, 15. Februar 2012] [21:08:31] Der könnte auch zwischen PCM und MP3 wechseln ;) [Mittwoch, 15. Februar 2012] [21:09:46] Oder zwischen speex und celt. [Mittwoch, 15. Februar 2012] [21:16:08] Du solltest noch 4096 bytes pro Packet aufnehmen. Das macht das Leben für die IP Storage Fraktion einfacher [Mittwoch, 15. Februar 2012] [21:16:24] Im Moment gibt es 2^n von 64 Bytes bis 2 Megabytes. [Mittwoch, 15. Februar 2012] [21:16:24] dann passt ein 4K Festplattenblock in ein datenpacket [Mittwoch, 15. Februar 2012] [21:16:44] auch gut. [Mittwoch, 15. Februar 2012] [21:17:06] Alle Zeiten in Nanosekunden. [Mittwoch, 15. Februar 2012] [21:17:56] Dank der Bursts reicht das dann für n*2 Petabytes/s. [Mittwoch, 15. Februar 2012] [21:18:25] Sollte einigermaßen zukunftssicher sein ;-). [Mittwoch, 15. Februar 2012] [21:18:48] Vermutlich [Mittwoch, 15. Februar 2012] [21:20:09] Ich geh so pi mal Daumen von einem Faktor 2 alle zwei Jahre aus. [Mittwoch, 15. Februar 2012] [21:21:34] Für Modem-Verbindungen ist das, was ich derzeit habe, nicht so richtig geeignet ;-). [Mittwoch, 15. Februar 2012] [21:22:13] Wenn das auch mal auf Android läuft, dann werde ich es unter Edge ausprobieren, das ist so realistisch das langsamste, was tatsächlich noch benutzt wird. [Mittwoch, 15. Februar 2012] [21:22:41] Ich wäre nicht überrascht, wenn die derzeitige Technik mit einem 300baud Akustikkoppler nicht mal mehr telnet hinkriegen würde [Mittwoch, 15. Februar 2012] [21:23:10] Solche Extrema sind einfach nicht mehr in den Testszenarien drin [Mittwoch, 15. Februar 2012] [21:24:34] Auf'm Mac habe ich das Problem, dass der kein ppoll hat, und das normale poll nur Millisekunden-Delays kann. [Mittwoch, 15. Februar 2012] [21:25:21] Damit ist man auf n Megabytes/s begrenzt (n=Anzahl Packets pro Burst, bei 1k-Packets, normalerweise 8). [Mittwoch, 15. Februar 2012] [21:25:57] Wobei ich mir da wohl auch mit einer gettimeofday-Warteschleife behelfen könnte. [Mittwoch, 15. Februar 2012] [21:26:49] Ich muss Dich jetzt leider allein lassen. [Mittwoch, 15. Februar 2012] [21:27:16] Ciao! [Mittwoch, 15. Februar 2012] [21:27:19] Vielleicht kann ich Dein Net2o in ein paar Monaten mal testen [Mittwoch, 15. Februar 2012] [21:27:36] (dann hab ich vermutlich ein paar Ressourcen dafür) [Mittwoch, 15. Februar 2012] [21:27:52] Ja, bis dahin sollte es auch Sachen können, die ein Anwender braucht. [Mittwoch, 15. Februar 2012] [21:27:52] bis neulich dann [Mittwoch, 15. Februar 2012] [21:27:58] * BerndPaysan macht das Licht aus [Mittwoch, 15. Februar 2012] [21:28:03] Gute Nacht! [Mittwoch, 15. Februar 2012] [21:28:05] Beenden MatthiasT hat den Server verlassen ("").