Netwerk Snelheid/performance berekenen

[The_Butler]

Ik heb het volgende vraagstuk;

30 Ethernet apparaten (clients) praten allemaal via een 10mbit radio netwerk met een server. De server wil constant een klein beetje data hebben en versturen naar iedere client (4 words aan data, plus daarbij de overhead).

Wat is in het slechtste geval de langste reactie tijd als de server aan een client een pakketje met data wil versuren?

Ik ben van plan om een formule te vinden op het internet waar ik het volgende op kan invullen:

-netwerk snelheid over het medium(10/Mbit)
-aantal clients
-hoeveelheid data per client (inclusief header)

Mijn vragen aan de mensen die wat meer van TCP/IP en netwerken afweten dan mij:

-Het radio netwerk zal werken als een 30 poorts hub, ik moet denk ik rekening houden met het aantal collisions dat ik kan verwachten. Weet iemand of hier een formule voor is?

-Is er uberhaupt een formule om een theoretische netwerk snelheid te bepalen?

-Ben ik belangrijke punten vergeten in mijn verhaal?

-Benader ik dit probleem in jullie opinie op de goede manier?

Achtergrond info
Iedere Client is een treintje op een mono rail, via een leaky feeder systeem (speciale radio antenne onder de rail) wordt er data naar een server gestuurd (deuren open/dicht, noodstop,olie druk etc.) en wordt er data ontvangen (je mag rijden,doe een noodstop, zet het brand alarm aan etc.) Zodra ik weet hoe snel de data overdracht is is de slechtste situatie moet ik adviseren hoe snel de wagentjes mogen rijden. Als een wagen namelijk een noodstop doet dan moet het wagentje daar achter zo snel mogelijk stoppen. De afstand tussen de wagentjes wordt gemeten in tijd. De tijd die het kost om het volgende wagentje te stoppen is [transmissie tijd wagentje1] + [denktijd server] + [verzend tijd naar wagentje2] +[remtijd wagentje2] + [veiligheids marge].

Als deze tijd 12 seconden is betekend het dat de wagentjes 40 km/uur kunnen rijden, is het 10 seconden dan heb je 2 sec extra remtijd en dan mag de topsnelheid 55 km/uur zijn (deze getallen zijn uit de lucht gegrepen). Ik moet mijn gevonden tijd/formule via bronnen kunnen bewijzen, aangezien de veiligheid van de pasagiers er van afhankelijk is.

[Bor]

Is de hoeveelheid data altijd even groot? Is de overhead altijd even groot? Voor collisions is niet echt een berekening te maken lijkt me, het aantal collisions is afhankelijk van de tijd waarop de hosts willen zenden. Dit is moeilijk te voorspellen (zonder de achtergrond uit de startpost te hebben gelezen). Bij de reactietijd moet je ook de "wireless" tijd pakken.

Hoe nauwkeurig moet dit zijn?

Bovendien is 10Mbit de theoretische snelheid. Die zal in de praktijk lager liggen.

[ Voor 26% gewijzigd door Bor op 13-12-2004 15:04 ]

[zwippie]

* zwippie is geen tcp/ip expert

Maar ik zat te denken dat een noodstop voor alle wagentjes misschien ook uitgevoerd kan worden door middel van een broadcast, zodat alle wagentjes echt precies tegelijk een stop-commando krijgen.

[Xiphalon]

Volgens mij is dit niet echt te vatten in een formule.
De structuur van ethernet (en al helemaal door de lucht) is zo dat als er wat verzonden moet worden, dat gewoon ook meteen gedaan wordt. Waarbij er dus ook botsingen kunnenoptreden, waardoor het zenden even later nog een keer geprobeerd wordt.
Dit is niet te voorspellen (je zou evt wel wat kunnen gokken) en dus niet in een formule te proppen.

Wat je wel zou kunnen doen is op de een of andere manier gaan werken met time-slots. Hierbij specificeer je per wagentje wanneer hij mag zenden (stel: 100 wagentjes, dus wagentje 1 mag de 1^e 100^ste seconden zenden, wagentje 2 de 2^de 100^ste seconde etc..) Vooraf een puls geven zodat alle wagentjes netjes synchen et voila, reactietijd is voorspelbaar, mits je kan garanderen dat het verzenden van data foutloos gaat.

[The_Butler]

