bandbreite splitten

bandbreite splitten (61 Beiträge, 670 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

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
---------------------------------------------------------------------------------------------------------------
mfg JoJo
visit me: http://www.jo-jo.net

du kannst nur bei jeden einzelnen PC ein Programm installieren, welches die Bandbreite beschränkt (netlimiter, trafficlimiter oder was weiß ich wie sich die Proggys nennen) ...

VW Golf IV

Nennt sich QoS (Quality of Service), bessere Router können sowas.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Empfehlungen deinerseits solcher Router?

linksys wrt54g serie
____________________________________________________________________

Im
Frieden begraben Söhne ihre Väter. Im Krieg begraben Väter ihre Söhne.

(Herodot von Halikarnassos)

nö. qos ist was anderes. was er sucht ist throttling und sollte möglichst anwendungsbezogen stattfinden.

es bringt gar nichts die hälfte der pakete am router zu verwerfen, wenn diese bereits die gesamte bandbreite des modems belegt haben. der zweite user wird trotzdem nicht mit der anderen hälfte der downloadgeschwindigkeit runterladen können wenn das modem bereits ausgelastet ist.

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.

QoS

♫=♥ --> /pirat

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

QoS (Quality of Service) oder auch Traffic Shaping genannt. Funktioniert nur, wenn der Traffic durch einen zentralen Punkt fließt, an dem du das Ventil zudrehen kannst sozusagen. Zum Beispiel am Router, der diese Funktion jedoch unterstützen muß.

Unter Windows weiß ich von AVM Fritz Software, daß die sowas schon ziemlich lange unterstützt haben - war zumindest bei deren DSL PCI Karte so. Der gleiche Rechner verteilt damit auch das Internet an die anderen und kann dabei kontrollieren.

Für Linux gibts einige Scripte und Tools, ganz unterschiedliche Lösungen, z.B. FairNAT für gerechte Bandbreitenverteilung. Das schränkt Anwender nicht fest auf 0,5MBit runter, sondern setzt eben auf faire Gleichverteilung, d.h. die 0,5MBit pro User hättest du nur, wenn alle 4 User gleichzeitig online sind und diese Bandbreite auch gerade brauchen. Ansonsten entsprechend mehr. Bei einer festen Grenze von 0.5MBit würdest du deine Leitung ja nie ausreizen (wobei das auch gewollt sein kann, wenn für Traffic gezahlt werden muß).

Je nach System erfordert die Einrichtung wenig Know-How (AVM Fritz) und dafür auch wenig Einflußmöglichkeiten, oder sehr viel Know-How und dafür entsprechend viele Möglichkeiten, das Problem anzugehen (QoS unter Linux, wenn man es manuell einrichtet).

zufriedenstellend nur für den upload. eine priorisierung ist viel sinnvoller.

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

Ja, natürlich; volle Kontrolle hat man nur über den Upload. Was einem von außen geschickt wird ist eine ganz andere Geschichte. Aus meinen praktischen Erfahrungen heraus kann ich dir jedoch sagen, daß es - so abstrus es klingen macht - durchaus Sinn machen kann, eingehende Pakete von TCP/IP Verbindungen zu verwerfen, auch wenn diese dann bereits Bandbreite belegt haben. Wenn man wirklich gar keine andere Möglichkeit mehr hat, kann man so wenigstens noch die Eigenschaft von TCP-Verbindungen nutzen, daß das Gegenüber Pakete weniger/langsamer schickt und somit - auf lange Sicht - mehr Bandbreite freiwird, auch wenn so das eine oder andere Paket mehrfach übertragen werden muß.

Natürlich sollte man davor sämtliche Alternativen ausschöpfen, aber manchmal gibt es derer eben nicht allzuviele. Und die Methode funktioniert, obwohl sie brutal und ineffizient ist, erstaunlich gut. Bei mir (5er Studenten-WG mit DSL, wo jeder Hinz und Kunz schon alleine für sich die Leitung mit edonkey, azureus, etc. 24/7 ausgelastet hätte) wurde damit das Internet überhaupt erst benutzbar (statt 1000-2000ms Pings runter auf <200ms... das bei voller Leitungsauslastung. Ideal wären 80ms (kein Fastpath) gewesen).

Was wirklich sinnvoll wäre, ist wenn der Provider selber mitspielen würde und ich seinen Upload (bzw. meinen Download) auf seiner Seite genauso gut kontrollieren könnte wie ich meinen Upload.

Alles andere ist Quark, darauf zu vertrauen daß die Nutzer ihre Programme freundlich einstellen ist naiv, wenns denn nicht alles eigene Rechner sind; daher mußt du an einem zentralen Punkt kontrollieren und das ist nun mal der Router.

dass es irgendwie funktioniert bestreite ich nicht, tcp macht nichts anderes mit dem slow start. betrachtet man jedoch dass insbesondere bei filesharing einige tausende verbindungen anfallen, ist oft das warten auf einer windowreduktion fatal. du kannst gar nicht so viele pakete verwerfen sodass du nicht ständig auf den buffer des modems kommst. spätestens da sind alle bemühungen für ein qos für die katz.

ich gebe zu dass das nicht so oft passiert wenn man caps zwischen den usern verteilt, es passiert aber trotzdem. sind aber mal daten angekommen, dann sind sie eben da, sie zu verwerfen wäre kontraproduktiv denn die zustellung kostet so gut wie nichts an resourcen. und auf ein paket das ich verzögert bestätige, kommt keine timeout veranlasste wiederholung.

sinnvoller jedoch ist eine scharfe upload priorisierung. hast du etwa 512 kbit/s upload, erlaube halt nur 350 in der tiefsten prioritätsklasse als standard für alle. den rest lässt du für andere anwendungen wie web/mail/icq zu. ack, dns & voip auf die höchste stufe, dann sollte dein ping mindestens genau so niedrig sein wie mit individuellen caps, nur mit dem unterschied dass ihr viel mehr aus der leitung herausholen könnt.

17.04.2007, 19:42 Uhr - Editiert von patos, alte Version: hier

Bei einigen tausend Verbindungen ist beim Schmalspur-DSL sowieso die Bandbreite durch den Verbindungsoverhead dahin. Und die Anzahl offener Verbindungen läßt sich zum Glück wieder effektiver kontrollieren. Wie gesagt, ich habe gute bis sehr gute Erfahrungen in der Praxis damit gemacht, sowohl Up- als auch Download zu kontrollieren.

Heute wohn ich zum Glück nicht mehr da; wenn man die Leitung nicht teilen muß, reichts in der Tat völlig aus, nur den Upload zu kontrollieren.

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

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.

möglich, nur ginge es weit effektiver...

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

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...

17.04.2007, 20:14 Uhr - Editiert von patos, alte Version: hier

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).

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

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.

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 ?

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

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

