Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

OS Linux

collisions

wstolk
9 antwoorden
  • Wordt een beetje gek van een door mij geinstalleerde server :(
    betrefd een klein windows netwerk met een servertje
    outer op linux
    [code:1:3c2f388fb1]
    eth0:
    UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1
    RX packets:18383612 errors:0 dropped:0 overruns:0 frame:0
    TX packets:12030740 errors:0 dropped:0 overruns:0 carrier:0
    collisions:5125 txqueuelen:100
    Interrupt:11 Base address:0xe400

    eth1 Link encap:Ethernet HWaddr 00:60:97:72:05:AD
    inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
    inet6 addr: fe80::260:97ff:fe72:5ad/10 Scope:Link
    inet6 addr: fe80::60:9772:5ad/10 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:12322223 errors:12 dropped:0 overruns:12 frame:12
    TX packets:17471292 errors:0 dropped:0 overruns:0 carrier:57
    collisions:48696 txqueuelen:100
    Interrupt:10 Base address:0x300
    [/code:1:3c2f388fb1]

    hoe kom ik van die collisons af ??
    Of beter hoe komt het dat er zoveel zijn ??
  • Je hebt helemaal niet veel collisions, op je lokale netwerkkaart heb je er +/- 50000 per +/- 30 miljoen pakketten, wat ongeveer 1 collision per 600 pakketten is.
    Collisions zijn heel normaal en eigen aan het ethernet protocol. Een collision wil gewoon zeggen dat er twee pc's toevallig tegelijk een pakketje sturen, maar er is maar ene kabel (of beter: alles passeert langs dezelfde hub), dus zo'n pakketjes durven al wel eens botsen, waardoor ze kapot gaan en niet meer (goed) aankomen.
    Immers, pc's weten nooit van elkaar wanneer ze juist een pakket gaan sturen, dus het enige wat zo'n pc (of beter, ethernet adapter) kan doen is het proberen te versturen en opnieuw proberen als er collision geweest is (een collision kan dus gedetecteerd worden, hoe juist weet ik niet, er ontstaat in elk geval een speciaal "signaal" wanneer collision optreedt en dat wordt dan door alle pc's op het netwerk opgevangen).
    Eens dat er collision geweest is, zal zo'n ethernet adapter random kiezen tussen ofwel een klokcyclus wachten, ofwel onmiddelijk nog eens proberen. (om te vermijden dat de twee pc's terug meteen gaan proberen, want dan gebeurt er uiteraard weer een botsing). Hoe meer collisions er na elkaar optreden, hoe groter de kans dat de ethernetkaart beslist om nog een klokcyclus te wachten, zodat de kans op een nieuwe collision steeds kleiner wordt na elke poging. Meer concreet: de kans dat een ethernet adapter zal proberen te versturen, is 1 op 2 tot de i-de macht, met i het aantal collisions dat al is opgetreden.
    Enfin, dit om even uit te leggen dat collisions onvermijdelijk zijn en hoe er mee omgegaan wordt.
    1 collision op 600 is dus heel normaal voor een netwerk met een paar pc's, het netwerk hier thuis bestaat uit 4 pc's waarvan 1 linux-router en ik heb 1 collision per 200 pakketten (op mijn intern netwerk dus)
    Op je internetverbinding heb je blijkbaar nog veel minder collisions, wat ook logisch is omdat de kabel tussen je adsl/kabelmodem en je pc met niks anders wordt gedeeld.
    Kortom: er valt niks aan te doen, tenzij naar iets anders overschakelen dan ethernet, zoals token ring, maar dat is op kleinere netwerken zéker niet efficiënter dan ethernet, omdat dan elke pc om de beurt een stukje "zendtijd" krijgt, of hij nu iets wil verzenden of niet. Dus als een pc niks wil versturen, gaat er weer wat tijd verloren.
  • Ok thanks voor je uitleg en dat is dan ook een geruststelling :D

    In het betreffende netwerk wordt idd een hub gebruikt. met een switch heb je er minder last van ?
    thuis heb ik ze nml. nauwelijks en op mijn werk (alleen maar switches) ook bijna niet terwijl juist daar veel verkeer is (nfs /home op de server)

    Zal morgen eens kijken hoeveel het er daar zijn :D

    Maar ik begrijp uit je uitleg dat het niet een netwerkfout is dus laat ik het zo :wink:
  • het principe van meten van collisions is heel gemakkelijk.

    bij elk pakettje wat verstuurd is… krijgt de verzender een packetje terug terzijnde als: " hallo ik heb het hoor, kun je de rest ook ff doen? dank u"
    wanneer er een collision optreed .. wordt dit pakkettje van ontvangst niet verstuurd en dus wordt hij opnieuw verstuurd. dit allemaal in een fractie van een miliseconde uiteraard.

    let maar eens op als je download van inet..zonder dat je upstream traffic heb… je hebt altijd staan upstream wanneer je download… en andersom
  • Nou, dat van die acknowledgements klopt ook wel, maar collision op ethernet wordt toch ook nog op een andere manier gedetecteerd. Er kunnen immers ook nog pakketten verloren gaan door andere redenen dan collision (bv. als de doel-pc de data niet snel genoeg kan slikken), en in dat geval moet heel de collision-handling procedure niet uitgevoerd worden. Als er collision optreedt, worden alle machines in het netwerk daarvan verwittigd met een speciaal signaal (het JAM-signaal), zodat ze weten dat ze best niet onmiddelijk beginnen met sturen.

    Trouwens, een acknowledgement over ethernet is iets totaal anders als een acknowledgement over TCP/IP. Als je bij het downloaden over internet nog upload hebt, wordt die vooral veroorzaakt door het acknowledgement systeem van TCP/IP.

    En, wstolk:
    Een geavanceerdere hub/switch (zoals de duurdere 3com modellen) kan dat probleem inderdaad gedeeltelijk ondervangen, omdat die de pakketjes gaat bekijken en "ziet" aan welk mac-adres (van een ethernet adapter) een pakket gericht is, en dat dan ook enkel naar de poort waar de betreffende pc op hangt doorsturen. Een simpele hub zoals bij mij thuis doet dat niet, en stuurt alles wat binnenkomt door naar alle andere pc's in het netwerk, die dan zelf maar moeten beslissen of ze het pakket aannemen en acknowledgen of niet. Dat maakt het mogelijk om te "sniffen", nl. het aannemen van pakketjes die niet voor u bedoeld zijn. De ethernetadapter draait dan in "overspelige" modus, en neemt alle pakketjes aan zonder ze te acknowledgen (want dat moet gebeuren door de ethernetadapter aan wie de pakketten écht gericht zijn). Zo kan je dus makkelijk netwerkverkeer afluisteren, en er bestaan genoeg linux-tooltjes om dat (ongemerkt) te doen.

    Ohja, het kan overigens wel zijn dat er te buitensporig veel collisions optreden, als er bv. een slechte netwerkkaart in 't netwerk zit, of er slechte drivers gebruikt worden voor zo'n netwerkkaart (bekend voorbeeld zijn de realtek8029 drivers die in win98 1e editie zitten), of door slechte bekabeling.
    In dat geval merk je het wel direct door de buitengewoon lage transfersnelheden, en op mijn hub zie je dan 't collision lichtje bij zowat elke activiteit flikkeren :)
  • Als het aantal collisions buiten verhouding (tov het aantal clients) hoog is kan ook de hub stuk zijn. Maar een non-switched ethernet-netwerk kan niet anders dan veel collisions hebben.
  • [quote:dd8638da01="Bamboe"]Nou, dat van die acknowledgements klopt ook wel, maar collision op ethernet wordt toch ook nog op een andere manier gedetecteerd. Er kunnen immers ook nog pakketten verloren gaan door andere redenen dan collision (bv. als de doel-pc de data niet snel genoeg kan slikken), en in dat geval moet heel de collision-handling procedure niet uitgevoerd worden. Als er collision optreedt, worden alle machines in het netwerk daarvan verwittigd met een speciaal signaal (het JAM-signaal), zodat ze weten dat ze best niet onmiddelijk beginnen met sturen.

    Trouwens, een acknowledgement over ethernet is iets totaal anders als een acknowledgement over TCP/IP. Als je bij het downloaden over internet nog upload hebt, wordt die vooral veroorzaakt door het acknowledgement systeem van TCP/IP.

    [/quote:dd8638da01]

    hmmm ja..daar zit wat in natuurlijk.. :)
  • [code:1:7800830803]
    maas
    oot# ifconfig
    eth0 Link encap:Ethernet HWaddr 00:E0:4C:49:65:F7
    inet addr:192.168.229.1 Bcast:192.168.229.255 Mask:255.255.255.0
    inet6 addr: fe80::2e0:4cff:fe49:65f7/10 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:41891710 errors:0 dropped:0 overruns:0 frame:0
    TX packets:46075710 errors:0 dropped:0 overruns:10 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:212806706 (202.9 Mb) TX bytes:2983932679 (2845.6 Mb)
    Interrupt:11 Base address:0x2000

    ippp1 Link encap:Point-to-Point Protocol
    inet addr:10.1.2.6 P-t-P:10.1.2.5 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP DYNAMIC MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:30
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

    [/code:1:7800830803]

    Géén collisions :D

    [code:1:7800830803]
    maas
    oot# uptime
    12:42pm up 119 days, 16:01, 1 user, load average: 0.09, 0.02, 0.01
    [/code:1:7800830803]

    en hier betrefd het dus een switched netwerk met 9 linux clients en 3 windows bakken :D
  • Dat is HET voordeel van switching ja….

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.