De pakket groote is altijd het zelfde voor iedere Unit.
Ik heb naar de broadcast gekeken en dit kan een optie zijn voor de noodstop. Het hangt er van af hoe heftig de wagentjes stoppen (als het betekend dat er 30 wagentjes * 15 passagiers binnen een paar seconden stil staan dan kunnen er zich best veel persoonlijke ongelukken voor doen en dat is niet echt gewenst).

[Verwijderd]

Ik denk dat je leuk mag gaan simuleren.
Wat gebeurt er als er veel berichten achter elkaar gestuurd moeten gaan worden? Komen er dan collisions, gaan er berichten verloren, hoeveel tijd heeft een wagentje nodig om het bericht te ontvangen en te verwerken enz enz. Er zijn dus een hoop parameters die in jou situatie van belang zijn maar niet algemeen geldend zijn. Een algemene theoretische formule is dan ook niet bruikbaar. Wel zou je de theoretische tijden van alle onderdelen (tijd die het wagentje nodig heeft na het ontvangen van het bericht om te reageren, latencies, tijd die het kost om je bericht naar een willekeurige afstand te versturen) in je simulatiemodel kunnen stoppen. Dan kom je al snel tot iets wat veilig lijkt.

Het worst case scenario is trouwens wel makkelijk te berekenen. In dat geval bereikt het signaal het wagentje namelijk helemaal niet (stoorzenders, kapotte electronica, en ik denk dat je nog wel wat redenen kan bedenken) Dus de max snelheid is 0 km/u Maar ik denk niet dat je daar op zat te wachten.

[Predator]

Niet dat het hier iets technisch mee te maken heeft maar euh...
Is het niet beter je clients/treintjes niet expliciet een noodstop te laten maken via een signaal, maar juist bij gebrek aan signaal ?

Door bv. elke X seconden een 'OK' signaal te sturen. Y aantal seconden geen signaal meer van controle eenheid -> stop.

Cfr dodemanspedaal in een gewone trein.

Anders kan je je treintjes niet laten stoppen als er 1 of ander probleem is.
Antenne netwerk down / storing / controlle eenheid down ... enz ..

[The_Butler]

Natuurlijk komt er een Watchdog die de signalen in de gaten houd. Maar deze watchdog heeft een tolerantie van laten we zeggen 6 seconden. Ik hoop dat ik een Stop signaal toch echt binnen deze tijd kan versturen. Maar is de Watchdog tijd te kort dan stopt de bende drie keer per dag. Zo'n noodstop is ook echt een noodstop, remmen gaan er vol in en de motoren gaan zo hard mogelijk in ze'n achteruit.

Ik denk na wat ik vandaag allemaal hier en op Google heb gelezen het idee dat ik mijn netwerk beter kan opsplitsen in 8 delen; dan komt er naast de leaky feeder een dubble glasvezel ring. Het resultaat is dat er 8 segmenten zijn die op 10m/bit lopen en die via 100 mbit hub's met elkaar verbonden zijn. Naar mijn idee zullen switches en routers niet werken omdat een karretje als deze in naar een ander segment rijd zijn IP adres mee neemt, dus het netwerk loopt telkens achter de feiten aan.

[bigfoot1942]

en als de hoofd-hub het begeeft? dat is nl ook een worst-case scenario, en ik denk dat dan een noodstop wel gerechtvaardigd is. een centrale Watchdog die dan een signaal probeert te sturen helpt niet in dit scenario (of elke client moet een Watchdog aan boord hebben).

[The_Butler]

De watchdog bevind zich in iedere wagen, iedere wagen zal dus stoppen als de hoofd hub het begeeft. Mijn bedrijf specialiseerd zich in veiligheids systemen, de PLC in de wagen is ook SIL 3 fail safe, dus veiligheid is niet direct een probleem. Het probleem is dat onze/mijn netwerk kennis wat minder is en dat de performance (snelheid) van het systeem nu het grote probleem is.

[Verwijderd]

Ik denk na wat ik vandaag allemaal hier en op Google heb gelezen het idee dat ik mijn netwerk beter kan opsplitsen in 8 delen; dan komt er naast de leaky feeder een dubble glasvezel ring. Het resultaat is dat er 8 segmenten zijn die op 10m/bit lopen en die via 100 mbit hub's met elkaar verbonden zijn. Naar mijn idee zullen switches en routers niet werken omdat een karretje als deze in naar een ander segment rijd zijn IP adres mee neemt, dus het netwerk loopt telkens achter de feiten aan

