[Netwerkverttraging] 350 mtr. (versterkt met switching hubs)

[Anoniem: 75994]

Ik heb ruim twee jaar geleden een netwerkverbinding van ons woonhuis naar onze zaak gelegd (Anoniem: 75994 in "-= Het grote topic voor NETTE LAN afwerk..."), zodat ze ook daar gebruik kunnen maken van internet. Nu er ook nog een backup-systeem achter hangt die van dit netwerk gebruik maakt, is het helemaal functioneel.

Het probleem zit hem echter in de snelheid. Deze zakt, over het hele traject gezien, naar de 300 kbit/sec. Het hele netwerk is 100 mbit, dus dat moet beter kunnen. Zeker als je bekijkt dat het backup-systeem zo'n 7 à 8 GB per nacht over moet pompen (en vooral dat hij 's morgens klaar is).

Nu probeer ik er achter te komen waar de bottle-neck zit. Na wat trajectmetingen tussen de versterkende hubs door, kom ik tot de conclusie dat deze zorgen voor vertraging. Zoals ik in bovengenoemd topic al genoemd had, is de weerstand in alle trajecten niet noemenswaardig. Ik heb van alle adapters de output gemeten en die komt telkens op ongeveer 17 V onbelast. Dat betekent dat hij zo'n 12 V belast overhoudt (volgens de specificaties genoeg). Ook dat is dus in orde.

Kan het zijn dat de vertraging zit in het feit dat het switching hubs zijn? Mijn vermoeden is dat de vertraging komt doordat de hub alle data alle kanten opstuurt. Correct me if I'm wrong.

Zou een echte switch het probleem in de vertraging oplossen?

[FatalError]

Officieel mag jouw opstelling wel (of heb je toch stiekem meer dan 4 hubs op n rij?), maar ik denk ook dat het vervangen van de hubs door echte switches VEEL verschil gaat maken. Simpele switches zijn niet zo duur, en je zou er eventueel best n aantal kunnen lenen om te testen, lijkt me

[ Voor 10% gewijzigd door FatalError op 24-09-2005 12:41 ]

[Anoniem: 75994]

In het geval van het backup-systeem zitten er in totaal 5 hubs tussen (van de cliënt naar de server). Officieel mag het dus niet...

[Anoniem: 88882]

kun je niet beter gewoon een glasvezellijntje laten leggen. is tegenwoordig ook niet zo duur meer. en weet je 100% zeker dat je dan klaar bent.

[BHQ]

Dan zou ik de hubs maar vervangen voor switches. Hubs flikkeren idd. de data over alle poortjes heen en 5 hubs is gewoonweg teveel..

[Anoniem: 75994]

Een beetje zonde van al die tijd die er toen ingestoken is. De UTP gaat 100 meter door de grond (door tyleenbuis), door stallingen, noem maar op. Een 100 mbit verbinding moet genoeg zijn, moet het alleen niet vertragen.

---

Edit:

Zouden de Linksys 5 poorts switches (EZXS55W-EU) het probleem kunnen oplossen?



10/100 5-Port Workgroup Switch
Specifications
Model EZXS55W
Standards IEEE 802.3, IEEE 802.3u
Ports Five 10/100 RJ-45 Ports,
One Shared RJ-45 Uplink Port
Cabling Type UTP Category 3 or better (10BaseT),
UTP Category 5 or better (100BaseTX)
LEDs Power
Link/Act, FD/Col, 100 (per port)
Environmental
Dimensions 4.33" x 3.43" x 1.26"
(W x H x D) (110 mm x 87 mm x 32 mm)
Unit Weight 6.00 oz. (0.17 kg)
Power 7.5V DC, 700 mA
Certifications FCC Class B, CE Mark
Operating Temp. 32ºF to 122ºF (0ºC to 50ºC)
Storage Temp. -4ºF to 158ºF (-20ºC to 70ºC)
Operating Humidity 10% to 85%, Non-Condensing
Storage Humidity 5% to 90%, Non-Condensing

[ Voor 69% gewijzigd door Anoniem: 75994 op 24-09-2005 14:42 ]

[FatalError]

Vervang voor de grap eens n enkele hub ergens in het midden door een switch (die kan je vast wel ergens lebnen).

[BHQ]

Anoniem: 75994 schreef op zaterdag 24 september 2005 @ 14:18:
[afbeelding]

Die krengen zouden in principe gewoon moeten werken.Het is slechts een doorlus en er gaat dus 1x 100 mb/sec doorheen, dat trekt-ie wel.

[Klippy]

Misschien snap ik het niet, maar ik zie de situatie als volgt:

code:

Kabel-HUB-Kabel-HUB-Kabel

Dus gewoon één lange kabel in princiepe over 350 meter; in het midden versterkt met 2 of 3 HUBs.

Dan hebben die HUBjes toch zeker maar 1 poort in gebruik?
En dan maakt het toch ook geen hol uit of daar een HUB of een switch tussen staat?
Het is toch gewoon éénrichtingsverkeer... alles dezelfde kant op (en ook wat terug naturllijk ja)..

[Koppensneller]

Het is meer:

code:

HUB1-kabel-HUB2-kabel-HUB3-kabel-HUB4-kabel-HUB5

Het probleem wat dan dus onstaat met hubs is dat HUB1 alles doorstuurt in de richting van HUB2. Die stuurt alles richting HUB3, maar ook weer naar HUB1. HUB1 stuurt dat weer naar HUB2, enzovoort. En dat dus een keer of 5.

Of zit ik nu verkeerd te denken?

[Klippy]

Een HUB stuurt toch denk ik geen pakketjes terug naar de poort waarop ze binnen komen...
Als iets op poort 1 binnen komt wordt dat verstuurd naar alle andere poorten, maar niet naar 1.
Zo slim is een HUB toch wel... denk ik

[LauPro]

