Temat: Problem z multicastami VMware

Jak TTL służy do weryfikacji?.

Temat: Problem z multicastami VMware

Daniel W.:
Jak TTL służy do weryfikacji?.

Nadużyłem słowa TTL, ale tutaj to się to nazywa timeAllowedtoLive, a w sofcie nazwali to Time to Live, reszta się zgadza, czemu tak ?, nie wiem słownictwo w IEC 61850 trzeba zostawić w spokoju :)

Jeżeli potrzebujesz głębszej interpretacji to musisz trochę poczytać o normie elektroenergetycznej, a w skrócie, goose wysyłane do IED mają swój czas np jak się zmieni stan to jest np. 30 ms, potem pakiety przychodzą coraz rzadziej 60, 120ms ... aż do zmiany stanu lub próbki pomiaru (SMV) itd. Jeżeli pakiet nie przyjdzie w czasie zdeklarowanym w poprzednim pakiecie jest informacja że coś się dzieje z dostępnością serwera / urządzenia IED, i wtedy zgłasza Goose Timeout Control Block, w tym przypadku symulacja robi zła sekwencję, co już nad tym pracuję.Ten post został edytowany przez Autora dnia 14.03.16 o godzinie 21:25

Temat: Problem z multicastami VMware

Ze stacka TCP na Vmware się nie doktoryzowałem, ale skoro można dość swobodnie przepuszczać trunkowane połączenia wewnątrz ESXa oraz IPXa to powinien on być dość przeźroczysty dla wszystkiego co wepchniemy w warstwę 2 (w tym jakieś egzotyczne protokoły). Niebezpieczeństwo może być tylko dla kawałków transmisji które mogą być interpretowane jako uszkodzone ramki. Stąd poprosiłem o podłączenie się sniferem, bo zazwyczaj daje nam to odpowiedź na pytanie czy wszystko "przechodzi".
Artykulik o opóźnieniach bardzo fajny, ale finalnie i tak człowiek dochodzi do wniosku, że wiele zależy od obciążenia samej maszyny.

Robert, tak z ciekawości, te czasy opóźnień o których piszesz wynikają z czegoś? Dla energetyki mógłbym sobie wyobrażać że są związane z okresem sinusoidy napięcia, ale to tak tylko gdybam.Ten post został edytowany przez Autora dnia 15.03.16 o godzinie 09:50

Temat: Problem z multicastami VMware

Tomasz Z.:
Robert, tak z ciekawości, te czasy opóźnień o których piszesz wynikają z czegoś? Dla energetyki mógłbym sobie wyobrażać że są związane z okresem sinusoidy napięcia, ale to tak tylko gdybam.

Tak te dopuszczalne opóźnienia wynikają z definicji przesyłanych danych, nie które maja duże czasy bo są np raportami dla systemów typu SCADA, a takie np próbki SMV (Sampled Measured Values) mają bardzo małe czasy bo podają pomiary np prądów, napięcia, itp. aby aparatura zabezpieczeniowa mogła szybko zareagować. A te czasy wyszły w symulacjach prawidłowo, Wireshark ładnie wszystko pokazał, bug jest w sofcie v3.7.

Tknęło mnie i ściągnąłem nowszą wersję oprogramowania v3.8, która wyszła w styczniu i poprawili bug:
"If a write is performed on an item that is in a dataset that is assigned to a Report Control Block. The server will return a bogus response to the client"

Aktualnie zero błędów wykazanych w poprzedniej wersji co potwierdzają moje odrębne badania Wiresharkiem.Ten post został edytowany przez Autora dnia 05.05.16 o godzinie 16:53