port 80 eh immer durch Squid abgefangen wird...

Also wenn das WG oder ähnliches ist...

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

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

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 ?

18.04.2007, 18:12 Uhr - Editiert von googleDork, alte Version: hier

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.

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 ?

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.

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.

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.

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.

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.

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

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

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

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

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

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

wenn b, c und d nichts downloaden, warum sollte a nicht mit vollem speed auf die leitung zugreifen können? einfach dienste, ports und ips priorisieren und fertig. surfst du herum muss eben der bittorrent download der anderen maschine warten. hörst du auf kann die maschine wieder saugen. as easy as that.

funktioniert bestens mit einer fremdfirmware für wrt54gl.

puh, und wie stellst das für zig verschiedene Rechnern ein?

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

funktioniert bestens mit einer fremdfirmware für wrt54gl.

welche meinst du und wo findet man die ?

007

Help the World Γνώθι σεαυτόν

http://www.polarcloud.com/tomato

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...

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.

18.04.2007, 17:43 Uhr - Editiert von patos, alte Version: hier

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

18.04.2007, 18:56 Uhr - Editiert von patos, alte Version: hier

Heyhey...

Im Vergleich zu anderen Usern

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

OK zahlst nen Liter.

bin ich ja günstigst

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

ich würd dieses tool verwenden:

http://www.netlimiter.com/

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

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung