Latency meten tussen 2 pc's

[svarrio]

Beste mede-tweakers,

Voor een onderzoek wil ik de latency van een bericht meten tussen twee pc's die direct aan elkaar zijn gekoppeld. Dit zal een nul test worden en als echte test wil ik een homeplug (PLC) tussen de pc's hangen en de latency hiervan meten.
De precisie van deze meting moet minstens 100 microseconde zijn. De toegelaten latency is namelijk 3 a 4 ms.

Problemen waar ik tegenaan loop:
- Synchronisatie van de systeemklokken (volgens mij op te lossen met precision timing protocol, 1 microsende precissie).
- Precisie van de timestamp. Hoe precies is de timestamp die aan het bericht wordt gehangen vergeleken met de systeemklok?

Als iemand mij hiermee kan helpen dank ik u zeer

Groeten,
Sven van Eldik

[Orion84]

Een simpele ping volstaat niet? Natuurlijk meet je dan de latency heen en terug, maar ik zou bij direct gekoppelde PC's verwachten dat je dan gewoon <1ms responses krijgt, waarmee je bevestiging hebt dat het binnen je toegelaten latency zit? Mochten de pings boven je toegestane latency uitkomen, dan kan je alsnog in meer detail gaan testen.

Als je wilt dat we meedenken over je huidige aanpak en de problemen waar je tegenaanloopt is het misschien handig om even uit te leggen hoe je die berichten nu verstuurt / ontvangt?

[ Voor 10% gewijzigd door Orion84 op 04-03-2015 16:10 ]

[svarrio]

In een ping kan ik helaas geen data verzenden. (*bewerking* de data zal ongeveer 3 bytes zijn. De vertraging zal dus niet zo zeer komen door de data maar door de PLC)
De latency die ik wil meten is die van de power line communication (PLC). Daarvoor wil ik een nultest doen tussen de pc's en daarna het plc systeem ertussen hangen zodat ik een verschil kan berekenen dat veroorzaakt wordt door de PLC.

Hoe de berichten worden verstuurd is vrij. Het gaat puur om hoelang het bericht (liefst zonder overhead) erover doet van A naar B. Zelf dacht ik dat UDP dan het beste zou passen.

[ Voor 11% gewijzigd door svarrio op 04-03-2015 16:15 ]

[Orion84]

Waarom wil je data verzenden als je de latency wilt meten? Van een ping kan je overigens ook gewoon bepalen hoe groot de ping moet zijn.

Zoals gezegd: het voornaamste nadeel is dat je met een pingtest meet hoe snel je een response krijgt in plaats van dat je meet hoe lang een pakketje in één richting onderweg is. Maar als die respons binnen jouw toleranties valt, dan zal een pakketje in één richting ook binnen de toleranties vallen lijkt me.

En ook voor het vergelijken van PLC vs. zonder PLC kan een simpele ping test je al een beeld geven van de invloed.

Dus voordat je iets heel complex gaat bouwen om de klokken van de systemen perfect in sync te hebben en dan te gaan meten, zou ik gewoon eens beginnen met een simpel ping testje en zien of je daarna nog noodzaak hebt om het wat wetenschappelijker aan te pakken.

[ThinkPad]

iperf? Daar kun je ook allerlei parameters instellen.

[CyBeR]

svarrio schreef op woensdag 04 maart 2015 @ 16:13:
In een ping kan ik helaas geen data verzenden.

Zeker wel. De exacte data opgeven is wat lastiger maar je kunt gewoon een size opgeven.

Even tussendoor: een PLC is een procescontrolesysteem, niet een homeplug.

[ Voor 22% gewijzigd door CyBeR op 04-03-2015 17:02 ]

[Ben(V)]

Zoals al aangehaald is Iperf de tool hiervoor.
http://sourceforge.net/projects/iperf/


PS:
PLC = Programmable Logic Controller (ding voor industriele besturingen)

[ Voor 14% gewijzigd door Ben(V) op 04-03-2015 18:10 ]

[Ximon]

De belangrijkste vraag is volgens mij: wat wil je meten en waarom? "Latency" an sich betekent niet zoveel, aangezien de nuttige arbeid van een netwerk de latency direct beeinvloed. Een enkel bericht is ook niet een situatie die zich in het dagelijks leven veel zal voordoen. Sowieso is het meten van latency onder ideale omstandigheden niet interessant lijkt me, want dat is bij zo'n beetje alle bekabelde verbindingen onmeetbaar laag (< 1 ms). Je zou bijvoorbeeld "gemiddelde latency in een zwaarbelast Homeplug AV netwerk t.o.v. een 802.11n (2.4 GHz) netwerk onder vergelijkbare omstandigheden" kunnen onderzoeken. Nog mooier wordt het als je ook een toepassing erbij noemt (VoIP telefonie, internet gaming, video, etc). Als je daarna nog bijvoorbeeld de belasting van het netwerk varieert heb je volgens mij al een redelijk onderzoeksplannetje.

[svarrio]

Bedankt voor alle reacties.
Ik ga eens kijken wat iperf inhoud en uitzoeken of ping zal voldoen.

PLC staat voor power line communication, excuses voor de onduidelijkheid.

[Question Mark]

Waarom ga je een homeplug gebruiken als je latency kennelijk zo belangrijk is?

Een dimmer of halogeenlamp kan al een stoorbron zijn voor het gebruik van homeplugs waardoor de latency beinvloedbaar wordt. Zulke factoren kun je nooit allemaal meenemen in je testen, je zult dus nooit met zekerheid uitspraken kunnen doen over de maximale latency.Die homeplug dingen zijn leuk en zullen in veel gevallen ook prima voldoen, maar als latency zo belangrijk is kun je het beste gewoon een kabel trekken.

[CyBeR]

svarrio schreef op woensdag 04 maart 2015 @ 20:29:
PLC staat voor power line communication, excuses voor de onduidelijkheid.

Niet in onze wereld.

iperf is voor bandbreedte overigens.

[svarrio]

Question Mark schreef op woensdag 04 maart 2015 @ 20:35:
Waarom ga je een homeplug gebruiken als je latency kennelijk zo belangrijk is?

Een dimmer of halogeenlamp kan al een stoorbron zijn voor het gebruik van homeplugs waardoor de latency beinvloedbaar wordt. Zulke factoren kun je nooit allemaal meenemen in je testen, je zult dus nooit met zekerheid uitspraken kunnen doen over de maximale latency.Die homeplug dingen zijn leuk en zullen in veel gevallen ook prima voldoen, maar als latency zo belangrijk is kun je het beste gewoon een kabel trekken.

Helaas is dit niet mogelijk. Er ligt een kabel waar 220v 50Hz over staat met een belasting van +- 15 watt. Er kan geen extra kabel getrokken worden. Over dezelfde kabel moet gecommuniceerd worden. Deze communicatie is zeer eenvoudig maar heeft wel een tijdsinterval waarbinnen gemeld moet worden. Dit tijdsinterval is +- 3 ms.

CyBeR schreef op woensdag 04 maart 2015 @ 20:38:
[...]


Niet in onze wereld.

iperf is voor bandbreedte overigens.

Nogmaals mijn excuses voor de onduidelijkheid

[Fish]

Bij een tijds synchronisatie wordt standaard rekening met de latency.

Om te kijken in hoeverre deze gelijk (blijft) lopen tov van een andere server kun je gebruik maken van de stripchart optie
https://technet.microsoft.com/en-us/library/w32tm.aspx

latency meet je met ping, maak dan ook bij voorkeur het pakket zo groot als dat je zelf van plan bent
Natuurlijk is het deel afhankelijk van de (gebruikte) bandebreedte. om het tot een minimum te houden zul je mischien met qos wat bandbreedte moeiten reserveren


met "pathping" en een maximum response tijd ingesteld kun je ook wat statistieken verzamelen

[ Voor 42% gewijzigd door Fish op 04-03-2015 22:08 ]

[Ximon]

svarrio schreef op woensdag 04 maart 2015 @ 20:48:
[...]


Helaas is dit niet mogelijk. Er ligt een kabel waar 220v 50Hz over staat met een belasting van +- 15 watt. Er kan geen extra kabel getrokken worden. Over dezelfde kabel moet gecommuniceerd worden. Deze communicatie is zeer eenvoudig maar heeft wel een tijdsinterval waarbinnen gemeld moet worden. Dit tijdsinterval is +- 3 ms.


[...]


Nogmaals mijn excuses voor de onduidelijkheid

Is er wel een ander alternatief dan? Zoals Question Mark al aangaf is powerline niet de meest betrouwbare manier van netwerkcommunicatie. Een onderzoek lijkt me niet heel veel toevoegen, je kan dan beter direct gaan testen met de toepassing waar de powerline verbinding voor ingezet gaat worden. Als het bovendien om een een kritische toepassing gaat dan kan je er misschien beter vanaf zien, omdat het met een powerline netwerk gewoon vrijwel onmogelijk is om iets te garanderen.

[DukeBox]

De meeste Powerlan/EoP adapters blinken niet uit in stabiele/lage latency. Ik heb (had) 85Mbit sweex met een latency van <1ms en 500Mbit sitecom welke tussen de 1ms en 5ms schommelt.. met gemiddeld 1ms

[Dylanvo]

svarrio schreef op woensdag 04 maart 2015 @ 16:13:
In een ping kan ik helaas geen data verzenden. (*bewerking* de data zal ongeveer 3 bytes zijn. De vertraging zal dus niet zo zeer komen door de data maar door de PLC)
De latency die ik wil meten is die van de power line communication (PLC). Daarvoor wil ik een nultest doen tussen de pc's en daarna het plc systeem ertussen hangen zodat ik een verschil kan berekenen dat veroorzaakt wordt door de PLC.

Hoe de berichten worden verstuurd is vrij. Het gaat puur om hoelang het bericht (liefst zonder overhead) erover doet van A naar B. Zelf dacht ik dat UDP dan het beste zou passen.

De standaard ping size is sowieso 32 bytes aan data.. anders wordt de minimale frame grootte niet bereikt van 64 bytes. Je kan deze uiteraard vergroten en verkleinen, echter zodra je deze kleiner maakt dan 32 bytes wordt er alsnog een trailer toegevoegd in het frame om de minimale frame grootte te bereiken.

[DukeBox]

Buiten dat zijn er tegenwoordig veel truukjes met tcp/ip offload die er voor zorgt dat de latency niet correct te meten is zoals TCP delayed acknowledgment wat zeker met grotere MTU sizes van invloed is.

[ Voor 19% gewijzigd door DukeBox op 05-03-2015 09:26 ]

[svarrio]

Erg leuk om te zien dat iedereen wil meedenken, dank jullie wel hiervoor.

Ximon schreef op donderdag 05 maart 2015 @ 09:02:
[...]


Is er wel een ander alternatief dan? Zoals Question Mark al aangaf is powerline niet de meest betrouwbare manier van netwerkcommunicatie. Een onderzoek lijkt me niet heel veel toevoegen, je kan dan beter direct gaan testen met de toepassing waar de powerline verbinding voor ingezet gaat worden. Als het bovendien om een een kritische toepassing gaat dan kan je er misschien beter vanaf zien, omdat het met een powerline netwerk gewoon vrijwel onmogelijk is om iets te garanderen.

Je slaat de spijker op zn kop. Er is een ander alternatief en dat is een ethernet kabel trekken. Dit brengt reuzachtige kosten met zich mee in de toepassing vandaar dat ik ben ingeschakeld om te onderzoeken of de communicatie kan verlopen via Power Line Communication. De kansen zijn gering. Dat beseffen wij ook maar mits het mogelijk is scheelt het enorm in de kosten. Vandaar dat het belangrijk is om dit tot op het bot te onderzoeken.

DukeBox schreef op donderdag 05 maart 2015 @ 09:06:
De meeste Powerlan/EoP adapters blinken niet uit in stabiele/lage latency. Ik heb (had) 85Mbit sweex met een latency van <1ms en 500Mbit sitecom welke tussen de 1ms en 5ms schommelt.. met gemiddeld 1ms

