Skocz do zawartości
Sim00n

[ROZWIĄZANY]Benchmark sampowych timerów - szukam opinii na temat ich działania.

Rekomendowane odpowiedzi

Cześć goście, zrobiłem przed chwilą takie małe testy natywnych timerów w sampie bo jak każdy z nas wie (mam nadzieje) nie są idealne.

Odpaliłem taki kawałek kodu: http://pastebin.com/a2873Z0w

Pisane na kolanie ale robi co planowałem. W skrócie .. zrobiłem timer na 1000ms i co call sprawdzam jak mocno GetTickCount() odbiega od oczekiwanej wartości. Zbieram to sobie w średnią* i dodatkowo wystąpienia każdej liczby zapisuje do małej (100 indexowej) tablicy bo zauważyłem, że rozbieżność zamyka się generalnie w przedziale 20-100ms. Wszystko co jest powyżej 100ms łapie w takie "catch all" na indexie 99 i potem olewam w obliczeniach jako wyjątek od normy, który zmieniłby mi średnie. Potem dorzuciłem jeszcze do środka timera proste pętle O(n) na 100,000 i na 1,000,000 obrotów. Zapisuje też min i max żeby sobie to potem wyprintować w konsoli i móc ładnie skopiować do exela bo jestem zbyt leniwy żeby bawić się w zapisywanie do jakiegoś CSV.

Wyniki:

TiPgiWI.png

 

Wyszło mi, że sampowe timery spóźniają się o ~50ms co call zakładając, że powinny się wykonać co 1000ms (1sec). I wyszło mi z obliczeń, że tracimy średnio 3sec. na każdą minutę działania skryptu.

Oczywiście to jest w idealnych warunkach bez niczego innego w tle.

Piszę ten temat bo chce się Was zapytać, czy sądzicie, że można przeżyć z takimi timerami czy nie? Po godzinie tracimy prawie 3 minuty, po całym daniu ponad godzinę ... Alternatywy to pluginy lub zakodzenie własnego timera na dziwnej fuzji sampowych timerów i OnPlayerUpdate.

Opinie?

* S' = S + ((An+1 - S) / (n+1))

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

3 sekundy w ciągu godziny? poważnie w sampie wam to robi różnice? ;p

Co do fuzji sampowych timerów z OnPlayerUpdate - jak chcesz to zrobić skoro OnPlayerUpdate wykonuje sie "co ping" (np raz co 40ms a drugi co 120ms) w dodatku jak dany gracz jest na serwerze. 

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Godzinę temu, Beata_Szydlo_2015 napisał:

3 sekundy w ciągu godziny? poważnie w sampie wam to robi różnice? ;p

Może wydać się głupie ale jeśli ktoś zamierza zrobić pro racingowy server z trasami na czas (SA:RACE:DM) i tam na prawdę top timy różnią się od siebie o tysięczne sek.

Ja osobiście używam już od dłuższego czasu <fixes2> - polecam. Przy lekkich sprawach używam sampowskich, nie przeszkadzają mi takie straty dopóki nie zależy mi na precyzji.

Fajny teścik.

 

@DOWN: taa tak się to robi profesjonalnie, bardziej chodzilo mi o to, że zazwyczaj są te timery wyświetlane dla graczy, ale tak.. w zasadzie to tylko błyskotka (głupio by było gdyby czas przejazdu stanowczo [zauważalnie] różnił się od stanu licznika na mecie), prawdziwy czas to i tak bd roznica tickcountow.

Edytowane przez Mati_(POL)

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
23 minut temu, Mati_(POL) napisał:

Może wydać się głupie ale jeśli ktoś zamierza zrobić pro racingowy server z trasami na czas (SA:RACE:DM) i tam na prawdę top timy różnią się od siebie o tysięczne sek.

No to raczej takie serwery uzywaja GetTickCount do liczenia czasu niz timerow ;p

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
14 godzin temu, Sim00n napisał:

Cześć goście, zrobiłem przed chwilą takie małe testy natywnych timerów w sampie bo jak każdy z nas wie (mam nadzieje) nie są idealne.

