bandbreite splitten

Re: bandbreite splitten

Balrok — Thu, 19 Apr 2007 05:35:40 GMT

ich würd dieses tool verwenden:

http://www.netlimiter.com/

einfach auf jedem pc installiern und die bandbreite dort nach belieben einstellen

Re(6): bandbreite splitten

googleDork — Wed, 18 Apr 2007 16:58:55 GMT

Heyhey...

Im Vergleich zu anderen Usern

http://forum.geizhals.at/t488781,4049436.html#4049436

OK zahlst nen Liter.

bin ich ja günstigst

Re(5): bandbreite splitten

patos — Wed, 18 Apr 2007 16:56:11 GMT

schnorrer!

Re(5): bandbreite splitten

patos — Wed, 18 Apr 2007 16:56:11 GMT

schnorrer!

Re(3): bandbreite splitten

codeslayer — Wed, 18 Apr 2007 16:55:51 GMT

korregiere: Traffic Shaping ist das richtige wort

Du könntest Monowall einsetzen ... http://m0n0.ch/wall/
Man braucht eigentlich nur einen alten ausrangierten PC mit 2 Netzwerkkarten.

Re(19): bandbreite splitten

googleDork — Wed, 18 Apr 2007 16:26:06 GMT

Hmmm .... patos, patos..... enttäuschend....

Da schließt du von 65532 anderen Ports (wahrscheinlich sogar um 1024 weniger für die well-known... und zusätzlich um 32768 weniger wegen der klassischen ephemerals) auf den einen ? Pfew... Statistisch schwach!

Da ist ja sogar mein Familienvergleich passender.... Denn wieviel Familien gibts wohl in AT ? 10 ? 20 ?

Re(18): bandbreite splitten

patos — Wed, 18 Apr 2007 16:20:22 GMT

untersteh dich! nein, auch ich bin ein squidder... ich habe nur das verhalten bei anderen well known ports beobachtet und schlussgefolgert, dass es so auch im port 80 sein muss.

Re(14): bandbreite splitten

patos — Wed, 18 Apr 2007 16:13:55 GMT

hast eh recht. ich hoffe sowas verschwindet einfach in versenkung der netzwerkprotokolle. ich glaube die "free-internet" aktivisten sind auch dagegen, oder?

Re(17): bandbreite splitten

googleDork — Wed, 18 Apr 2007 16:07:52 GMT

Wieso ?

Selbst meine einfache Family mit nur 2 Usern fährt nur über Squid...
Also gehe ich mal (durch Beobachtung in 100% der Fälle, also meiner Familie) davon aus, daß überall mit Squid gefahren wird .

EDIT: Mit Ausnahme von Dir, Patos...
Denn wie solltest sonst von dem Filesharer wissen .

Oder bist eh nur beim durchwassern der Squid-Logs mit "Connection refused" draufgestoßen ?

Re(17): bandbreite splitten

googleDork — Wed, 18 Apr 2007 16:07:52 GMT

Re(13): bandbreite splitten

googleDork — Wed, 18 Apr 2007 16:06:17 GMT

Mit mehr und mehr VPNs hast natürlich recht...

Wobei dann wieder MPLS als Krankest-Lösung raussticht... Wo der Router ja "mit 2 Füßen" in 2 Schienen steht... Und CPU-Bedarf und angreifbarkeit steigt...

Nun ja.... MPLS, TCP drinnen, VPN drauf, TCP drinnen - mit Fibre-to-the-home werden wir dann endlich wieder Tetris ruckelnd im Netz spielen

Re(16): bandbreite splitten

patos — Wed, 18 Apr 2007 15:58:56 GMT

schon, nur... phantasiere nicht ZU viel...

Re(12): bandbreite splitten

patos — Wed, 18 Apr 2007 15:58:07 GMT

für endgeräte sind connection oriented protokolle ein segen, erfordet aber rechenleistung auf der gesamten strecke. genau daran wird es scheitern. imho natürlich.

man sieht schon heute, dass die tendenz richtung netze über netze geht. darknets, vpns. ich denke in zukunft werden diese netze sich wie eine krake über tcp/ip legen und schlicht auf tcp pfeifen, weil sie eh selber die verbindungen aushandeln.

tcp/ip war schon mal diese krake, man errinert sich als die carrier keine verwendung für ihre tollen atm netze fanden und anfingen ip darüber zu routen

Re(15): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:47:19 GMT

Also wenn das WG oder ähnliches ist...

Warum sollte man keinen Proxy verwenden ? Weil einem Seitenzugriffe sonst zu schnell gehen ???

Re(4): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:46:31 GMT