In het final product zal niet de homeplug technologie gebruikt worden zoals op de schappen te koop is. Er zal vanaf scratch een product ontworpen worden dat over een powerline kan communiceren en de gespecificeerde eisen te halen.
Ik wil nu een homeplug gebruiken omdat het de enige technologie is wat op de schappen ligt die in theorie de eisen zou kunnen halen.

DukeBox schreef op donderdag 05 maart 2015 @ 09:25:
Buiten dat zijn er tegenwoordig veel truukjes met tcp/ip offload die er voor zorgt dat de latency niet correct te meten is zoals TCP delayed acknowledgment wat zeker met grotere MTU sizes van invloed is.

Deze delay krijg je volgens mij ook tezien in de nul test.

Om de latency van het powerline communcation systeem te meten voeren we eerst een nul test uit zonder de PLC ertussen. De latency die we hier meten wordt veroorzaakt door de pc's, netwerkkaaarten, protocollen en kabels. Hierna willen we een test doen MET de PLC ertussen. Dit zal naar verwachting een hogere latency opleveren. het verschil tussen de gemeten latency's wordt dan veroorzaakt door het PLC systeem.

Een ping gaat heen, daar wordt het een tijd vastgehouden en daarna weer teruggestuurd. Heeft iemand enig idee hoelang het duurt tussen aankomst van het bericht en terugsturen van het bericht op server 2? Als dit meer dan 0.5 ms is dan kunnen we geen ping gebruiken. Klok synchronisatie tussen 2 pc's kan namelijk tot op 10 microseconde niveau en dit is ruim voldoende.

[Fish]

affijn ..


Pc naast dat andere apparaat zetten. kabeltjej van 2 meter er tussen (of 100 op een rol) zal me worst wezen
En die pc met een rdp of teamviewer sessie besturen (via die powerline) en dan is latency geen issue meer

[Orion84]

svarrio schreef op donderdag 05 maart 2015 @ 12:38:
Een ping gaat heen, daar wordt het een tijd vastgehouden en daarna weer teruggestuurd. Heeft iemand enig idee hoelang het duurt tussen aankomst van het bericht en terugsturen van het bericht op server 2? Als dit meer dan 0.5 ms is dan kunnen we geen ping gebruiken. Klok synchronisatie tussen 2 pc's kan namelijk tot op 10 microseconde niveau en dit is ruim voldoende.

Hoezo "wordt een tijd vastgehouden"

PC2 reageert gewoon 'direct' op een ping.

Desnoods kan je dat ook gewoon zichtbaar maken door op beide PC's een netwerksniffer zoals wireshark mee te laten lopen. Dan kan je precies zien op PC2 hoeveel tijd er zit tussen het ontvangen van de ping en het versturen van de respons. En op PC1 kan je mogelijk ook wat preciezer zien hoeveel tijd er zit tussen versturen ping en ontvangen respons.

Nogmaals: bij een direct bekabelde LAN verbinding zal een ping als resultaat "<1ms" teruggeven. Wat voor jou belangrijk is, is om te kijken hoe dat verandert als je de homeplug set toevoegt. Blijft dat dan netjes stabiel op "<1ms" dan zit je gebakken.

Al is een dergelijke conclusie natuurlijk wat voorbarig als je uiteindelijke setup met allerlei speciale hardware etc. gaat werken die mogelijk totaal anders presteert en homeplug achtige constructies altijd sterk afhankelijk zijn van de situatie ter plekke.

Als je het synchen van de klok van de twee pc's trouwens al hebt opgelost, dan kan je natuurlijk perfect op beide een netwerksniffer draaien en dan een ping doen en de verzendtijd in de sniffer op PC1 vergelijken met de ontvangsttijd in de sniffer op PC2.

[ Voor 8% gewijzigd door Orion84 op 05-03-2015 13:22 ]

[marcop23]

Orion84 schreef op donderdag 05 maart 2015 @ 13:19:
[...]
Nogmaals: bij een direct bekabelde LAN verbinding zal een ping als resultaat "<1ms" teruggeven. [...]

Debian (dus waarschijnlijk ook Ubuntu e.d.) geeft een ping naar de router hier aan met twee decimalen, en de gemiddelden met 3:

64 bytes from 192.168.1.1: icmp_req=91 ttl=64 time=1.44 ms
^C
--- 192.168.1.1 ping statistics ---
91 packets transmitted, 91 received, 0% packet loss, time 90121ms
rtt min/avg/max/mdev = 1.323/1.758/5.800/0.529 ms

Als deze onder de 1 ms duikt krijg je geloof ik 3 decimalen.

Ik weet niet precies of deze nauwkeurig lijkende getallen ook echt nauwkeurig zijn, maar misschien heb je daar wat meer aan dan <1ms? Hier zit trouwens een switch tussen.

[DukeBox]

svarrio schreef op donderdag 05 maart 2015 @ 12:38:
Deze delay krijg je volgens mij ook tezien in de nul test.

Dat is juist het punt.. het wordt als latency weergegeven terwijl dat het niet is.

[svarrio]

Orion84 schreef op donderdag 05 maart 2015 @ 13:19:
[...]

Hoezo "wordt een tijd vastgehouden"

PC2 reageert gewoon 'direct' op een ping.

Desnoods kan je dat ook gewoon zichtbaar maken door op beide PC's een netwerksniffer zoals wireshark mee te laten lopen. Dan kan je precies zien op PC2 hoeveel tijd er zit tussen het ontvangen van de ping en het versturen van de respons. En op PC1 kan je mogelijk ook wat preciezer zien hoeveel tijd er zit tussen versturen ping en ontvangen respons.

Nogmaals: bij een direct bekabelde LAN verbinding zal een ping als resultaat "<1ms" teruggeven. Wat voor jou belangrijk is, is om te kijken hoe dat verandert als je de homeplug set toevoegt. Blijft dat dan netjes stabiel op "<1ms" dan zit je gebakken.

Al is een dergelijke conclusie natuurlijk wat voorbarig als je uiteindelijke setup met allerlei speciale hardware etc. gaat werken die mogelijk totaal anders presteert en homeplug achtige constructies altijd sterk afhankelijk zijn van de situatie ter plekke.

Met tijd vastgehouden bedoelde ik de computation time van pc2, maar uit het resultaat dat een ping bij direct LAN verbinding <1ms is zal dit waarschijnlijk verwaarloosbaar zijn. Gelukkig Ik denk dat een dat een ping wel moet lukken.

marcop23 schreef op donderdag 05 maart 2015 @ 13:25:
[...]

Debian (dus waarschijnlijk ook Ubuntu e.d.) geeft een ping naar de router hier aan met twee decimalen, en de gemiddelden met 3:
[...]

Als deze onder de 1 ms duikt krijg je geloof ik 3 decimalen.

Ik weet niet precies of deze nauwkeurig lijkende getallen ook echt nauwkeurig zijn, maar misschien heb je daar wat meer aan dan <1ms? Hier zit trouwens een switch tussen.

3 decimalen nauwkeurig is wel een bijkomstigheid maar ik verwacht wel dat deze te vinden zijn. Het is wel goed om even te kijken wat hiervan de nauwkeurigheid is. Wellicht dat een tool zoals wireshark deze tijden nauwkeuriger kan weergeven?

[Anoniem: 660674]

Met het programma tping kan je ook de packetgrootte instellen.

[Fish]

met een gewone ping ook hoor

[svarrio]

Direct pingen tussen twee pc's levert toch nog een ping van gem. 0.7ms.
Zou dit verbeteren als ik tussen twee raspberry pi's zou pingen?
Weet iemand wat ik kan doen om deze ping tijd te verlagen?

[Orion84]

Dat is toch ruim binnen je marge? Aannemende dat een pakketje in enkele richting er de helft van die tijd over doet zit je dan op 10% van je toegestane latency...

[svarrio]

klopt, maar dit is nog een nul test. Als ik het systeem ertussen hang dan pas weet ik hoeveel latency het systeem veroorzaakt. Om de latency van de pc's zo min mogelijk van invloed te laten zijn op het geheel wil ik graag de nultest verlagen. Dus de latency van een ping bericht tussen 2 pc's verlagen.