(...)

Piszę ten temat bo chce się Was zapytać, czy sądzicie, że można przeżyć z takimi timerami czy nie? Po godzinie tracimy prawie 3 minuty, po całym daniu ponad godzinę ... Alternatywy to pluginy lub zakodzenie własnego timera na dziwnej fuzji sampowych timerów i OnPlayerUpdate.

Opinie?

Mogłeś jeszcze dorzucić benchmark urządzenia, na którym robiłeś testy :P
Środowisko SA-MP jak na grupkę pasjonatów-programistów i tak zostało nieźle napisane, bo jednak do czegoś się ono nadaje - daje się coś w nim napisać.
Jeżeli komuś brakuje ~50 ms czy nawet tych 3 minut to po prostu musi oprzeć swój kod (zsynchronizować, dostroić) na funkcjach typu GetTickCount i nie ma co z tego robić sprawy.
Timery może i nie są idealne, ale są wystarczające żeby np zrobić licznik do pojazdu albo opóźnić kick itp, ale trzeba to właśnie mieć na uwadze, że nie do wszystkiego się one nadają, co z kolei wynika z dobrej znajomości środowiska.

10 godzin temu, Mati_(POL) napisał:

(...)

Ja osobiście używam już od dłuższego czasu <fixes2> - polecam. Przy lekkich sprawach używam sampowskich, nie przeszkadzają mi takie straty dopóki nie zależy mi na precyzji.

(...)

Te "fixy" konkretnie dla timerów polegają na tym, że ktoś po prostu zmierzył te opóźnienia i wytyczył jakąś regułę, którą zastosował przy wywoływaniu tych timerów. Równie dobrze można samemu mieć to na uwadze, ale wiadomo... wygoda :)

Edytowane przez PrzMas

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

 

Cytuj

 

Te "fixy" konkretnie dla timerów polegają na tym, że ktoś po prostu zmierzył te opóźnienia i wytyczył jakąś regułę, którą zastosował przy wywoływaniu tych timerów. Równie dobrze można samemu mieć to na uwadze, ale wiadomo... wygoda :)

A nie czasem na tym?



 

//gora inca
enum etimer {

      time, callback[], interval, starttime

}
new timery[MAX_TIMEROW][etimer];

new timer_c;

//Hook dla SetTimer(call[], time, interval)
timery[timer_c][time] = time;

timery[timer_c][callback] = call; //tak wiem, format
timery[timer_c][interval] = interval;
timery[timer_c][starttime] = GetTickCount();
timer_c++;

//OnGMInit:
SetTimer("uruchomtimery", 1, true);

//uruchomtimery:
for(new i; i < timer_c; i++)
{
     if(timery[starttime] + timery[time] >= GetTickCount()) 
     //uruchomienie callbacka przez CallLocalFunction, jesli interval=0 to usuniecie/zablokowanie wykonania ponownego, reset "starttime"
}

//pisane w trybie ultrakolanko


Chociaż to również może generować opóźnienia. Poza tym timer co 1ms zamuli serwer tak czy inaczej. A wyliczenie opóźnienia jest guzik warte - na każdym sprzęcie, pod każdą inną mapą, przy różnej ilości graczy i różnym zajęciu czasu CPU przez inne procesy ten czas opóźnienia będzie różny (if(CountWord("różny","czas", "każdym") > 10) return Ban("Maku")).

Wracając do tematu. Fixy dla timerów w przypadku, gdy wykorzystujemy to w SAMPie nie mają sensu. No, chyba, że chcemy zrobić zegar atomowy w textdrawie. 
Tylko zmniejszymy sobie tym optymalizację.

PS. Ten bbcode ssie. 10 minut probowalem to poprawic i nie idzie. Jak poprawie to zapisac nie chce -,-

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
19 godzin temu, Beata_Szydlo_2015 napisał:

3 sekundy w ciągu godziny? poważnie w sampie wam to robi różnice? ;p

