An der Stelle weiß ich erstmal nicht weiter...
Ich bewundere trotzdem Deinen Enthusiasmus ... daß der ursprüngliche privoxy-Vorschlag von Dir war, wußte ich gar nicht mehr.
Ich habe mal (ganz grob nur) in die trickle-Quellen geschaut, ob das eher schon etwas betagte Programm (es ist älter als die erste Linux-basierte FRITZ!Box) immer noch funktionieren könnte/sollte.
Es arbeitet offenbar so, daß da eine Bibliothek mit eigenen Netzwerk-Zugriffsfunktionen mit einen speziellen Mechanismus (LD_PRELOAD) so "davorgeladen" wird, daß das gesteuerte Programm nicht die "richtigen" Netzwerkaufrufe verwendet, sondern die untergeschobenen und bei diesen wird dann beim Erreichen der Limits pro Sekunde einfach eine "Gedenkminute" eingelegt, d.h. der Abschluß z.B. eines read-Aufrufs, um die Daten vom Netzwerk zu lesen, wird ganz simpel angehalten, bis das nächste Zeitinterval erreicht ist. Das
kann jetzt mit vielen Programmen klappen ... aber auch die Netzwerk-Stacks haben sich in der Zwischenzeit wesentlich weiter entwickelt (es sind neue/alternative Funktionen dazu gekommen) und auch einige Programmier-Paradigmen sind inzwischen vollkommen anders. Multithreading (und damit die Verwendung von asynchronen I/O-Funktionen bzw. von "non-blocking calls") ist viel weiter verbreitet, usw..
Am Ende kann trickle also nur solche Programme "bremsen", die auch die von trickle modifizierten Funktionen zum Netzwerkzugriff wirklich benutzen. Es erfolgt also keine Regelung quasi auf der Task-Ebene, wo nach dem Erreichen des Limits einfach dem Thread weitere "Zeitscheiben" verweigert werden, wenn er das Liimit überschreitet und damit hängt die Funktion von trickle eben an der konkreten Umsetzung des zu steuernden Clients. Wie das bei dante aussieht (bei einem Daemon erwarte ich ehrlich gesagt "non-blocking i/o" als Pflicht und nicht als Kür), müßte man in den entsprechende Quellen prüfen.
Ich muß aber auf der anderen Seite auch gestehen, daß ich dazu eigentlich keine Lust so richtig habe. Das, was da dante/privoxy/etc. in Kombination mit trickle leisten könnten, geht imho auch mit den schon in der Firmware vorhandenen Funktionen und eigentlich sogar besser. Denn eine Nutzungslimitierung, die immer stattfindet, hat mehr mit der Drosselkom gemeinsam, als mit einer technischen Notwendigkeit, wenn da am Ende "ungenutzte Leitungskapazität rumliegt" und die Nutzung trotzdem eingeschränkt wird. Eine Priorisierung von Traffic (auf Protokoll-Ebene) ist mit der Firmware möglich, etwas anderes macht imho (habe ich weiter vorne erläutert, wie ich es verstehe) gar keinen Sinn und die Latenz für einzelne Pakete kann man damit ohnehin nicht gezielt niedrig halten. Also recht vergebliche Mühen ... der TE hat ja irgendwo schon geschrieben, daß er die vorhandenen Mechanismen der Firmware getestet hat, das aber bei seinem konkreten Problem keine Lösung brachte; wieso das jetzt mit dieser Lösung anders sein sollte, leuchtet mir nicht ein.
Ich sehe absolut nicht, wie ihm ein SOCKS-Proxy da helfen könnte ... der kann ja das Prinzip auch nicht auf den Kopf stellen. Der TE sieht am Ende beim "Ping" (was meist ja aber kein ICMP ist, sondern irgendeine "alive"-Nachricht zwischen Spiel und Server, wo dann der Roundtrip gemessen wird - es gehen also beide Richtungen in die Messung ein) nur, daß es mit der neuen Leitung etwas länger dauert. Wenn schon der Upload nur noch 60% des vorherigen erlaubt, ist eine entsprechende Erhöhung der Latenz auch folgerichtig. Das kann er nun mal nur verhindern, wenn er den anderen Verkehr
komplett aussperrt und somit sicherstellen kann, daß da garantiert niemals ein fremdes Paket gerade bei der Übertragung ist, wenn er es eilig hat. Er kann die Wahrscheinlichkeit für solche Konflikte senken durch das Drosseln der anderen, abstellen kann er sie nicht. Und da im Falle eines solchen Konfliktes dann auch die Priorisierung (sein Paket ist definitiv das nächste) reicht, sollte mit entsprechenden Einstellungen da auch schon der maximal mögliche Erfolg machbar sein (vorausgesetzt, die Firmware-Mechanismen funktionieren und das taten sie imho dort noch).
Er hat ja noch nicht einmal von sich gegeben, wie eklatant die Änderungen seiner Latenz nach dem Umstieg von der 16.000er- auf die 6.000-Leitung nun wirklich waren (auch nicht, wie sich die Angaben zur Latenz in der DSL-Statistik verändert haben). Wenn das nicht 250%+ sind, sondern max. 50%, dann sehe ich nicht, wie man das (außer durch exklusive Nutzung) überhaupt beheben könnte. Wenn es am Ende gar so ist, daß er an einem ganz alten ADSL(2)-DSLAM ohne die Möglichkeit des Ausschaltens für das Interleaving gelandet ist, dann sollte er u.U. auf Kuriere umsteigen, denn dann sind sogar 60-75 ms alleine bis zum DSLAM drin und da kann er nun mal einfach nichts dagegen tun.
Den Einsatz von trickle sehe ich mehr da, wo auf einem einzelnen PC verhindert werden soll, daß eine Aufgabe mit "Background"-Priorität (meinetwegen eine "lazy transmission" irgendwelcher Backups an einen zweiten Speicherplatz, bei denen es vollkommen Bummi ist, ob die eine Stunde früher oder später dort ankommen), die keine eigene Regulierung der genutzen Bandbreite erlaubt, dort die Netzwerkverbindung (meinetwegen auch die Internetverbindung) "zufährt" und dann z.B. Webseitenabrufe zu stark verzögert.
Wenn jemand eine 6.000er-Leitung hat/bezahlt und dann am Ende nur die Nutzung mit 3.000 kBit/s möglich ist, weil da auf irgendeine (ich sag mal recht primitive) Art ein ungeeignetes Management eingesetzt wird, das auch die eigentliche Ursache des Problems nicht beseitigen kann, dann sollte man die ganze Idee noch einmal neu durchdenken.