[Fish]

zo min mogelijk is niet relevant. wel zo stabiel mogelijk.

dan weet je wat je al kan trekken van je resultaat (dat doe je ook met een lage waarde)

[ Voor 14% gewijzigd door Fish op 05-03-2015 17:08 ]

[svarrio]

Fish schreef op donderdag 05 maart 2015 @ 17:07:
zo min mogelijk is niet relevant. wel zo stabiel mogelijk.

dan weet je wat je al kan trekken van je resultaat

Goed punt. Als de latency altijd gelijk zou zijn zou ik daar meer aan hebben dan een lage latency.
Ik heb echter geen idee of dat wel mogelijk is... Een lagere latency zal volgens mij ook lijden tot een stabielere (absoluut) latency.

[borft]

Wow, dat is wel erg traag. Hier op kantoor is de gemiddelde ping, op Gbit ethernet, met 2 switches ertussen rond de 0.233 gemiddeld volgens ping. Tussen 2 servers op dezelfde switch is het gemiddeld 0.149 zelfs.

[ Voor 19% gewijzigd door borft op 05-03-2015 17:11 ]

[heuveltje]

Heb je uberhaubt wel eens aan die pluggen gemeten ?
Die we hier op het werk hebben liggen, zitten over het algemeen tussen de 4 en 10 ms
En op een slecht moment mag je daar een nulletje aan toe voegen.
Dus dan hoef je je ook niet druk te maken over die ,01 ms meer of minder

[ Voor 32% gewijzigd door heuveltje op 05-03-2015 17:14 ]

[Cave_Boy]

borft schreef op donderdag 05 maart 2015 @ 17:10:
Wow, dat is wel erg traag. Hier op kantoor is de gemiddelde ping, op Gbit ethernet, met 2 switches ertussen rond de 0.233 gemiddeld volgens ping. Tussen 2 servers op dezelfde switch is het gemiddeld 0.149 zelfs.

Vind dit best snel met een paar van die powerpluggen. Ik ken deze vaak met een hogere latency.

[Orion84]

Cave_Boy schreef op donderdag 05 maart 2015 @ 17:19:
[...]


Vind dit best snel met een paar van die powerpluggen. Ik ken deze vaak met een hogere latency.

Dit is nog zonder de homeplug dingen er tussen

[svarrio]

borft schreef op donderdag 05 maart 2015 @ 17:10:
Wow, dat is wel erg traag. Hier op kantoor is de gemiddelde ping, op Gbit ethernet, met 2 switches ertussen rond de 0.233 gemiddeld volgens ping. Tussen 2 servers op dezelfde switch is het gemiddeld 0.149 zelfs.

Dat zijn meer resultaten die ik had verwacht/op had gehoopt. Waar zou dit aan kunnen liggen dat mijn latency's relatief hoog zijn? Firewalls en evt ethernet kaarten zouden van invloed kunnen zijn.
Jullie meer ideeen?

[borft]

Wat voor netwerk heb je (10/100/1000 ethernet? fdx?)? Gebruik je een switch? Wat voor netwerkkaarten? Hoe snel zijn je pc's (zijn ze druk of idle)? wat voor besturingssysteem draai je op?

[svarrio]

raspberry pi: 10/100 - linux
PC: 10/100/1000 Base Ethernet Controller - windows 7 enterprise

Apparaten waren idle. Er zijn geen switches of routers gebruikt. alleen 1 cro ssover kabel.

[Jay-v]

svarrio schreef op donderdag 05 maart 2015 @ 17:21:
[...]


Dat zijn meer resultaten die ik had verwacht/op had gehoopt. Waar zou dit aan kunnen liggen dat mijn latency's relatief hoog zijn? Firewalls en evt ethernet kaarten zouden van invloed kunnen zijn.
Jullie meer ideeen?

Latency wordt bepaald door van alles, soort kabel, lengte kabel, NIC, switch, switch methode etc.

Lees dit maar eens:
http://www.cisco.com/c/en...ite_paper_c11-465436.html

Cut-through switching is de snelste variant dit voegt 10 microsec of minder toe aan je latency per hop.