Ik heb het gevoel dat het hele idee nog niet echt uitgedacht is. Het concept van karretjes die met dezelfde snelheid en hetzelfde tijdsinterval achter elkaar rijden geeft al aan dat je gewoon te weinig kennis van zaken hebt om de karretjes veilig te laten rondrijden. Ze staan namelijk ook stil bij de perrons om mensen(?) in of uit te laten stappen. (nofl) Verder dan een inschatting dat als het signaal werkt het binnen x milliseconden bij de karretjes is kom je hier niet mee. En dan begint eigenlijk het echte werk pas.Het model waarmee je het aantal wagentjes, de afstand, de route (als je een keus hebt) enz enz enz. bepaald is vele malen belangrijker. Dat je nu (hopla) je idee van draadloos door glasvezel hebt vervangen schept nu ook echt niet veel vertrouwen.

Mijn advies: Ga eens praten met bedrijven die ervaring hebben met dit soort problemen, bv de ECT, de bagageafhandeling van Schiphol of de NS.

[Illusion]

Ik zou zowiezo niet voor ethernet i.c.m. tcp/ip gaan.. Er zijn speciale mission-critical netwerksystemen die een vaste worst-case-scenario tijd hebben. Bij ethernet is dat gewoon niet mogelijk/te berekenen.
Ga eens op zoek naar de systemen die ze gebruiken in auto's (airbag, motorsturing, sensoren, remmen, alles is gekoppeld) of kern/electriciteits-centrales.

[swampy]

Ik heb zo'n alles een beetje gelezen en... heb een vraag...

Waarom een Hub... Hubs hebben 1 groot nadeel... ze sturen rond elk poortje..dus een eindpunt moet 31 signalen weggooien voor dat ENE signaal dat het nodig heeft?????

Een switch is veel handiger, dan gaat signaal x17 ook maar naar poortje 17... minder problemen...

[swampy]

Ik heb zo'n alles een beetje gelezen en... heb een vraag...

Waarom een Hub... Hubs hebben 1 groot nadeel... ze sturen rond elk poortje..dus een eindpunt moet 31 signalen weggooien voor dat ENE signaal dat het nodig heeft?????

Een switch is veel handiger, dan gaat signaal x17 ook maar naar poortje 17

Natuurlijk hangt de snelheid van een switch af van de gebruikte processor op de switch.. maar een beetje non-budget switch kan alles wel af.

Als je echt 100% zeker wil zijn..dat alles goed gaat... dan praten we niet meer over hubjes of switchjes...

[bigfoot1942]

swampy schreef op dinsdag 14 december 2004 @ 04:16:
Een switch is veel handiger, dan gaat signaal x17 ook maar naar poortje 17

TS legde uit dat dit niet handig is, treintje x kan aangemeld zijn op het traject wat op poort 1 hangt, vervolgens komt deze op het traject aan poort twee en geeft door aan de switch dat hij van poort verandert is. In de tussentijd is er mogelijk een signaal uit poort 1 gestuurd die nooit opgevangen is. en dan?

[Verwijderd]

ik zou afstappen van het idee op tcp/ip te gebruiken.

Dit protocol doet namelijk (zelf) niets om te verifiëren dat een packet ook daadwerkelijk op het eindstation is gearriveerd. Voor een dergelijke real-time functie is tcp/ip dan ook absoluut ongeschikt. Ik zou eens gaan zoeken in de richting van een CAN bus of dergelijke die wel real-time functies ondersteunen. (tevens is het vinden van formules hiervoor véél simpeler aangezien men dit soort vragen hiervoor immers verwacht).

Ik heb het idee dat je bezig met iets wat bij voorbaat al gedoemd is om te mislukken...TCP/IP wordt gebruikt voor het regelen van een logische opeenvolging (als kar1 op pos 3 en pos2 is vrij >> kar 2 van pos1 naar pos2) en niet voor het real-time controleren van een dergelijke regeling. Met als belangrijkste argument dat hier veiligheidsnormen voor staan.

bedenk namelijk ook dat ethernet het toelaat dat pakketten volledig onwillekeurig de server bereiken. Pakketten halen elkaar binnen je model dus in! (niet fysiek, maar voor het model wel).
tevens heeft een RF-netwerk een zogenaamde "dwell-time" die mag (protocol gewijs) oplopen tot 400ms.
*moet ik nog doorgaan?*

