GoldenLine
Zaloguj się

konto usunięte

Temat: Problem z multicastami VMware

Hej,

Potrzebuje do celów naukowych przepuszczać sporą ilość multicastów a dokładniej w protokole IEC61850 opisywane jest to jako GOOSE, i niestety pakiety docierają ale są opóźnienia (mam rejestracje że są timeouty, zamiast po 30ms przychodzą np po 120ms), testowe zarówno pomiędzy VM <>VM i VM <>PM.

Ktoś coś poradzi ?
Używam ESXi 6 wersji bezpłatnej, ale w celach naukowych mogę posiedzieć na trialu :)
Pakiet do symulacji:
http://trianglemicroworks.com/products/testing-and-con...Ten post został edytowany przez Autora dnia 22.02.16 o godzinie 20:31
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

Napisz coś więcej. Czy komunikacja Vm,_>vm odbywa się w ramach tej samej PM czy wychodzi na zewnatrz. Jakie masz switche fizyczne jeżeli na zewnątrz. Czy wykorzystujesz natywny transfer po ethernecie czy enkapsulujesz w TCP/IP. Trzy "natywnej" transmisji bezpośrednio po ethernecie niektóre switche próbuja być mądrzejsze i traktować taką ramkę jak uszkodzoną. Poza tym możesz mieć założone jakieś limity na multicasty na portach na switchach.
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Dziękuje za odzew, aktualnie testy są robione na jednym ESXi (jeden PM), ruch zamyka się o virtualny standard switch VMware'a z przepuszczonymi wszystkimi vlanami (multicasty fruwają na rożnych vlanach).Ten post został edytowany przez Autora dnia 24.02.16 o godzinie 17:04
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

z przepuszczonymi wszystkimi vlanami (multicasty fruwają na rożnych vlanach)

bardziej od multicastów boję się nietoperzy. W jaki sposób mierzysz to opóźnienie? Rozumiem, że żaden z komponentów nie jest przeciążony.
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Opóźnienia są rejestrowane przez oprogramowanie do symulacji, wspominane opóźnienia nie powstają przy przesyłaniu danych PM <>PM,a dokładniej to pracuje w trybie serwer/ klient lub jak to woli w przypadku multicastów wydawca/subskrybent. Oprogramowanie jest pod Windows i pracuje w środowisku .Net, maszyny sa przygotowane tylko pod to oprogramowanie i nie są dociążone. Zweryfikowałem też to na różnych wersjach Windows, oraz z rożnymi wirtualnymi sieciówkami (E1000, E1000e oraz vmxnet3). Podeśle jak ogarnę się czasowo screen jak to wygląda w oprogramowaniu.Ten post został edytowany przez Autora dnia 24.02.16 o godzinie 17:13
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

Przejdźmy na priv bo szkoda zaśmiecać GL.
Link do wypowiedziLink
Daniel W.

Daniel W. Architekt ;)

Temat: Problem z multicastami VMware

Stos TCP w ESX dla systemów przemysłowych to inna bajka.
Wirtualizatory mają z tym problemy ;).
A jak się to zachowuje na fizycznym sprzęcie
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Witam,

Sprawa widzę że wygląda trochę inaczej, te problemy z timeoutami powstają kiedy z jakiegoś powodu przychodzą przekłamane czasy TTL zamiast 30ms wpada z jakiegoś powodu na 120ms:

Obrazek


Serwery mają synchronizację klientem NetTime, który łączy się do jednego serwera wzorcowego, synchronizacja klienta jest co 10 minut, z dokładnością do 1 ms (offset).

Wiresharkiem przeglądałem te pakiety, łatwo jest je filtrować bo je rozpoznaje jako protokół GOOSE, niestety nic ciekawego nie znalazłem, gdy porównywałem pakiet dobry i pakiet zły.
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

Daniel W.:
Stos TCP w ESX dla systemów przemysłowych to inna bajka.
Wirtualizatory mają z tym problemy ;).
A jak się to zachowuje na fizycznym sprzęcie

No właśnie. Stąd moje wcześniejsze pytanie, Czy ten protokół wrzucamy w TCP/IP czy bezpośrednio w ramkę Eternetową?

Swoją drogą można by jeszcze poeksperymentować z passthrough w komunikacji VM->PM o ile zasoby sprzętowe ci na to pozwalają.Ten post został edytowany przez Autora dnia 26.02.16 o godzinie 14:03
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Tomasz Z.:
No właśnie. Stąd moje wcześniejsze pytanie, Czy ten protokół wrzucamy w TCP/IP czy bezpośrednio w ramkę Eternetową?

No właśnie Panowie, to nie jest tak do końca, protokół wykorzystuje 2 kanały transmisji, TCP/IP jako klient/serwer oraz multicast mac jako wydawca/subksrybent, w weekend robię kolejne testy.Ten post został edytowany przez Autora dnia 26.02.16 o godzinie 15:30
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Mam mieszane uczucia po testach, 2 przypadki:
1. Wirtualna maszyna > passthrough NIC > skrętka > passthrough NIC > wirtualna maszyna
2. Wirtualna maszyna > vmxnet3 NIC > Standard vSwitch > vmxnet3 NIC > wirtualna maszyna

Laboratorium testowe stoi na Xeonie E3-1230, 16 GB ramu i aktualnie 256 GB dysku SSD (Samsung 850 Pro). Maszynki mają dyski w thinie.

I to jest dosyć dziwne zachowanie w obydwu przypadkach, timeouty pojawiają się w znaczącej ilości po jakimś czasie, tak jakby się jakiś bufor przepełnił, albo coś przechłodziło w stan idle. Wiem że aplikacja dotnetowa pod windowsem to nie jest nic szczególnego i może to ona tak się zachowuje, ale może macie jakieś pomysły ?
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