Ok... Wir fassen also zusammen:

pfff.. TDMA ist schon seit jahrzehnten nimmer aktuell. warum die bandbreite fix
einzuteilen wenn du die einteilung flexibel gestalten kann?

Ist obsolet... Kostet Dich ein Krügerl

Re(14): bandbreite splitten

patos — Wed, 18 Apr 2007 15:44:43 GMT

port 80 eh immer durch Squid abgefangen wird...

wünsch dir was....

Re(11): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:44:30 GMT

es war billiger aufm phy alles hard zu coden als rechenleistung zu verbraten

Nun ja... Einerseits hast das ja noch immer... Cisco-Router sind dann pfeilschnell, solange die CPU nix tun muß .

Aaaber ich sprach von Endgeräten...

Da ist es sicher sinnvoller, wenn eine Applikation TCP verwendet, als wenn sie
- UDP verwendet
- sich selbst um Retransmits kümmert
- und dadurch Teile des TCP-Stacks nachbildet.

UDP ist (IMHO!!!) dann super, wenn ich eben keine Retransmits will - sondern nur "Wenn ich Daten krieg - super. Wenn ich keine krieg - auch wurscht, ich warte nicht auf sie" - wie beispielsweise bei AV-Streams.

Wieso beispielsweise NFS auf UDP basiert, ist mir ja bis heute unklar

Re(3): bandbreite splitten

patos — Wed, 18 Apr 2007 15:41:29 GMT

verzeihung, ich betrachtete lediglich den netzwerktechnischen sinn des vorhabens. zwischenmenschlichkeit stand bis dato ausser diskussion

Re(3): bandbreite splitten

patos — Wed, 18 Apr 2007 15:41:29 GMT

verzeihung, ich betrachtete lediglich den netzwerktechnischen sinn des vorhabens. zwischenmenschlichkeit stand bis dato ausser diskussion

vermutlich machen es Provider eh nicht anders...

da liegst du richtig. schon mal selber gesehen.

Re(13): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:40:50 GMT

Nutzt nur leider keinem was...

Da
- port 80 eh immer durch Squid abgefangen wird...
- dann kein GET funktioniert (weil CONNECT eh unterbunden wird)
wird keiner aus dem Lan hinkommen

Re(12): bandbreite splitten

patos — Wed, 18 Apr 2007 15:37:55 GMT

du kannst es erahnen.... öfters sehe ich einen "witzbold", der bittorrent auf port 80 betreibt. nicht unintelligent, muss ich sagen.

Re(10): bandbreite splitten

patos — Wed, 18 Apr 2007 15:36:06 GMT

Genau dann, wenn Retransmits notwendig sind, finde ich UDP meist schon die
falsche Wahl
Abgesehen davon - wieso ist es fürs Netzwerk besser, wenn die Applikation dann
Retransmits anfordert, als wenn dasselbe durch den TCP-Kernel passiert ? Für
die Rechner ist dann jedenfalls TCP sinnvoller... Mehr passiert im Kernelspace
- weniger Contextswitches - weniger Last.

stimmt schon, genau deswegen wurde auch schon mal layer2 connection oriented gefahren. es war billiger aufm phy alles hard zu coden als rechenleistung zu verbraten. davon hat man aber zunehmen mehr, ich kann die schmutzarbeit höheren protokollschichten überlassen. das war der schlüssel zum erfolg von tcp/ip. dadurch wurden hardware implementierungen billiger, systeme leistbarer, entwicklungszeiten kürzer. ich gehe davon aus dass wir in einigen jahrzehnten nur mehr connectionless im internet unterwegs sein werden und die verbindung zur gänze auf application layer stattfindet. ist schon so bei vielen anwendungen.

Dieses keep-it-simple macht aber die Applikationen aufwändiger - und
anfälliger.

das ist immer der fall, tcp hat auch seine zeit gebraucht

Re(2): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:31:03 GMT

pfff.. TDMA ist schon seit jahrzehnten nimmer aktuell. warum die bandbreite fix
einzuteilen wenn du die einteilung flexibel gestalten kann?

Momeeeent... Das macht absolut Sinn..

Beispiel: Es sei eine WG - und eben 4 Studis.
Er hätte Chello genommen (und bezahlt es) - und jeder Mitbewohner hat das Angebot:
- reichen dir 500kBit - dann zahlst 5€ p.m.
- willst 1 MBit - dann zahlst 10€ p.m.
- willst 500kBit und freie Bandbreite wenn sonst keiner was tut - dann zahlst 7€

Dann macht "brutales" runterdrosseln durchaus Sinn - vermutlich machen es Provider eh nicht anders...