(of je moet hier inderdaad mensen bijhalen met verstand van logistiek en aansturing. Maar je zult extra maatregelen -lees: bouwen van een complete client-server applicatie- moeten nemen om de veiligsnormen te kunnen garanderen. Maar nogmaals, er zijn hier geen vaste toestanden, dus liever helemaal geen tcp/ip...

[Bor]

Dit protocol doet namelijk (zelf) niets om te verifiëren dat een packet ook daadwerkelijk op het eindstation is gearriveerd. Voor een dergelijke real-time functie is tcp/ip dan ook absoluut ongeschikt.

Volgens mij ben je in de war met UDP? TCP gebruikt acknowledge...

[swampy]

bigfoot1942 schreef op dinsdag 14 december 2004 @ 04:24:
[...]

TS legde uit dat dit niet handig is, treintje x kan aangemeld zijn op het traject wat op poort 1 hangt, vervolgens komt deze op het traject aan poort twee en geeft door aan de switch dat hij van poort verandert is. In de tussentijd is er mogelijk een signaal uit poort 1 gestuurd die nooit opgevangen is. en dan?

Login Procedures?

Normaal is een hub/switch via kabels geregeld enzal je fysiek de computer niet vaak en automatisch verplaatsen.

Misschien een soort Authenticatie signaal die elk karretje om de 6 seconde uitzend om zijn positie kwa netwerk door te geven, dan is het langste dat een karretje "uit beeld" is 6 seconden.

[The_Butler]

Het communicatie protocol dat wordt gebruikt is zogenaamd "Safe-Ethernet", dit protocol zorgt er voor dat alle informatie juist en veilig wordt verstuurd (de gebruiker kan wel de watchdog tijd en het type netwerk aangeven zodat het protocol er rekening mee houd.)

Zoals het er nu uit ziet wil ik in feite de functionaliteit van een veld bus netwerk (Modbus/Profibus) over het medium Ethernet. Nu bestaat er zoiets als Modbus over TCP/IP. Dit protocol werkt via een master/slave systeem, de master vraag aan 1 slave om zijn informatie, daarna wordt client 2 aangesproken enz. Helaas kan ik met dit systeem geen gebruik maken van zogenaamde broadcasts (een paar posts hierboven genoemd) en broadcasts zijn ideaal als je snel iedereen op een netwerk wilt aanspreken.

Al iemand een praktijk voorbeeld weet van een bedrijf die zoiets heeft opgelost met bijvoorbeeld een lopende band dan houd ik me aanbevolen.

[Verwijderd]

ok, dat kon ik natuurlijk niet weten .

Geen broadcasts is inderdaad wel een probleem binnen deze opstelling. Misschien kun je het omzeilen (gedeeltelijk) door de slaves steeds hun positie te laten doorgeven zonder dat hiervoor een aanvraag vanuit de master moet komen. Dan hoeft je master alleen actief orders te geven op het moment dat hij onveilige situaties doorkrijgt.

je kunt overigens wel een indicatie krijgen van de minima van dit netwerk door:

TCP rate < MSS/ (RTT * sqrt(loss))

en dan tcp rate (throughput, wat jij wil) te herschrijven naar aanleiding van je maximale belasting. Het is maar een indicatie natuurlijk...Maar aangezien je een ethernet netwerk (toch) wilt gebruiken, zou hij van toepassing moeten zijn. (maar wie kent deze niet? )

[Guru Evi]

Zou het niet beter zijn ipv Ethernet een soort van modified Token Ring te maken. Dit kan ook in ster topologie (draadloos) en is veel beter voor dit soort dingen.

Dan krijgt iedere wagen zijn tijd waarin hij zijn data moet versturen ook de server en dan moet er natuurlijk een broadcast pakket of lijn (vb. hf-signaal op de stroomlijn) zijn die de token kan stilleggen om een nieuwe broadcast token te lanceren of een noodstop kan genereren.

Ik denk eerder dat je beter zelf je topologie maakt en daarop je eigen protocollen bouwt (misschien op basis van een of ander bestaand protocol). Ik weet natuurlijk niet of het voor zelfbouw/fun is of voor real life.

[ Voor 5% gewijzigd door Guru Evi op 16-12-2004 18:52 ]