Jedyne co mi onlajnowo przychodzi do głowy to to że hardware zaczyna dyszeć wydajnościowo. Próbowałeś jeszcze skorelować moment kiedy zaczynają się te opóźnienia z obciążeniem całej maszyny fizycznej i poszczególnych VMów?
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Tomasz Z.:
Jedyne co mi onlajnowo przychodzi do głowy to to że hardware zaczyna dyszeć wydajnościowo. Próbowałeś jeszcze skorelować moment kiedy zaczynają się te opóźnienia z obciążeniem całej maszyny fizycznej i poszczególnych VMów?

Nie jest to możliwe każda wirtualka ma przydzielone 1 GB i 2 core'y z czego podczas ostaniach symulacji działa ich 4. Każda wirtualka praktycznie to 0 % obciążenia CPU, zużycie pamięci na poziomie 450MB.

Na pewno zauważalnie mniej błędów jest na passthrough NIC, ale to nie zmienia faktu że po pewnym czasie jest lawina błędów.

Co ciekawego restart maszyny odbierającej pakiety danych (klient) pomaga.Ten post został edytowany przez Autora dnia 02.03.16 o godzinie 09:04
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

Jeżeli sprawdzałeś obciążenie na wykresach to na chwilę obecną nie mam innych pomysłów bez fizycznego pomacania.
Link do wypowiedziLink
Daniel W.

Daniel W. Architekt ;)

Temat: Problem z multicastami VMware

Wniosek jest jeden nie wszystko można zwirtualizować ;)
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Raczej jest inny w tym wypadku, problem aplikacji, jestem na dobrej drodze poprawy modelu symulacji... ;)Ten post został edytowany przez Autora dnia 02.03.16 o godzinie 21:08
Link do wypowiedziLink
Tomasz Zieliński

Tomasz Zieliński Ignorant IT

Temat: Problem z multicastami VMware

>Wniosek jest jeden nie wszystko można zwirtualizować ;)

Np. pieca na eko-groszek :)

W ramach ostatniego eksperymentu możesz odpalić na maszynach wiresharka i popatrzeć czy w momencie kiedy powstają owe opóźnienia nie pojawiają się np. jakieś retransmisje czy inne niepokojące objawy (może zaczynają pojawiać się przy okazji tych pakietów jakieś inne).
Link do wypowiedziLink
Bartosz Partyka

Bartosz Partyka Administrator Inea

Temat: Problem z multicastami VMware

Przechodziłem ten sam problem z klastrem DNS. Wirtualizacja bez passthrough na karcie sieciowej powoduje wrzucenie kolejki na vCPU i mamy bardzo dużo przerwań soft.... co generuje opóźnienia.
Ale z passthrough powinno być znacznie lepiej bo kolejki są realizowane na karcie, a karta eth jaka ? Jeżeli nie karta to szukałbym problemu w OS.

Podpowiem ci Latency sensitivity featur: http://www.vmware.com/files/pdf/techpaper/latency-sens...

http://www.vmware.com/files/pdf/techpaper/latency-sens...

Generalnie :

Virtual Interrupt Coalescing
Disabling Hyperthreading
RX/TX Buffer tuning
Disabling Pause frames
Interrupt throttling
Disabling IPv6
Disable TPS in ESXi

Ale może się mylę..
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Bartosz P.:
realizowane na karcie, a karta eth jaka ?
Karty na PCIE Intela (w VMware wykrywane jako 82574L), bo PCI słabo idzie z przechwytywaniem vmware'owi,
Podpowiem ci Latency sensitivity featur: http://www.vmware.com/files/pdf/techpaper/latency-sens...
Ha!, da się to włączyć na bezpłatnym ESXi trzeba tylko doinstalować ESXi Free Web client interface i mamy Web vSphere bez vCenter :) Inna sprawa że funkcjonalność jest dostępna w płatnej wersji lub trialu ESXi - przetestowałem.

Jeszcze ten ciekawy artykuł:
https://www.vmware.com/files/pdf/techpaper/VMW-Tuning-L...

Co do podsunięcia pomysłu, bardzo dziękuje :), ale to nie wpłynęło na szybkość, tak jak pisałem to jest kwestia modelu symulacji i bugu aplikacji już z tym kombinuje :)Ten post został edytowany przez Autora dnia 06.03.16 o godzinie 17:21
Link do wypowiedziLink

konto usunięte

Temat: Problem z multicastami VMware

Tak jak myślałem, podsłuchałem transmisje wiresharkiem, to nie wina sieci vmware, tylko soft generuje rożne sekwencje TTL (zweryfikowałem po stronie odbierającej i wysyłającej) robi sekwencje:
timeAllowedtoLive:30 - sqNum 0 (wielkość pakietu przy wysyłaniu 308b odbieraniu 304b)
timeAllowedtoLive:60 - sqNum 1 (wielkość pakietu przy wysyłaniu 308b odbieraniu 304b)
timeAllowedtoLive:120 - sqNum 2 (wielkość pakietu przy wysyłaniu 308b odbieraniu 304b)

Z stąd te pseudo timeouty, muszę teraz namierzyć w którym miejscu model interpretuje to, bo to jest naturalne zachowanie w przypadku wysyłania GOOSE i całkowicie dopuszczalne bo tak naprawdę ten TTL służy talko do weryfikacji czy serwer żyje.Ten post został edytowany przez Autora dnia 14.03.16 o godzinie 18:22
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Problem z instalacja VMware...




Wyślij zaproszenie do
Anuluj