Co do fuzji sampowych timerów z OnPlayerUpdate - jak chcesz to zrobić skoro OnPlayerUpdate wykonuje sie "co ping" (np raz co 40ms a drugi co 120ms) w dodatku jak dany gracz jest na serwerze. 

3 sekundy w ciągu minuty*. Przez godzinę tracimy 3 minuty co robi dużą różnicę.

 

18 godzin temu, Mati_(POL) napisał:

Może wydać się głupie ale jeśli ktoś zamierza zrobić pro racingowy server z trasami na czas (SA:RACE:DM) i tam na prawdę top timy różnią się od siebie o tysięczne sek.

Nie wiem jak to jest w praktyce, ale w teorii na dużym serwerze nie sądzę, że da się zmierzyć czas bardziej dokładnie niż 1/4 sekundy biorąc pod uwagę ping i częstotliwość OnPlayerUpdate.

 

16 godzin temu, KosiPlonsa napisał:

Lepiej byś poradnik o timerach nagrał :P Więcej bym się dowiedział :D

Taki mam właśnie zamiar ale przed nagraniem czegokolwiek chce być pewny, że przekazuje widzom poprawne informacje, stąd ten temat. Ktoś mi podesłał wczoraj tutoriale innego youtubera i załamałem się jak zobaczyłem ile tam jest mylnych informacji.

 

19 godzin temu, Beata_Szydlo_2015 napisał:

Co do fuzji sampowych timerów z OnPlayerUpdate - jak chcesz to zrobić skoro OnPlayerUpdate wykonuje sie "co ping" (np raz co 40ms a drugi co 120ms) w dodatku jak dany gracz jest na serwerze. 

OnPlayerUpdate wykonuje się dla gracza a nie jako ogólny event na serwerze i dlatego powiedziałem, że kod to musiałaby być fuzja pomiędzy normalnymi timerami i OnPlayerUpdate. Wydaje mi się, że ważniejsze, żeby timer był dokładny przez dłuższy okres czasu niż przez konsekutywne ticki. W skrócie użyłbym OnPlayerUpdate (bo ma największą częstotliwość kiedy są gracze) i zwykłego timera (na czas kiedy nie ma graczy), żeby generować sztuczne eventy, w których na podstawie GetTickCount sprawdzałbym czas. Tym sposobem miałbym (tak samo jak w normalnych timerach), różnice ok 50ms pomiędzy każdym tickiem ale ta różnica nie stackowałaby się bo mógłbym ją sam nadrabiać.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Trochę dziwny ten test moim zdaniem, sam komputer co używasz na codzień nie nadaje się do odliczania czasu, dlatego mamy synchronizację. Zrób prosty program, puść na 6 godzin i używaj komputera, zobaczysz jakie opóźnienia będzie generował. I tu mówimy o prostym programie, gdzie samp od niego jest rozbudowany. 

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Co masz na myśli mówiąc prosty program? W nawtywnej aplikacji mogę zakodzić bardzo dokładne timery bo mogę sam kontrolować eventy. Mowimy tu o poprawieniu opóźnień sampa.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

http://forum.sa-mp.com/showthread.php?t=435525

Sam od zawsze korzystam z tego pluginu, wykorzystuje sampowe ProcessTick do wywoływania funkcji po określonym czasie. Nie pamiętam już, ale kiedyś robiłem test i rozbieżności w czasie timera i czasie wykonania były raczej minimalne.

Średnia różnicy czasu z 300 wywołań timera 200 milisekundowego gdy grałem na serwerze wyniosła 200.0, za drugim razem 200.00994, trzecim 199.99673. Pasowałoby sprawdzić to jeszcze na serwerze z większą ilością graczy. Nie testowałem na czystym serwerze tylko normalnym gamemodzie (około 7 tys linii), pluginach typu streamer itd, wraz z timerem 250ms na licznik prędkości i driftu.

Edytowane przez .silent

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Gość
Ten temat został zamknięty. Brak możliwości dodania odpowiedzi.

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników przeglądających tę stronę.

×