Op vrijdag 06 april 2001 19:43 schreef Red devil het volgende:
[..]
Sorry misschien was ik wat onduidelijk maar ik bedoelde dat de child classes van elkaar kunnen lenen. Als client 1, 2, 4 en 5 niet online zijn kan client 3 van 1, 2, 4 en 5 lenen. Dan heeft ie dus wel de juiste bandbreedte van 50k/s
[..]
LOL we bedoelen hetzelfde maar zeggen het anders.
Ik heb tot nog toe altijd begrepen, dat
alle child-classes lenen van de root-class. Zodra andere child-flows dus niet actief zijn (beter: ze benutten niet hun volledige bandbreedte), betekent dit dat er in de root-class bandbreedte extra over is dat te vergeven is aan het child-class dat meer bandbreedte nodig heeft.
Dit betekent in de praktijk dat je het je voor kan stellen alsof je die bandbreedte leent van een andere child-class (is het nog te volgen of niet:?, anders ligt het vast aan mij:))
Verder schijnt het zo te zijn dat sharing van bandbreedte via een TCP flow niet eerlijk verdeeld wordt. Dit schijnt te maken met het feit, dat TCP al enigszins "eerlijk" is en het heeft te maken met de huidige realisatie van CBQ.
[..]
Hmmm ik gebruik ook CBQ (met een beetje lenen) op een p60 met kabelverbinding, zit de hele tijd in zijn neus te vreten volgens mij!
[..]
Ik heb hier geen child-classes draaien, dus ik kan dat zelf niet helemaal beamen of tegenspreken. Ik heb daarentegen wel eens een benchmark gezien, waarin toch wel duidelijk was, dat wanneer je met een dergelijke structuur gaat werken, dat de load hoger wordt en daarop volgend de hoeveelheid data die verwerkt kon worden binnen een bepaald tijdsbestek lager werd.
Op zich als je erover na gaat denken zou dat ook niet zo vreemd zijn, omdat er continu in alle classes gecontroleerd moet worden zodra een classe zijn bandbreedte overschrijdt of er ergens nog geleend kan worden, terwijl je bij een normale CBQ implementatie dan gewoon niet meer bandbreedte hebt en het dus in de queue terecht komt.
Wat ik verder bedoelde met de regel dat een child-class nooit de maximale bandbreedte van de root-class kan benutten is hetvolgende:
Het schijnt zo te zijn dat als slechts één child-class actief is en alle andere child-classes zijn niet actief (met actief bedoel ik dus dat er een flow is), dat je dan vaak niet de volledige bandbreedte van de root-class kan benutten. Ook dit is iets, wat ik dus niet zelf ondervonden heb o.i.d. maar allemaal van horen zeggen en internet bronnetjes etc.
Ja, je kunt dan toch bij de clients alles op bijv 1500 mtu zetten ofzo?
[..]
CBQ gebruikt het mechanisme van gemiddelde packet-groote om te bepalen hoeveel packets hij door moet laten voor een bepaalde class.
Aan de hand hiervan bepaald hij een parameter waarin bij wordt gehouden of een flow al aan zijn maximale bandbreedte zit.
Als die paramater nu wordt bepaald door een verkeerd gemiddelde betekent dit dat de parameter kleiner dan nul wordt. Zodra deze parameter <0 dan betekent dit op zijn beurt weer dat de flow aan z''n maximale bandbreedte zit. (Dit terwijl dit door die verkeerde gemiddelde packet-grootte helemaal niet het geval hoeft te zijn).
Een MTU geeft de maximale packet-grootte in een frame aan. Zodra 2 clients met elkaar gaan communiceren, dan wordt de kleinste MTU waarde door beide clients gebruikt.
Hoe lager de MTU hoe kleiner de packets zijn dus. Dit heeft als nadeel dat er dus meer packets verstuurd moeten worden; dit geeft een extra overhead!
Verder is een er het probleem dat een aantal programma''s zich niet aan de MTU houden , er valt dan te denken aan multimedia audio packets etc. Ook met sommige tcp-flows wil dit nog wel eens mis gaan (=afhankelijk van de maximale segment-grootte (MMS)).
Al deze problemen zijn wel gedeeltelijk op te lossen, door inderdaad een goede MTU te kiezen, zodat CBQ een goed ggemiddelde kan bepalen. Probleem is echter dat je dan wel voor elke klasse een gemiddelde MTU moet zien te achterhalen.
edit:
bijkomend probleem schijnt te zijn dat bij CBQ met een root-child indeling kleinere packets meer bandbreedte kunnen gebruiken dan wanneer er grotere packets gebruitk worden
[..]
Daarom stelde ik de vraag hoeveel clients er zijn om dan 50 gedeeld door aantal clients classes aan te maken.
10 clients is 10 classes van 5 k elk die allemaal van mekaar kunnen lenen.
In theorie is dit toch zeker dynamisch?
Maar ik heb er te weinig verstand om te kunnen zeggen dat het ook echt zo werkt.
Nee dit is niet volledig dynamisch (wel bijna). Het probleem is dus zoals ik eerder al genoemd heb, dat er eventueel meer clients dan je aantal child-flows zouden kunnen verbinden. Gevolg is dan dat er meerdere clients in één flow komen. Als alle andere flows ook bezet zijn, onstaat een oneerlijk situatie op die manier.
Verder geldt nog bovenstaand probleem, van die maximale bandbreedte benutting.
Een volledige dynamische oplossing, zou dus afhankelijk van het aantal clients een minimale bandbreedte kunnen garanderen. Deze is dus variabel.
/me heeft wel weer ff genoeg getikt dacht ie zo
edit:
Ik hoop dat het allemaal een beetje te volgen is wat ik allemaal ingetikt heb, anders ligt het waarschijnlijk aan m''n uitleg:P
)
foutmelding dus, heb ik dus toch niet goed mijn kernel gecompileerd?
inderdaad! bedankt he!:strip_exif()/u/13214/schanulleke.gif?f=community)
:strip_icc():strip_exif()/u/1522/crop5f4a0291a77ba_cropped.jpeg?f=community)
:strip_exif()/u/2043/313546.gif?f=community)