Waren in 2003 dergelijke switches zo duur? Ik moet zeggen dat ik rond 2000 een 8 poorts switch 100 MBit voor 175 gulden heb gekocht nog. Maar ik denk dat je een aanzienlijke snelheidswinst krijgt. 70 Mbit moet zeker haalbaar zijn effectief. Wellicht als je wat gaat knutselen aan de Window Size dat je er nog meer uit trekt.

Ik weet niet precies wat je budget is maar anders zou je misschien zelfs GBit kunnen overwegen. Aangezien goedkope modellen al voor een paar tientjes in de pw staan.

[FatalError]

Dat uiteraard, maar bij een hub heb je n half-duplex verbinding, en dus last van collisions. Daarom is er bij hubs ook een maximum aantal hubs dat je mag gebruiken. Bij switches heb je een full-duplex verbinding en dus geen last van collisions.

Kan je niet bij een van de pc's de statistieken bekijken van de verbinding.. over hoeveel collisions, fcs-fouten en andere problemen? Dan zal wel duidelijk worden wat er mis gaat.

[ Voor 28% gewijzigd door FatalError op 24-09-2005 16:53 ]

[LauPro]

Bij meerdere switches achter elkaar ga je wel degelijk last krijgen collisions hor.

[Vipertje]

maareh een hub is toch geen repeater of heb ik dat nu verkeerd. ik heb lang geleden eens een stel repeaters gehaalt voor iemand maar die dingen kon je niet gebruiken als hub of switch.

[Leon T]

Een hub is een multiport repeater
Ik heb alleen nog nooit van een switching hub gehoord?

Wat wel relevant is voor is is de 5-4-3 regel voor je netwerk.

Ethernet and IEEE 802.3 implement a rule, known as the 5-4-3 rule, for the number of repeaters and segments on shared access Ethernet backbones in a tree topology. The 5-4-3 rule divides the network into two types of physical segments: populated (user) segments, and unpopulated (link) segments. User segments have users' systems connected to them. Link segments are used to connect the network's repeaters together. The rule mandates that between any two nodes on the network, there can only be a maximum of five segments, connected through four repeaters, or concentrators, and only three of the five segments may contain user connections.

The Ethernet protocol requires that a signal sent out over the LAN reach every part of the network within a specified length of time. The 5-4-3 rule ensures this. Each repeater that a signal goes through adds a small amount of time to the process, so the rule is designed to minimize transmission times of the signals.

Blijkbaar stik je van de collisions. Zoals reeds geopperd werd zal een switch in het midden je probleem dus waarschijnlijk oplossen.

[Anoniem: 155286]

kun je niet beter dit doen:

2 keer een kabel van 175 mtr en in het midden een 1Gbit switch?(uiteraard werkt dit alleen als alle comps een 1Gbit Lankaart heeft (spreekt voor zich).
als dat niet helpt weet ik het ook niet maar 5 hubs klinkt mij niet gezond in de oren

[LauPro]

Een repeater is gewoon een hub met 2 poorten. Voor de meest optimale situatie kan je beter alle hubs vervangen door switches.

[FatalError]

LauPro schreef op zaterdag 24 september 2005 @ 16:54:
Bij meerdere switches achter elkaar ga je wel degelijk last krijgen collisions hor.

Als je bij switches last van collisions hebt heb je kapotte hardware

[joopv]

Yapser schreef op zaterdag 24 september 2005 @ 14:17:
Dan zou ik de hubs maar vervangen voor switches. Hubs flikkeren idd. de data over alle poortjes heen en 5 hubs is gewoonweg teveel..

Het probleem heeft niets over het "flikkeren van de data over alle poorten" te maken. Het probleem van TS is dat hubs het netwerk niet segmenteren en het collision domain alleen vergroten en niet afbakenen. Een collision domain is het stuk netwerk wat alleen verbonden is met kabels en hubs. Een switch is geen hub en kapt een collision domain af.
Het collision domain mag maximaal 512 bits groot zijn, bij 100Mbit is dat 5 us. Als je de delay in je kabels en de hubs bij elkaar optelt betekent dat dat je netwerk te groot is, fysiek gezien.

http://www.networkuptime.com/faqs/ethernet/index.shtml

5.4] What is a late collision, and why is it bad?

A collision is considered late if the jam occurs after 512
bit-times, or 64 bytes. Collisions that occur after the first 64
bytes of a frame may be indicative of a network design problem (the
network is so large the jam cannot traverse the entire length in 32
bit-times), or a hardware or Ethernet firmware issue.

When collisions do not propagate the network quickly enough, a
collision could occur between two stations without the stations
aware that the packets collided. In this situation, the frames are
simply lost, and the upper-layer protocols must begin a
retransmission process to retransmit the information. These
retransmissions can cause large delays, especially at the
application layer.

Oplossing: switches gebruiken ipv hubs. Een veel nettere oplossing: fiber trekken.

[Anoniem: 109978]

Anoniem: 155286 schreef op zaterdag 24 september 2005 @ 17:34:
kun je niet beter dit doen:

