bash! Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 Door trage buffering is het soms beter om juist een lagere MTU size te kiezen. Hierdoor volgen de pakketten elkaar sneller op, maar kunnen ze ook sneller verwerkt worden door de ontvangende kant. Stel dat de ontvangst buffer volloopt op de server (reëele kans) dan worden de daarop volgende paketten overboord gegooid totdat er weer ruimte is in de buffer. De verloren paketten dienen echter wél ontvangen te worden. Hierdoor moet de server het betreffende pakket wederom aanvragen wat natuurlijk de nodige overhead veroorzaakt. Deze overhead door retransmissions is vele malen groter dan het percentage overhead dat je krijgt door een iets lagere MTU size. Houd hier dus rekening mee <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> Tevens: Indien er enkele paketten verloren raken stapelt het probleem zich enorm op... De server wil namelijk de pakketjes wel in de juiste volgorde plaatsen dus moet hij eerst wachten tot een bepaald pakket binnen is voordat hij weer verder kan gaan met wegschrijven. Dit kan je overigens met een sniffer goed meten! Indien je een "intelligente" switch hebt kan je ook het een en ander aan interessante info zien <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> small note: Sommige netwerk drivers kunnen dynamisch geheugen reserveren voor buffering. Dit kan enorm schelen zolang dit buffer geheugen maar op de NIC zelf zit! There is nothing wrong with having a strong opinion... if it comes with an open mind!
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 Citaat: 28 vrij houden voor de overhead dus Als je je mtu op 1500 zet dan is de 28 bytes inbegrepen, je hebt een overhead van 28bytes in die 1500. Alleen als je bv een vpn sessie gaat opzetten dan moet je je mtu lager zetten omdat de vpn de hele 1500 inpakt in een pakketje, dan heb je de overhead van de vpn erbij, gevolg is dat elk pakketje gesplitst word. Genoeg erover, eerst maar eens zien hoe het met de db zit, met de ping test lijkt het goed te staan, maar ik wil graag de waarde in een cfg bestand zien, zodra ik dat gevonden heb. Tips welkom <img src="/ubbthreads/images/graemlins/wink.gif" alt="" /> De topic is wel heel erg veranderd intussen, hadden we beter een nieuwe kunnen beginnen.
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 Citaat: De verloren paketten dienen echter wél ontvangen te worden. Hierdoor moet de server het betreffende pakket wederom aanvragen wat natuurlijk de nodige overhead veroorzaakt. Als ik mij niet vergis, word het per UDP protocol verstuurd, dat betekend dat alle packets die niet goed aankomen om wat voor reden dan ook gewoon gedropt worden. Weg is weg. Was het nu op TCP protocol, ja dan MOETEN de datapaketjes die gedropt zijn weer opnieuw gestuurd worden, als dat het geval zou zijn krijg je grote problemen met de db omdat ie dan erg snel uit zijn geheugen loopt, of de buffer moet bijzonder groot zijn, komt ook bij dat elk verstuurd data pakketje met tcp protocol bevestigt moet worden wat weer een enorme overhead veroorzaakt. Dus door het UDP protocol krijg je dus het fenomeen "Dropped Frames". Het is gewoon uitproberen wat het beste mtu waarde is. Als je bv Sisco switch gebruikt kan deze bijzonder hoog gezet worden, gebruik je een simple hub dan zal je hem beter lager zetten.
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 wat weer heel aannemelijk klinkt aangezien de 500-s geen geheugen genoeg heeft om niet ontvangen pakketten te bufferen om deze evt opnieuw te versturen. groet kamaradski
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 Niet alleen de db500 zal dit probleem hebben hoor, ik vermoed alle db varianten.
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 ga via telnet en type in "ifconfig" dan krijg je een lijstje waar je kunt zien dat de db op 1500 is ingesteld. ik ben er nog niet achter of je via dit commando de mtu kunt aanpassen maar het is een script van 340kb dus zal vast wel wat meer kunnen dan een lijstje op scherm toveren <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> verder zijn er nog de scripts: adsl-start adsl-stop adsl-status adsl-connect streamsec streampes streamts inetd iptables route deze lopen allemaal via "busybox" en kunnen gewoon ingetypt worden via telenet. en hebben allemaal iets met netwerk of streaming te maken. telnet is voor mij geheel nieuw en moet er dus nog thuis geraken. excuse mij als ik hier iets vermeld wat al algemeen bekend is... maar vooral die ifconfig ga ik ff mee lopen spelen. ben er aleen nog niet achter waar deze gegevens opgeslagen worden. groet kamaradski
Gast Geplaatst: 4 november 2004 Geplaatst: 4 november 2004 <img src="/ubbthreads/images/graemlins/biggthumpup.gif" alt="" />kamaradski Kun je gelijk zien of je veel errors hebt. Probeerde het eens op de sisco manier om instellingen te wijzigen, helaas.
Gast Geplaatst: 5 november 2004 Geplaatst: 5 november 2004 ifconfig eth0 mtu 570 veranderd de mtu in 570. wat die eth0 doet ben ik nog niet achter. verbazend wat je zoal uit die config files kan trekken <img src="/ubbthreads/images/graemlins/laugh.gif" alt="" /> hoe bedoelde je met die errors ? btw ik ga eerst pitten. morgen weer een dag. groet kamaradski
Gast Geplaatst: 5 november 2004 Geplaatst: 5 november 2004 Ik ga hierna ook pitten hoor, maar wat antwoorden op je vragen, eth0 betekend Ethernet 0, ofwel je netwerkaansluiting op je db. En wat errors betrefd, als je dus ifconfig doet krijg je dus een overzicht te zien, daar staat ook een soort log in, let dan vooral op deze regels, RX packets:5645 errors:0 dropped:0 overruns:0 frame:0 TX packets:2033 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX is voor ontvangen data en TX is voor verzonden data, wat daar verder achter staat lijkt me vrij duidelijk, beste is waarde 0 voor errors, dropped en overruns, want dat betekend dat de netwerk uitstekend is. Hoe hoger het getal hoe groter je problemen zullen zijn. Mijn ervaaring is dat als het niet op 0 staat het niet per defenitie een probleem is, het kan nou eenmaal voorkomen dat er wat errors zijn, ethernet is nou eenmaal collision based en daardoor zeker niet het beste type netwerk. Zelden zie ik 60% of meer in snelheid van een 100Mbit/s netwerk op ethernet, met 60% loopt het zelfs uitstekend, maar verwacht ook niet meer dan dat. Is het niet handig om een nieuwe threat aan te maken als we hier mee door gaan met de titel "Netwerk van een Dreambox ontrafeld"? <img src="/ubbthreads/images/graemlins/crazy.gif" alt="" />
Gast Geplaatst: 5 november 2004 Geplaatst: 5 november 2004 Is het niet handig om een nieuwe threat aan te maken als we hier mee door gaan met de titel "Netwerk van een Dreambox ontrafeld"? misschien wel. maar dit heeft ook nog steeds met een mount te maken, een beetje.. tevens lijkt het mij dat de titel die de thread nu heeft ook voor een beetje herkenning zorgt bij de lezers. maar ja hiervoor hebben we tenslotte de mod's. iniedergeval heb ik op 600mb verstuurde data 0 errors. dus waarom ik dan toch die blokken in mijn opname heb ? ook met tuxtv blokt ie een beetje. tevens heeft de box de neiging om halverwege de getimde opname zomaar te stoppen met opnemen. (dit zou toch op errors duiden) zal morgen eens met de mtu spelen en weer een zooitje opnames maken. mocht er dan geen verandering optreden zal ik mijn speedtoutch multi-pc modem eens omzeilen door er een snelle hub tussen te gooien, en anders een crosslink te maken. misschien dat daarmee het initiele probleem op te lossen is. ga nu echt pitten <img src="/ubbthreads/images/graemlins/smile.gif" alt="" /> truste kamaradski
Gast Geplaatst: 5 november 2004 Geplaatst: 5 november 2004 zo, ff met ping en mtu lopen spelen richting de dreambox. en het lijkt erop dat deze het beste op 1500 kan staan. Pinging [10.0.0.155] with 40 bytes ->bytes=40 time=0ms TTL=64 Pinging [10.0.0.155] with 750 bytes ->bytes=750 time=0ms TTL=64 Pinging [10.0.0.155] with 1125 bytes ->bytes=1125 time=0ms TTL=64 Pinging [10.0.0.155] with 1312 bytes ->bytes=1312 time=1ms TTL=64 Pinging [10.0.0.155] with 1406 bytes ->bytes=1406 time=1ms TTL=64 Pinging [10.0.0.155] with 1453 bytes ->bytes=1453 time=1ms TTL=64 Pinging [10.0.0.155] with 1476 bytes -> ..fragmented Pinging [10.0.0.155] with 1465 bytes ->bytes=1465 time=1ms TTL=64 Pinging [10.0.0.155] with 1470 bytes ->bytes=1470 time=1ms TTL=64 Pinging [10.0.0.155] with 1473 bytes -> ..fragmented Pinging [10.0.0.155] with 1472 bytes ->bytes=1472 time=1ms TTL=64 ik ga heb nu zowel op de box als op de pc eens instellen op 750, enig idee of ik dan ook in de router de mtu moet aanpassen, of maakt dit niets uit ? groet kamaradski edit: bij een medesatter hier in de uurt een filmpje opgehaald welke met de 7000 opgenomen is vanaf sbs6. het afspelen hiervan gaat vlekkeloos en zonder blokken, tenminste de eerste 10min en dan stopt ie zomaar. dit betekend waarschijnlijk dat het toch niet een het netwerk ligt en dat het probleem in de image of in de box gezocht moet worden. tevens heb ik mijn netwerk instellingen geoptimalizeerd met een tool van speedguide. evt kan ik deze instellingen hier posten.
Gast Geplaatst: 6 november 2004 Geplaatst: 6 november 2004 Citaat: ik ga heb nu zowel op de box als op de pc eens instellen op 750, enig idee of ik dan ook in de router de mtu moet aanpassen, of maakt dit niets uit ? Zou het zeker doen, ik heb menig sisco router onderuit zien gaan als de mtu niet goed staat, buiten dat zoals ik al eerder schreef, alles op elkaar afstellen, dan loopt het het beste(met de ideale grote natuurlijk) Zelfs adsl router zyxel gaat spontaan rebooten als ik gekke dingen gaat doen met de mtu. Maar meestal alleen als je veel data overstuurd of veel verbindingen tegelijk aan maakt.
Gast Geplaatst: 9 november 2004 Geplaatst: 9 november 2004 zo, ik heb nu weer ff tijd hiermee bezig te zijn. ik vroeg mij af wat de volgende dingen betekenen bij nfs-setup: - options hier heb ik "RW" staan wat volgensmij Read-Write betekend ? - extra hier staat standaard "nolock, Rsize & Wsize. wat doet nolock precies? en rsize en wsize lijken mij de read en write grote. kan ik deze zonder problemem veranderen? tevens zijn er nog een paar andere instellingen mogelijk bij: options. zoals: - rw, soft ?? - rw, udp...waarschijnlijk gebruikt ie dan de udp-protocol ipv tcp ? graag reacties van iemand die hiermee al heeft lopen stoeien. of een url waar dit netjes wordt uitgelegd. groet kamaradski
-= [ Appien ] =- Geplaatst: 9 november 2004 Geplaatst: 9 november 2004 Citaat: wat doet nolock precies? Als je nolock niet gebruikt duurt het soms wel 2 minuten voordat je nfs gemount is..
Gast Geplaatst: 9 november 2004 Geplaatst: 9 november 2004 ik ben er inmiddels wel achter dat als ik de "rsize" en "wsize" bij "extra" de mtu waarde van het netwerk meegeef (1500) dat de opnamen niet aleen gaan bloken maar ook hevig gaan haperen. dit is dus een "nogo". @ appien, thz het is nog geen volledige verklaring wat het precies doet, maar duidelijk is dat "nolock" dus wel aan moet staan. ik zal nog wat meer moeten googleén hier naar. groet kamaradski edit: voor de speedtouch gebruikers wil ik even het volgende vermelden ivm het veranderen van de mtu voor de LAN. (let wel, niet voor de verbinding naar buiten. Start hiervoor een telnet sessie op. Klik op START -> UITVOEREN -> CMD -> telnet xxx.xxx.xxx.xxx (waar xxx... het ip adress van het modem is.) Username & paswoord: dit het je zelf ingegeven, indien je geen hebt ingegeven, druk dan gewoon enter. =>ip iflist Normaal is de grootte rond de 1500 =>ip ifconfig intf=eth0 mtu=xxx (xxx de nieuwe waarde...) =>ip iflist => saveall suc6 kamaradski
Aanbevolen berichten
Maak een account aan of log in om te reageren
Je moet een lid zijn om een reactie te kunnen achterlaten
Account aanmaken
Registreer voor een nieuwe account in onze community. Het is erg gemakkelijk!
Registreer een nieuwe accountInloggen
Heb je reeds een account? Log hier in.
Nu inloggen