Re(11): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:27:31 GMT

eine verbindung ist eine sache. was darüber gesendet wird, eine ganz andere. während des verbindungsaufbaus kannst du einfach nicht erkennen was später darüber laufen wird, somit tust du dir ein wenig schwer, die anzahl der verbindungen im dunkel zu kontrollieren.

Wieso kann man das nicht anhand der Ports einschätzen ?

Re(9): bandbreite splitten

googleDork — Wed, 18 Apr 2007 15:24:51 GMT

*Stein werf* .

ich kann mich mit udp weit mehr anfreunden als mit tcp. da weiss die gegenstelle dass das paket nicht ankommen kann und muss sich um einen retransmit kümmern.

Genau dann, wenn Retransmits notwendig sind, finde ich UDP meist schon die falsche Wahl
Abgesehen davon - wieso ist es fürs Netzwerk besser, wenn die Applikation dann Retransmits anfordert, als wenn dasselbe durch den TCP-Kernel passiert ? Für die Rechner ist dann jedenfalls TCP sinnvoller... Mehr passiert im Kernelspace - weniger Contextswitches - weniger Last.

ich muss mir keine sorgen über verbindungen machen, ob es vorteilhafter wäre zu priorisieren oder nicht.

Nein... Du kannst dir weniger Sorgen machen . Abgesehen davon bleibt priorisieren weiterhin möglich .

ich kann sie einfach bedenkenlos verwerfen, denn ich weiss dass das programm damit rechnen muss.

Passiert ja bei TCP genauso..... Manche kannst verwerfen.

keep it simple

Dieses keep-it-simple macht aber die Applikationen aufwändiger - und anfälliger.

Re(8): bandbreite splitten

patos — Wed, 18 Apr 2007 15:14:39 GMT

uhm... steinigt mich, aber ich kann mich mit udp weit mehr anfreunden als mit tcp. da weiss die gegenstelle dass das paket nicht ankommen kann und muss sich um einen retransmit kümmern. ich muss mir keine sorgen über verbindungen machen, ob es vorteilhafter wäre zu priorisieren oder nicht. ich kann sie einfach bedenkenlos verwerfen, denn ich weiss dass das programm damit rechnen muss. ein paar sek puffer für up und down damit real time pakete ankommen, fertig. insbesondere da kommen paketerkennungstechniken wunderbar zur geltung. keep it simple.

Re(7): bandbreite splitten

googleDork — Wed, 18 Apr 2007 14:53:42 GMT

Ok - dann sind wir da eh d'accord...

Gemeinsam haben wir also:
1.) Cappen beim download Systemweit
2.) Priorisierung beim Upload (wohl nach Protokoll)

Ich würde trotzdem zusätzlich beim Download (innerhalb des Systemweiten Downloadlimits) noch CBQ oder HTB fahren... In beide Richtungen.

Begründung:
1.) Beispiel SMTP - Uploadbegrenzung.
Wenn einer Megabyte-Mails uploaded, soll der nur einen Teil der Bandbreite vergiften... zB 10%. Denn ob eine Mail pro MB nun 20 Sekunden oder 200 Sekunden braucht, müßte ja wurscht sein - ich möchte aber nicht, daß jemand für 20 Sekunden meine Leitung voll "up" belegt. Wenn die Leitung zu ist, sollten Mail, FTP u.a. am wenigsten bekommen.

2.) Beispiel Filesharer - Downloadbegrenzung:
Hier gehört ebenfalls ein Limit.
Wenn ein User 1000 parallele Connections aufmacht, dann ist kurz die Leitung sowieso tot. Wenn aber die 1000 antwortenden Rechner alle via Slow Start gedrosselt werden, sind 2 wichtige Effekte erreicht:
- sehr schnell ist die Leitung wieder frei
- für den User wirds langsamer, als wenn er nur 5 parallele downloads hätte - Lerneffekt

Problem bei all diesen Lösungen ist natürlich, daß Window-Techniken wie Slow Start halt nur TCP-Features sind...
Wenn wer per UDB fährt - ists leider essig.

Re(6): bandbreite splitten

patos — Wed, 18 Apr 2007 14:19:23 GMT

möglich dass ich mich missverständlich ausgedrückt habe, aber einen cap bei ca 90% des downloadvolumens halte ich ebenfalls für sinnvoll. individuelle caps hingegen nicht.

Re: bandbreite splitten

googleDork — Wed, 18 Apr 2007 14:14:29 GMT

Bißchen oT:

Wenn mehrere Benutzer mit grob ähnlichen INet-Interessen aktiv sind, würde ich mir sowieso zusätzlich Squid überlegen... Falls nicht eh schon im Einsatz