2 keer een kabel van 175 mtr en in het midden een 1Gbit switch?(uiteraard werkt dit alleen als alle comps een 1Gbit Lankaart heeft (spreekt voor zich).
als dat niet helpt weet ik het ook niet maar 5 hubs klinkt mij niet gezond in de oren

Utp mag oficieel maar 100mtr lang zijn , langer mag wel en gaat ook wel werken, maar aangezien er nu al problemen zijn, lijkt het me niet nodig nog meer oorzaken te maken.

simpele switch is ~even duur als een hub scheelt tegenwoordig echt niet veel tenzij je per se een professionele switch wilt gaan gebruiken. Ga iig switches gebruiken in plaats van hubs..

[ Voor 17% gewijzigd door Anoniem: 109978 op 24-09-2005 17:57 ]

[Anoniem: 155286]

Anoniem: 109978 schreef op zaterdag 24 september 2005 @ 17:54:
[...]


Utp mag oficieel maar 100mtr lang zijn , langer mag wel en gaat ook wel werken, maar aangezien er nu al problemen zijn, lijkt het me niet nodig nog meer oorzaken te maken.

hmm ja is ook zo sorry ben niet helder vandaag...

[Anoniem: 155286]

joopv schreef op zaterdag 24 september 2005 @ 17:53:
[...]

Het probleem heeft niets over het "flikkeren van de data over alle poorten" te maken. Het probleem van TS is dat hubs het netwerk niet segmenteren en het collision domain alleen vergroten en niet afbakenen. Een collision domain is het stuk netwerk wat alleen verbonden is met kabels en hubs. Een switch is geen hub en kapt een collision domain af.
Het collision domain mag maximaal 512 bits groot zijn, bij 100Mbit is dat 5 us. Als je de delay in je kabels en de hubs bij elkaar optelt betekent dat dat je netwerk te groot is, fysiek gezien.

http://www.networkuptime.com/faqs/ethernet/index.shtml


[...]


Oplossing: switches gebruiken ipv hubs. Een veel nettere oplossing: fiber trekken.

toon volledige bericht

ehm hij zei net: beetje zonde van de tijd die hij erin heeft gestoken... en beetje duur (dat zijn mijn woorden)

[Anoniem: 155286]

FatalError schreef op zaterdag 24 september 2005 @ 17:44:
[...]

Als je bij switches last van collisions hebt heb je kapotte hardware

joh

[joopv]

FatalError schreef op zaterdag 24 september 2005 @ 17:44:
[...] Als je bij switches last van collisions hebt heb je kapotte hardware

Onzin.

Collisions zijn een normaal verschijnsel bij half duplex ethernet. Het is geen teken dat er wat mis is, collisions horen gewoon bij de werking van ethernet.

Alleen bij full-duplex ethernet hoor je geen collisions te zien. Een ethernet switch kan zich op zowel half- als full duplex ethernet instellen. Als je half-duplex ethernet hebt, kan (zal) ook een switch collisions genereren en ontvangen.

[FatalError]

In plaats van 'switches' had ik natuurlijk 'full-duplex' moeten zeggen

[Anoniem: 109978]

FatalError schreef op zaterdag 24 september 2005 @ 18:34:
In plaats van 'switches' had ik natuurlijk 'full-duplex' moeten zeggen

kom op zeg, dat verschil is te groot om zo ff af te doen, denk dan ook niet dat iemand je gelooft....

[FatalError]

ik had het over een situatie waarbij alleen maar switches gebruikt worden, dan is normaalgesproken alles full-duplex. Maar idd, sorry voor mijn onduidelijkheid.

[Leon T]

Anoniem: 109978 schreef op zaterdag 24 september 2005 @ 19:19:
[...]


kom op zeg, dat verschil is te groot om zo ff af te doen, denk dan ook niet dat iemand je gelooft....

Ach, wat maakt het uit zolang iedereen nu begrijpt wat de term had moeten zijn
Maar aan de andere kant, zoveel switched netwerken met halfduplex zie je tegenwoordig niet meer. Dan moet het al handmatig worden ingesteld.

[Anoniem: 31879]

joopv schreef op zaterdag 24 september 2005 @ 18:15:
[...]

Onzin.

Collisions zijn een normaal verschijnsel bij half duplex ethernet. Het is geen teken dat er wat mis is, collisions horen gewoon bij de werking van ethernet.

Alleen bij full-duplex ethernet hoor je geen collisions te zien. Een ethernet switch kan zich op zowel half- als full duplex ethernet instellen. Als je half-duplex ethernet hebt, kan (zal) ook een switch collisions genereren en ontvangen.

Zolang het percentage collisions onder de 1% blijft ja. en Bij full duplex zien switches doweg gewoon geen collitions omdat het detectie maganisme gewoon domweg uitgeschakeld wordt.

collisions woden dan fragments , en fcs errors.

[DinX]

Anoniem: 109978 schreef op zaterdag 24 september 2005 @ 17:54:
[...]


Utp mag oficieel maar 100mtr lang zijn , langer mag wel en gaat ook wel werken, maar aangezien er nu al problemen zijn, lijkt het me niet nodig nog meer oorzaken te maken.

100 meter is zelfs al ruim bemeten. Bij ons op het werk gaan we nooit over de 75m. en als er gepatcht wordt zelfs niet over de 50 meter.

Ik zou persoonlijk ook al de hubs vervangen door switchen. Een hub gaat alleen maar het signaal versterken, inclusief de eventuele ruis die er al op zit enzo. En switch stuurt het pakketje gewoon opnieuw.

Voor 650-700$ heb je ook 500 meter fiber kabel. Het ligt er maar net aan hoeveel je er voor over hebt.

http://www.shopping.com/x...ber_optic_Cable_126545_06

Het is een kleine investering, maar van die afstand heb je dan al geen last meer. Ik vind dit persoonlijk een nettere oplossing dan met 5 switches te zitten werken. Daar betaal je trouwens ook weer voor, om uiteindelijk met een mindere kwaliteit van verbinding te zitten.

[ Voor 60% gewijzigd door DinX op 25-09-2005 11:32 ]

[rapture]

De eerder genoemde 5-4-3 regel bestaat voor iets:
max 5 segmenten
max 4 repeaters/hubs(multiportrepeater)
max 3 segmenten waar je hosts (computers) aansluit.

<segmentA>---<hub>---<utpkabel>---<hub>---<segmentB>---<hub>---<utpkabel>---<hub>---<segmentC>

(kan je een netwerkschema posten???)

[vereenvoudigde uitleg]Hubs blaaten elkaar na, als ze x aantal Volt binnenkrijgen, dan gaan ze ongeveer zoveel Volt terug buiten sturen. 4 hubs die hetzelfde signaal nablaten hebben het signalen net niet genoeg nageblaat om bruikbaar (net niet genoeg ruis...) te zijn. De 5de hub mag volgens de regels niet.[/vereenvoudigde uitleg]

Oplossing: in het midden een "bridge" of switch neerzetten. Dat breekt het hele collision domain in 2 stukken, dan zitten er per "netwerkgedeelte" maar 2 hubs elkaar na te blaten. Een switch pakt het signaal binnen, bekijkt wat het is op L2 niveau en maakt een nieuwe Ethernetframe => stuurt een verse signaal naar buiten.

[ Voor 42% gewijzigd door rapture op 25-09-2005 11:42 ]

[joopv]

Anoniem: 31879 schreef op zondag 25 september 2005 @ 11:16:
[...] Zolang het percentage collisions onder de 1% blijft ja.

Nope. Zelfs bij 100% collisions is de totale throughput van een ethernet segment nog geen 10% afgenomen. Denk er aan dat een collision altijd zeer kort duurt.
http://www.postel.org/pip.../2001-October/001522.html

A CSMA/CD collision rate of 100% (one collision for every successful
packet) for a typical TCP/IP/Ethernet stream (67% 1460 byte data segments
and 33% ACKs) spends only about 6.5% of the available bandwidth on
"collisions" and "retransmissions."

Ik kan dat trouwens met persoonlijke ervaringen staven.

en Bij full duplex zien switches doweg gewoon geen collitions omdat het detectie maganisme gewoon domweg uitgeschakeld wordt. collisions woden dan fragments , en fcs errors.

Inderdaad.

[Anoniem: 75994]

Als ik het goed begrijp krijg ik de volgende situatieverandering:

Oude situatie:

<huis / internet / backupserver, achter switch> -- <kabel> -- <hub 1> -- <kabel> -- <hub 2> -- <kabel> -- <hub 3> -- <kabel> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

Nieuwe situatie:

<huis / internet / backupserver, achter switch> -- <kabel> -- <hub 1> -- <kabel> -- <switch> -- <kabel> -- <hub 2> -- <kabel> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

[ Voor 17% gewijzigd door Anoniem: 75994 op 26-09-2005 14:49 ]

[BHQ]

Anoniem: 75994 schreef op maandag 26 september 2005 @ 14:49:
Als ik het goed begrijp krijg ik de volgende situatieverandering:

Oude situatie:

<huis / internet / backupserver, achter switch> -- <kabel> -- <hub 1> -- <kabel> -- <hub 2> -- <kabel> -- <hub 3> -- <kabel> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

Nieuwe situatie:

<huis / internet / backupserver, achter switch> -- <kabel> -- <hub 1> -- <kabel> -- <switch> -- <kabel> -- <hub 2> -- <kabel> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

Nee.

<huis / internet / backupserver, achter switch> -- <kabel> -- <switch> -- <kabel> -- <switch> -- <kabel> -- <switch> -- <kabel> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

[WiNlUx]

Of:

<huis / internet / backupserver, achter switch> -- <FIBER> -- <bedrijf / internet / netwerkomgeving met clients, achter switch>

[Anoniem: 75994]

Dan probeer ik het eerst met een aantal switches.

[Anoniem: 31879]

joopv schreef op zondag 25 september 2005 @ 12:12:
[...]
Nope. Zelfs bij 100% collisions is de totale throughput van een ethernet segment nog geen 10% afgenomen. Denk er aan dat een collision altijd zeer kort duurt.
http://www.postel.org/pip.../2001-October/001522.html
[...]

Ik kan dat trouwens met persoonlijke ervaringen staven.

[...]
Inderdaad.

Niet om het een of ander maar als alle verstuurde frames in een collision eindigen hou je geen goede frames meer over en komt er dus 0% van de frames ongeschonden door het netwerk.

De quote met "1 succesfull packet for every collision" levert in mijn berekening een collsion rate van slechts 50% op.

[ Voor 11% gewijzigd door Anoniem: 31879 op 27-09-2005 09:19 ]

[joopv]

taalkundige miereneukerij.... Uit het stukje quote wat je weggeknipt hebt blijkt duidelijk wat er bedoelt wordt. Ik begrijp eigenlijk niet waarom je zo'n reactie geeft, dit grenst aan trollen.
Bovendien kan ik nog aanvoeren dat een collision geen frame is, want geen CRC. En dus geldt de berekening wel.

Aan de TS: er bestaat ook nog zoiets als Long Reach Ethernet (LRE). Google er maar eens op.

Verder zou je 2 SDSL routers kop-aan-kont kunnen zetten, dan kun je 2,3Mb halen over enkele kilometers simpele telefoondraad.

En what about een WiFi link met 2 richtantenne's?

[ Voor 3% gewijzigd door joopv op 27-09-2005 21:02 ]

[Valkyre]

misschien ben ik heel gek hoor?
maar het heeft toch gewerkt? of lees ik dan de TS verkeerd.
als het gewerkt heeft met hubs, dan zou je zeggen dat er gewoon 1 hub brak is.

maar zoals gezegd, een switch in het midden is wel het mooiste

[Anoniem: 31879]

joopv schreef op dinsdag 27 september 2005 @ 20:57:
taalkundige miereneukerij.... Uit het stukje quote wat je weggeknipt hebt blijkt duidelijk wat er bedoelt wordt. Ik begrijp eigenlijk niet waarom je zo'n reactie geeft, dit grenst aan trollen.
Bovendien kan ik nog aanvoeren dat een collision geen frame is, want geen CRC. En dus geldt de berekening wel.

Aan de TS: er bestaat ook nog zoiets als Long Reach Ethernet (LRE). Google er maar eens op.

Verder zou je 2 SDSL routers kop-aan-kont kunnen zetten, dan kun je 2,3Mb halen over enkele kilometers simpele telefoondraad.

En what about een WiFi link met 2 richtantenne's?

met alle respect, noem het wat je wilt, maar er is geen reken machine die tot dezelfde conclusie komt

100% is 100% en geen 190%

1 collision + 1 frame = 50% collisions en geen 100%

Het regeltje wat ik noemde over de 1% is zelfs een cisco ccna vraag en die hebben er echt wel wat verstand van dacht ik zo.

Collisions zijn normaal bij een half duplex net maar behoren wel in bepaalde verhoudingen te blijven.

[ Voor 23% gewijzigd door Anoniem: 31879 op 28-09-2005 00:30 ]

[joopv]

Anoniem: 31879 schreef op woensdag 28 september 2005 @ 00:16:
[...] met alle respect, noem het wat je wilt, maar er is geen reken machine die tot dezelfde conclusie komt
100% is 100% en geen 190%
1 collision + 1 frame = 50% collisions en geen 100%

Oke, we zakken even af naar basisschool nivo. Met excuses aan de TS voor vervuiling van zijn topic.

Als ik 100 collisions zie op de lijn, en 100 goede frames, dan is het aantal collisions 100% van het aantal goede frames. Jouw denkfout is dat je ze optelt: 200 "dingetjes" op de lijn, daarvan zijn er 100 frames en 100 collisions. Dat is inderdaad 50%. Maar 50% waarvan? Je kunt zaken die niet optelbaar zijn niet optellen. Als ik 100 Euro in m'n portemonnee heb, en ik doe er 100 Roebel bij, heb ik dan 2 keer zoveel koopkracht?
Anyway - nogmaals dit is mierenneukerij want er staat duidelijk wat er bedoeld wordt.

Het regeltje wat ik noemde over de 1% is zelfs een cisco ccna vraag en die hebben er echt wel wat verstand van dacht ik zo.

Collisions zijn normaal bij een half duplex net maar behoren wel in bepaalde verhoudingen te blijven.

Heb jij wel eens gesnifferd aan een shared ethernet segment met pakembeet 100 werkstations en nog wat servers en printers? Dat zie je tegenwoordig niet zoveel meer, maar ik kan je garanderen dat je dan heel wat meer dan 1% collisions ziet.

De reden dat we massaal op switched ethernet zijn overgestapt is omdat we dan die 10 (of 100) mb niet meer hoeven te delen met de anderen, maar voor jezelf hebt. En niet omdat de throughput instort vanwege collisions.

[Anoniem: 31879]

joopv schreef op woensdag 28 september 2005 @ 08:30:
[...]
Oke, we zakken even af naar basisschool nivo. Met excuses aan de TS voor vervuiling van zijn topic.

Als ik 100 collisions zie op de lijn, en 100 goede frames, dan is het aantal collisions 100% van het aantal goede frames. Jouw denkfout is dat je ze optelt: 200 "dingetjes" op de lijn, daarvan zijn er 100 frames en 100 collisions. Dat is inderdaad 50%. Maar 50% waarvan? Je kunt zaken die niet optelbaar zijn niet optellen. Als ik 100 Euro in m'n portemonnee heb, en ik doe er 100 Roebel bij, heb ik dan 2 keer zoveel koopkracht?
Anyway - nogmaals dit is mierenneukerij want er staat duidelijk wat er bedoeld wordt.

[...]

Heb jij wel eens gesnifferd aan een shared ethernet segment met pakembeet 100 werkstations en nog wat servers en printers? Dat zie je tegenwoordig niet zoveel meer, maar ik kan je garanderen dat je dan heel wat meer dan 1% collisions ziet.

De reden dat we massaal op switched ethernet zijn overgestapt is omdat we dan die 10 (of 100) mb niet meer hoeven te delen met de anderen, maar voor jezelf hebt. En niet omdat de throughput instort vanwege collisions.

toon volledige bericht

K denk dat we het er lang over kunen hebben, maar ben het desalniet te min niet met je eens, en ja ik sniffer regelmatig daar wij hier een redelijk netwerkje hebben.Die netwerkjes waar jij er niet zoveel van ziet hebben wij er hier nog 10 tallen van. En dan zie je wel degelijk performance issues optreden vanwege collision timings, het collapse effect is b.v. een van die verschijnsels.

Je spreekt vervolgens over procenten collisions die je niet mag vergelijken met frames. Dan heb je dus altijd van beide 100% nooit meer en nooit minder.

Anyway ik ben het niet met je eens maar dat ga ik hier verder niet uit de doeken doen daar het niet toevoegt aan de vraag van de TS.

Maar vergeet niet wie op wie reageerde voor je iemand een mieren neuker noemt.

[Anoniem: 109978]

Gohan-san schreef op dinsdag 27 september 2005 @ 21:54:
misschien ben ik heel gek hoor?
maar het heeft toch gewerkt? of lees ik dan de TS verkeerd.
als het gewerkt heeft met hubs, dan zou je zeggen dat er gewoon 1 hub brak is.

maar zoals gezegd, een switch in het midden is wel het mooiste

Je leest de TS verkeerd, Het werkt nog steeds alleen is het een heel stuk langzamer dan de bedoeling is.. En idd zoals ik eerder al aangaf zijn switches sowieso beter dan hubs(niet alleen in deze configuratie)

[shure-fan]

ik vraag me inmiddels af of de TS al een oplossing heeft gevonden.

[Anoniem: 75994]

Ik wacht op de switches die ik besteld heb. Als ik er uiteindelijk met één in het midden af kom, houd ik die andere twee voor mezelf, altijd handig.

[Anoniem: 75994]

Oke, ik heb ze inmiddels in werking. Ik haal in plaats van 40 kb/sec (0,3 mbit) nu 850 kb/sec (6,8 mbit). Nog steeds niet optimaal, maar wel snel genoeg om iedere nacht 7 gb over te pompen.

Maakt het nog uit hoe de uplink zit? Ik heb nu de volgende situatie:

switch backupserver gewone poort <-utp-> switch 1 uplink - switch 1 gewone poort <-utp-> switch 2 uplink - switch 2 gewone poort <-utp-> switch 3 uplink - switch 3 gewone poort <-utp-> switch cliënts gewone poort.

[ Voor 6% gewijzigd door Anoniem: 75994 op 30-09-2005 15:32 ]

[Krypt]

Uplink is meestal al crossed, verder niets (zodat je dus straight patch kabels kunt gebruiken tussen switch&switch).. Maar tegenwoordig is toch alles autosensing, en ook het cross/straight gedeelte.

[ Voor 23% gewijzigd door Krypt op 30-09-2005 15:37 ]

[Jimbolino]

het is onzin om te investeren in 100mbit (of 1000mbit) koper switches...
je kan beter aan de toekomst denken en 100 euro uittrekken voor een stukje glasvezel.

Een backupje draaien via gbit gaat echt stukken beter dan via 100mbit. Backup media worden steeds groter, maar ook steeds sneller.

Ik denk dat je (als je het nu niet doet) over 2 tot 5 jaar zoiezo over moet stappen op gbit. De prijs van glasvezel zakt niet echt, dus over een paar jaar betaal je er waarschijnlijk net zo veel voor als nu.

[DinX]

Jimbolino schreef op vrijdag 30 september 2005 @ 15:56:
het is onzin om te investeren in 100mbit (of 1000mbit) koper switches...
je kan beter aan de toekomst denken en 100 euro uittrekken voor een stukje glasvezel.

Een backupje draaien via gbit gaat echt stukken beter dan via 100mbit. Backup media worden steeds groter, maar ook steeds sneller.

Ik denk dat je (als je het nu niet doet) over 2 tot 5 jaar zoiezo over moet stappen op gbit. De prijs van glasvezel zakt niet echt, dus over een paar jaar betaal je er waarschijnlijk net zo veel voor als nu.

100€ is wel laag geschat hoor. Zie de prjizen die ik boven aanhaalde met een lnik naar een webshop. Je gaat tegen de 600€ aanzitten voor 500 meter fiber (gaat van 350 naar 500, opmaat wordt veel en veel duurder). Maar zelfs dat is nog een mooie investering.
Voor 5 switchen ben je oko 250€ kwijt voor goedkopere merken. Je moet daar dan ook nog electriciteiskabels voor leggen enzo. Die dingen kunnen dan ook nog eens kapot gaan, en je zit dan nog altijd maar met 100Mbit. Zeker voor in de toekomst is dat vrij laag imho.

[rapture]

Anoniem: 75994 schreef op vrijdag 30 september 2005 @ 15:31:
Oke, ik heb ze inmiddels in werking. Ik haal in plaats van 40 kb/sec (0,3 mbit) nu 850 kb/sec (6,8 mbit). Nog steeds niet optimaal, maar wel snel genoeg om iedere nacht 7 gb over te pompen.

Maakt het nog uit hoe de uplink zit? Ik heb nu de volgende situatie:

switch backupserver gewone poort <-utp-> switch 1 uplink - switch 1 gewone poort <-utp-> switch 2 uplink - switch 2 gewone poort <-utp-> switch 3 uplink - switch 3 gewone poort <-utp-> switch cliënts gewone poort.

Dan wordt het tijd voor "lijntesten", elke stukje kabel gaan testen. bv servertje hangen aan switch 1 en laptop aan switch 2, ff benchen met iperf en zo verder doen totdat elk onderdeeltje gebencht is. Daarna grote stukken in 1 keer doen, bv van backupserver switch richting switch 3.

[redguy]

Waar je trouwens ook eens naar moet kijken is naar je tcp window size.. bij wat hogere delays is het sneller om je machines zo in te stellen dat er meer tcp packets op de lijn mogen staan, anders gaat je machine veel te vaak lang staan wachten op tcp ack's van de open staande pakketten waardoor je performance in elkaar zakt..

scheelt echt veel in een aantal gevallen.. Zeker als je aan de gang gaat met tooltjes als ipperf dan zul je hier enorme verschillen zien. Probeer het maar eens met een grotere tcp windows size en meerdere streams tegelijkertijd ipv 1 streampje. Laat eens meerdere FTP sessie tegelijkertijd lopen en kijk wat je opgeteld haalt.

Ik zie bij klanten die met ipperf meten over een 100mb lijn soms amper 5-10mb door foute instellingen. stel je bovenstaande goed in dan blazen ze de 100mbit makkelijk vol..

Als je dat in gedachte houd is het verstandig om te kijken naar backupsoftware met een push client die meerder streams verstuurd i.p.v. op "file sharing" nivo 1 voor 1 de files binnen te halen. Met een push client druk je de verbinding netjes vol met grote packets in meerdere streams zodat je de maximale snelheid over de lijn kunt behalen.

Het eeuwige "upgraden naar gbit ethernet is veeel beter" verhaal is dan compleet overdreven. Op deze manier haal je pas de performance van je 100Mbit link, zo efficient mogelijk i.p.v. brute force meer bandbreedte te installeren en hem grotendeels vol te proppen met troep.

Overigens heeft het overschakelen van hubs naar swiches juist op dergelijk lange link zeer veel nut. Door switches te gebruiken kun je overschakelen op full duplex links hetgeen in situaties met dergelijk lange delays erg veel gaat schelen. De gedachte dat een half duplex link minder gevoelig is voor storingen is in dit soort gevallen een fabeltje.

Heb je al eens geprobeerd wat je netwerk doet met 1 lange kabel tussen 2 switches ? ik heb al eerder dergelijke afstanden overbrugt op een point-to-point link tussen 2 switches.. ver buiten specs maar op een pt-pt verbinding soms best haalbaar.

kijk op zulke afstanden wel ff uit met ground loops enz (afscherming telkens maar aan 1 kant aansluiten als je die hebt)

[ Voor 54% gewijzigd door redguy op 30-09-2005 18:32 ]

[Anoniem: 75994]

Ik laat het voorlopig zo, want ik heb in principe niet meer nodig. Binnenkort krijg ik een 6 mbit download, dan hebben ze op de zaak nog voldoende over (volle bak als het goed is). Voor die 7 á 8 gb per nacht is het ook voldoende, want dan is het met een kleine 3 uur klaar. Als het 's nachts om 2 uur begint, is het 5 uur klaar. Geen enkel probleem.

[joopv]

Anoniem: 75994 schreef op vrijdag 30 september 2005 @ 15:31:
Oke, ik heb ze inmiddels in werking. Ik haal in plaats van 40 kb/sec (0,3 mbit) nu 850 kb/sec (6,8 mbit). Nog steeds niet optimaal, maar wel snel genoeg om iedere nacht 7 gb over te pompen.

Mooi, je bent van je "late collisions" af. 850kB/sec is zo'n beetje de limiet bij 10Mb ethernet. Ik vermoed dat een van je schakels op 10Mbit staat ingestelt. Dat zou je eventueel nog kunnen onderzoeken.
Je zou, zoals redguy suggereerde de tcp instellingen kunnen optimaliseren om er nog een beetje uit te persen. Op http://www.speedguide.net/ kun je tcpoptimizer downloaden daarvoor.

Maakt het nog uit hoe de uplink zit? Ik heb nu de volgende situatie:

Als het niet goed zou zitten zou je helemaal geen verbinding hebben.

[LinuZZ]

had de 2e pagina niet gezien en dus stond hier blaat

[ Voor 93% gewijzigd door LinuZZ op 01-10-2005 08:42 ]

[Anoniem: 75994]

Uit de metingen van vandaag blijkt dat de backup-software met gemiddeld 1,1 MByte per seconde images overpompt naar de server als alle cliënts dat tegelijk doen. Ik ben daarover tevreden, want dat betekent dat hij met alles na ongeveer 30-45 minuten klaar is.

[Anoniem: 86415]

joopv schreef op zaterdag 01 oktober 2005 @ 08:25:
[...]
Mooi, je bent van je "late collisions" af. 850kB/sec is zo'n beetje de limiet bij 10Mb ethernet. Ik vermoed dat een van je schakels op 10Mbit staat ingestelt. Dat zou je eventueel nog kunnen onderzoeken.
Je zou, zoals redguy suggereerde de tcp instellingen kunnen optimaliseren om er nog een beetje uit te persen. Op http://www.speedguide.net/ kun je tcpoptimizer downloaden daarvoor.

[...]

Als het niet goed zou zitten zou je helemaal geen verbinding hebben.

Ik moet zeggen, ik heb hier ook gedeelte van het netwerk 10mbit en ik haal keurig 1,2 mbyte per seconde. Zonder optimizer of wat dan ook. Switch is een 3com superstack 1100.

Met 100mbit kan je theoretisch 12 megabyte halen afhankelijk van je OS en switches, je moet dan toch op zn minst 10 mbyte per seconden halen, dus die 1mbyte vind ik dan toch redelijk traag. Of ligt het aan mij? Tenzij Eraser tevreden is met dit resultaat uiteraard

[ Voor 58% gewijzigd door Anoniem: 86415 op 01-10-2005 13:17 ]

[_Arthur]

Eventueel aan een wireless-netwerk gedacht? Want met 2 richtantennes is een 10+mbit (en meer vast ook wel) link over 350mtr toch zeker wel haalbaar.

[Jimbolino]

_Arthur schreef op zaterdag 01 oktober 2005 @ 19:28:
Eventueel aan een wireless-netwerk gedacht? Want met 2 richtantennes is een 10+mbit (en meer vast ook wel) link over 350mtr toch zeker wel haalbaar.

duur, niet betrouwbaar, onnodig

[_Arthur]

Jimbolino schreef op zaterdag 01 oktober 2005 @ 21:14:
[...]

duur, niet betrouwbaar, onnodig

3x niet met je eens.

Wat is er duur aan 2x een WRT54GS met bijbehorende richtantennes? Zit je niet eens aan dezelfde prijs als 5x een cheapo-switch. Betrouwbaarheid lijkt me weinig problematisch over een afstand van 350meter.

En onnodig? Huh, hoe weet jij wat er nodig/onnodig is? Mij lijkt een wireless oplossing in deze de meest praktische en snelste methode. Want hoe betrouwbaar zijn al die switches die ergens onder de grond staan of in stallingen opgehangen zijn. Niet echt plaatsen die wel betrouwbaar zijn.

[Leon T]

Er is ook nog zoiets als veiligheid. Persoonlijk zou ik nooit gevoelige bedrijfsdata (en dat zal waarschijnlijk wel in die backups staan he ) over een wireless verbinding willen sturen die jan-met-de-pet zonder problemen kan aftappen.

[shure-fan]

wat ik aan dit topic merk is dat 3 kwart ervan alleen maar bestaat uit offtopic gedoe, de TS geeft aan dat hij het zo goed vind en toch word er doorgezeken over dat ie een glasverbinding moet leggen of draadloos moet gaan, " want ja zo kan het nooit goed gaan op deze manier" terwijl deze manier (hoe het nu dus ligt) wel goed werkt voor de TS. En ik denk ook dat als je de echte reacties waar de ts wel wat aan heeft achter elkaar zet dat je dan met een halve pagina klaar bent en niet 3 pagina's.

dit was voor zover even mijn mening.

[rapture]

shure-fan schreef op zondag 02 oktober 2005 @ 15:59:
dit was voor zover even mijn mening.

Mijn mening is dat een verbinding de snelheden volgens het boekje moet halen, dus verder tweaken/optimaliseren totdat je van de 100mbps verbinding kan genieten.

Waarom bij die utp-kabels en switches blijven? Omdat alle infrastructuur er al is:
- wireless: accesspoints kopen, antennes op het dak zetten, coax aanleggen,... (veel werk en kosten)
- glasvezel: apparatuur aankopen, glasvezel trekken vereist ook het nodige materiaal en kennis,... (veel werk, kosten, gereedschap en kennis)

Waar je trouwens ook eens naar moet kijken is naar je tcp window size.. bij wat hogere delays is het sneller om je machines zo in te stellen dat er meer tcp packets op de lijn mogen staan, anders gaat je machine veel te vaak lang staan wachten op tcp ack's van de open staande pakketten waardoor je performance in elkaar zakt..

scheelt echt veel in een aantal gevallen.. Zeker als je aan de gang gaat met tooltjes als ipperf dan zul je hier enorme verschillen zien. Probeer het maar eens met een grotere tcp windows size en meerdere streams tegelijkertijd ipv 1 streampje. Laat eens meerdere FTP sessie tegelijkertijd lopen en kijk wat je opgeteld haalt.

Ik zie bij klanten die met ipperf meten over een 100mb lijn soms amper 5-10mb door foute instellingen. stel je bovenstaande goed in dan blazen ze de 100mbit makkelijk vol..

Dat is enorm belangrijk als je testen doet met iperf, window-size vergroten zorgt voor minder wachten op ack's, dus sneller. Bij te grote window-size zal de hele packetjes in je window niet meer veilig aankopen, dan zal de snelheid als een pudding in elkaar zakken. Statistisch gezien zal er een 1 / x aantal packetjes niet aankomen, als je de window groter dan die x maakt, dan zal altijd een fout in je window zitten => performance zakt in elkaar.

[ Voor 52% gewijzigd door rapture op 02-10-2005 16:16 ]

[Anoniem: 75994]

Hmm, nu heb ik een vreemd probleem. Alles wat vanuit de zaak naar thuis wordt gestuurd (of dat vanuit thuis of de zaak wordt gedaan geeft geen verschil), gaat met die 1,1 MB/sec (upload dus eigenlijk). Als ik echter wat moet downloaden (en daar hoort internet dus ook bij) vanuit de zaak, gaat het dramatisch langzaam. Ook hier geen verschil in locatie.

Het backupsysteem werkt ook vanuit het principe dat de cliënts op de zaak hun images overpompen naar huis en dat werkt dus wel prima.

Kan dat betekenen dat er ergens een brakke poort is of dat er toch ergens teveel weerstand in een adertje zit?

Edit: het lijkt erop dat het verkeer van de zaak naar huis normaal gaat en andersom erg traag. Ik meet 4 kb/sec.

[ Voor 23% gewijzigd door Anoniem: 75994 op 07-10-2005 16:17 ]

[FatalError]

zoals iemand al zei... meet stuk-voor-stuk na.. laptop aan de eerste switch, snelheid ok? --> volgende switch testen, etc...

[Anoniem: 75994]

Het verkeer dat van huis naar de zaak gaat, ziet er als volgt uit.



Er worden pieken gehaald van de normale snelheid in het geval van het verkeer van de zaak naar huis. Het fluctueert nogal, zoals te zien is.

De trajectmetingen zal ik morgen weer doen.

[joopv]

Anoniem: 75994 schreef op vrijdag 07 oktober 2005 @ 15:57:
Hmm, nu heb ik een vreemd probleem. Alles wat vanuit de zaak naar thuis wordt gestuurd (of dat vanuit thuis of de zaak wordt gedaan geeft geen verschil), gaat met die 1,1 MB/sec (upload dus eigenlijk). Als ik echter wat moet downloaden (en daar hoort internet dus ook bij) vanuit de zaak, gaat het dramatisch langzaam. Ook hier geen verschil in locatie.

Het backupsysteem werkt ook vanuit het principe dat de cliënts op de zaak hun images overpompen naar huis en dat werkt dus wel prima.

Een factor 10 te traag voor een 100Mbit verbinding noem ik niet "prima".

Kan dat betekenen dat er ergens een brakke poort is of dat er toch ergens teveel weerstand in een adertje zit?

Edit: het lijkt erop dat het verkeer van de zaak naar huis normaal gaat en andersom erg traag. Ik meet 4 kb/sec.

Misschien heb je een duplex mismatch, dat wil zeggen: aan de ene kant van (een van) de kabel(s) is een apparaat ingesteld op full duplex, en aan de andere kant van die kabel is het apparaat ingesteld op half-duplex. Dat levert dit soort problemen op. Begin eens met alles op automatisch in te stellen, levert dat niks op zet dan alles op half-duplex, te beginnen met de machine thuis.

Controleer ook je ethernet bekabeling en RJ45 connectoren nogmaals. Heb je de aderpaartjes goed aangesloten volgens de standaard?

[_Arthur]

shure-fan schreef op zondag 02 oktober 2005 @ 15:59:
wat ik aan dit topic merk is dat 3 kwart ervan alleen maar bestaat uit offtopic gedoe, de TS geeft aan dat hij het zo goed vind en toch word er doorgezeken over dat ie een glasverbinding moet leggen of draadloos moet gaan, " want ja zo kan het nooit goed gaan op deze manier" terwijl deze manier (hoe het nu dus ligt) wel goed werkt voor de TS. En ik denk ook dat als je de echte reacties waar de ts wel wat aan heeft achter elkaar zet dat je dan met een halve pagina klaar bent en niet 3 pagina's.

dit was voor zover even mijn mening.

Achja, kennelijk werkt het toch niet zoals de TS graag had gehad. Maar goed, we hebben jouw mening dat je nooit andere opties mag/zou moeten aandragen.

En als TS zijnde zou ik toch echt naar andere mogelijkheden kijken dan op het huidige plan verder te borduren.

[Romke]

Opzich kun je 2 wap54g accesspoints van linksys voorzien van mustdie firmware (te downloaden op www.linksysinfo.org ) en die dan met een line of sight tegen over elkaar zetten.

Als je het vermogen ver genoeg omhoog gooit, let's say 78 mW, kun je die afstand zonder richtantennes halen.

En als je met WPA, MAC filter en disabled SSID broadcast werkt, zitten je gegevens redelijk veilig.

Beetje random wpa key genereren, en zo ook het ssid, dan duurt het ff voor jan-met-de-pet-op je data heeft ontcijferd.

Uiteraard maakt een richtantenne het geheel wel een stukje veiliger, want als je er 2 neemt met zeer kleine openingshoek, dan moet die illustere jan-met-de-pet-op als tussen je antennes gaan staan als hij verkeer wil aftappen, en dat zal niet praktisch zijn, want dat valt op.