Re(5): bandbreite splitten

googleDork — Wed, 18 Apr 2007 14:11:42 GMT

du kannst gar nicht so viele pakete verwerfen sodass du nicht ständig auf den buffer des modems kommst.

Genau deshalb limitiert ein Router ja ein paar Prozental unter dem Modem... Klarerweise muß der Router selbst der Flaschenhals werden, sonst ists sinnlos. Bei einer 1-Mbit-Leitung down würde ich dem RTR selbst nur 900-950 Kbit genehmigen...

und auf ein paket das ich verzögert bestätige, kommt keine timeout veranlasste wiederholung.

Unbestritten. Reordern durch Priorisierung nach Protokoll ist ein wichtiger Punkt... Damit der Router das aber effizient machen kann, sollte er auch der Engpaß sein - und nicht das Modem - siehe oben.

Es macht ja keinen Sinn, wenn der Router ein Ack-Packerl nach vorne sortiert, dein Modem aber noch mit der Abarbeitung seines Cachs noch 1-2 Sekunden beschäftigt ist - oder auch nur gerade erst das erste Bit eines Packerls mit maximaler *TRÖT*größe losgeschickt hat

Priorisierung finde ich also ebenfalls sehr wichtig - nur würde ich nicht auf Shapen verzichten (habe damit auch gute Erfahrungen gemacht)... Und man kann sich ja jederzeit durch ein "wget --limit-rate" Überzeugen, daß es paßt.

Re(3): bandbreite splitten

patos — Tue, 17 Apr 2007 22:53:17 GMT

http://www.polarcloud.com/tomato

Re(2): bandbreite splitten

bond007 — Tue, 17 Apr 2007 22:08:52 GMT

funktioniert bestens mit einer fremdfirmware für wrt54gl.

welche meinst du und wo findet man die ?

Re(10): bandbreite splitten

patos — Tue, 17 Apr 2007 18:10:35 GMT

eine verbindung ist eine sache. was darüber gesendet wird, eine ganz andere. während des verbindungsaufbaus kannst du einfach nicht erkennen was später darüber laufen wird, somit tust du dir ein wenig schwer, die anzahl der verbindungen im dunkel zu kontrollieren.

ist die etwa established, vergehen einige stunden bis die verbindung wegen eines timeouts geschlossen wird. paketverwerfen wäre also noch schlimmer, zumal verbindungen eher geschlossen werden bevor der timeout zuschlägt. sie würde einfach nur länger in der nat tabelle verweilen, was ja nicht ziel der sache sein kann.

die verbindungsanzahl pro rechner, wie du mal erwähntest, auf 200 zu beschränken, ist, physikalische machbarkeit vorausgesetzt, wegen dieses verhalten sehr kontraproduktiv, da du sowieso erst im nachhinein sagen kannst ob darüber filesharing läuft oder nicht.

ob die qos regeln selber ack-pakete an die gegenstelle schicken um verbindungen zu schliessen entzieht sich meinen kenntnissen. wäre jedenfalls zielführender, auch wenn ich glaube dass sowas einfach nicht stattfindet. zumindest nicht im "standardverhalten".

eine a priori verweigerung von verbindungen wegen eines selbst gesetzten hard limits ist deshalt nicht wirklich angebracht.

Re(9): bandbreite splitten

juwb — Tue, 17 Apr 2007 17:41:58 GMT

ipp2p und l7 filtern nicht, sie erkennen. was du dann damit machst ist ganz allein deine sache. du kannst diese verbindungen natürlich filtern, so daß sie gar nicht erst zustande kommen. du kannst sie aber auch einfach nur markieren und somit alle folgenden pakete dieser verbindung gesondert behandeln (eben in eine andere prioritätsklasse einteilen).

Re(8): bandbreite splitten

patos — Tue, 17 Apr 2007 17:30:38 GMT

Vielleicht, nur gibts nicht immer ein Lokal. Je nachdem wie viele Clients
es insgesamt gibt, bringts auch nichts mehr, wenn jeder "nur" 200 Verbindungen
aufmacht, wenns in der Summe dann wieder zig tausend sind

auch da bringt das cappen nichts. du bekommst nur verärgerte leute, die sich andauernd beschweren dass die anwendungen immer wieder timeouts haben. man nehme eine bessere nat maschine.

Das läßt sich sogar recht zuverlässig erkennen, siehe z.B. ipp2p oder
l7-filter. Damit läßt sich P2P auch portunabhängig komplett blockieren oder
die P2P-Verbindungen in eine restriktivere Klasse versetzen.

ähm... das ist was anderes. wir redeten über die anzahl der maximal möglichen verbindungen. filtert ipp2p oder ein l7 den verbindungsversuch aus, kommt sie gar nicht zu stande. in die nat tabelle kommt nur das rein, was erlaubt wurde.

edit: ipp2p & l7 können es gar nicht...

Re(8): bandbreite splitten

patos — Tue, 17 Apr 2007 17:30:38 GMT

Vielleicht, nur gibts nicht immer ein Lokal. Je nachdem wie viele Clients
es insgesamt gibt, bringts auch nichts mehr, wenn jeder "nur" 200 Verbindungen
aufmacht, wenns in der Summe dann wieder zig tausend sind

auch da bringt das cappen nichts. du bekommst nur verärgerte leute, die sich andauernd beschweren dass die anwendungen immer wieder timeouts haben. man nehme eine bessere nat maschine.

Das läßt sich sogar recht zuverlässig erkennen, siehe z.B. ipp2p oder
l7-filter. Damit läßt sich P2P auch portunabhängig komplett blockieren oder
die P2P-Verbindungen in eine restriktivere Klasse versetzen.

ähm... das ist was anderes. wir redeten über die anzahl der maximal möglichen verbindungen. ~~filtert ipp2p oder ein l7 den verbindungsversuch aus, kommt sie gar nicht zu stande. in die nat tabelle kommt nur das rein, was erlaubt wurde.~~

edit: ipp2p & l7 können es gar nicht...

Re(8): bandbreite splitten

patos — Tue, 17 Apr 2007 17:30:38 GMT

Vielleicht, nur gibts nicht immer ein Lokal. Je nachdem wie viele Clients
es insgesamt gibt, bringts auch nichts mehr, wenn jeder "nur" 200 Verbindungen
aufmacht, wenns in der Summe dann wieder zig tausend sind

auch da bringt das cappen nichts. du bekommst nur verärgerte leute, die sich andauernd beschweren dass die anwendungen immer wieder timeouts haben. man nehme eine bessere nat maschine.

Das läßt sich sogar recht zuverlässig erkennen, siehe z.B. ipp2p oder
l7-filter. Damit läßt sich P2P auch portunabhängig komplett blockieren oder
die P2P-Verbindungen in eine restriktivere Klasse versetzen.

Re(7): bandbreite splitten

juwb — Tue, 17 Apr 2007 17:12:33 GMT

DAS ist auch etwas, das lokal geschehen
sollte.

Vielleicht, nur gibts nicht immer ein Lokal. Je nachdem wie viele Clients es insgesamt gibt, bringts auch nichts mehr, wenn jeder "nur" 200 Verbindungen aufmacht, wenns in der Summe dann wieder zig tausend sind.

der router weiss nicht ob die verbindung die gerade gekappt wird,
diejenige vom browser ist oder die vom filesharing programm.

Das läßt sich sogar recht zuverlässig erkennen, siehe z.B. ipp2p oder l7-filter. Damit läßt sich P2P auch portunabhängig komplett blockieren oder die P2P-Verbindungen in eine restriktivere Klasse versetzen.

am besten kappt man gar nicht.

Am besten man hat so eine dicke Leitung, daß man immer alles sofort senden und empfangen kann egal wie weit man aufdreht

Re(3): bandbreite splitten

patos — Tue, 17 Apr 2007 16:57:55 GMT

http://forum.geizhals.at/t491595,4074856.html#4074856

Re(6): bandbreite splitten

patos — Tue, 17 Apr 2007 16:57:09 GMT

Bei einigen tausend Verbindungen ist beim Schmalspur-DSL sowieso die
Bandbreite durch den Verbindungsoverhead dahin.

nicht wirklich. problematisch wird es nur wenn das verhältnis zwischen download und upload zu gross wird.

Und die Anzahl offener Verbindungen läßt sich zum Glück wieder effektiver
kontrollieren

DAS ist auch etwas, das lokal geschehen sollte. der router weiss nicht ob die verbindung die gerade gekappt wird, diejenige vom browser ist oder die vom filesharing programm.

am besten kappt man gar nicht.

Wie gesagt, ich habe gute bis sehr gute Erfahrungen in der Praxis damit
gemacht, sowohl Up- als auch Download zu kontrollieren.

ich habe gehört, dass es ein tool gibt, welches meine bandbreite auf die einzelnen Computer verteilt.

dh. wenn man eine bandbreite von 2mb hat und 4 anwender, dass jeder anwender exakt 0,5mb bandbreite bekommt. der sinn ist, dass keiner eingeschränkt wird.

wo finde ich so etwas und wie richte ich das ein.

danke