Autor Wątek: Stabilnosc serwerow  (Przeczytany 19599 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

black_wic

  • Gość
Stabilnosc serwerow
« dnia: Wrzesień 27, 2005, 21:59:50 »
Witam wszystkich serdecznie.
Jak to jest ze stabilnoscia serwerow. Gra jest na rynku pare lat, a hmm w ciagu triala, a wlasciwie polowy triala zauwazylem ze dosyc czesto jest problem z rozlaczaniem, lagami. Gram od paru miechow w WoW'a i tam czasami zdarzyly sie takie problemy, ale przez 7 miesiecy od premiery mozna takie zdarzenia policzyc na palcach jednej reki.  Tu pytanie, jak to wygladalo w dluzszym okresie czasu. Pytam, poniewaz zamierzam troche dluzej zabawic w swiecie EVE.

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #1 dnia: Wrzesień 27, 2005, 22:26:45 »
No w?a?nie wi?c od kilku dni jest totalnie do dupy. U mnie s? ci?gle wieczorami lagi a teraz na przyk?ad wogóle nie mog? si? po??czy? z serwerem. Nie wiem co si? dzieje ale widocznie serwer im nie wyrabia. Ostatnio przekroczyli 16.000 graczy na raz i widocznie co? im si? sypie. Pisz? teraz bo od pó? godziny nie udaje mi si? po??czy? i jestem ju? w%$^&@#$%.

EverSin

  • Gość
Stabilnosc serwerow
« Odpowiedź #2 dnia: Wrzesień 27, 2005, 22:48:28 »
dzisiaj ogolnie cos sie jebie i to zdrowo nigdy nie bylo takich lagow jak dzis przez caly dzien... a co najgorsze to nie ma od CCP zadnej informacji wiec ciezko powiedziec czy to u nich czy moze cos na laczach gdzies sie wali :/

Z tym ze CCP jak juz im sie cos wali to zawsze daje INFO i pare restartow serwa dodatkowo robi wiec nie wiem co myslec... narazie zwalam na lacze gdzies i tyle...

Xarthias

  • Użyszkodnik
  • *
  • Wiadomości: 6 512
  • Spamin' the World
    • Zobacz profil
  • Imię postaci: Xarthias
  • Korporacja: GoonWaffe
  • Sojusz: Goonswarm Federation
Stabilnosc serwerow
« Odpowiedź #3 dnia: Wrzesień 28, 2005, 07:54:38 »
Co? jest na rzeczy, bo ja si? od wczorajszego wieczora nie mog? zalogowa?... Albo mi si? zatrzymuje na authenticating albo w po?owie paska logowania i koniec... Po paru minutach Connection to server lost.
Nawet kilkukrotna zmiana IP tu nie pomog?a (cho? zazwyczaj pomaga?o).
Przedwieczny.

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #4 dnia: Wrzesień 28, 2005, 10:51:04 »
Ja od dwoch dni latam sobie po Solitude i lagow nie mam.
Moze w Syndicate sa lagi???

I Xarth..., czy aby nie zmienilo Ci sie MTU?

Dormio

  • Użyszkodnik
  • *
  • Wiadomości: 3 456
  • Mi'Sie
    • Zobacz profil
  • Imię postaci: Dormio
  • Korporacja: Shocky Industries Ltd.
Stabilnosc serwerow
« Odpowiedź #5 dnia: Wrzesień 28, 2005, 10:56:03 »
W Verge Vendor ostatnio równie? jakby mniejsze lagi.
Brak sygnatury w ramach protestu przed czepiaczami...

Xarthias

  • Użyszkodnik
  • *
  • Wiadomości: 6 512
  • Spamin' the World
    • Zobacz profil
  • Imię postaci: Xarthias
  • Korporacja: GoonWaffe
  • Sojusz: Goonswarm Federation
Stabilnosc serwerow
« Odpowiedź #6 dnia: Wrzesień 28, 2005, 10:58:31 »
Chyba b?d? musia? router zresetowa?, ale MTU nie zmienia?em...
Dobrze, ?e w pracy si? mog? zalogowa? i skilla zmieni? :)
Przedwieczny.

StellarSheep

  • Użyszkodnik
  • Wiadomości: 862
    • Zobacz profil
  • Imię postaci: GwiezdnaOfca
  • Korporacja: SzacherMacher!
  • Sojusz: CzeszeBerete!
Stabilnosc serwerow
« Odpowiedź #7 dnia: Wrzesień 28, 2005, 11:27:40 »
Jak ktos lata po empire to ma lagi :P




WANT PIE NOW!!!!!

dzikus

  • Gość
Stabilnosc serwerow
« Odpowiedź #8 dnia: Wrzesień 28, 2005, 12:01:29 »
Na Devblogu ju? napisali ?e im sprz?t nie wyrabia. A nowy jest ju? zamówiony od jakiego? czasu i ci?gle w drodze. Troch? w transporcie huragany im przeszkodzi?y. I sami przyznaj?, ?e s? ofiarami swojego w?asnego sukcesu - po prostu za du?o ludzi wali do nich na serwer 8)

marcoos

  • Użyszkodnik
  • Wiadomości: 630
    • Zobacz profil
Stabilnosc serwerow
« Odpowiedź #9 dnia: Wrzesień 28, 2005, 12:33:43 »
Cytat: "dzikus"
Na Devblogu ju? napisali ?e im sprz?t nie wyrabia. A nowy jest ju? zamówiony od jakiego? czasu i ci?gle w drodze. Troch? w transporcie huragany im przeszkodzi?y. I sami przyznaj?, ?e s? ofiarami swojego w?asnego sukcesu - po prostu za du?o ludzi wali do nich na serwer 8)


LOL - ciekawe co taki blizzard mówi?, jak im milion userów p?k? ;)
(a przy okazji - wie kto? jaki jest limit na jeden serwer w WOWie?)
Bermuda Syndrome [BAS-3]

StellarSheep

  • Użyszkodnik
  • Wiadomości: 862
    • Zobacz profil
  • Imię postaci: GwiezdnaOfca
  • Korporacja: SzacherMacher!
  • Sojusz: CzeszeBerete!
Stabilnosc serwerow
« Odpowiedź #10 dnia: Wrzesień 28, 2005, 13:41:30 »
Roznica jest taka misiu ze w wowie to masz iles setek serwerow.
Tutaj masz jeden.
Sa plusy i minusy jednej opcji i drugiej.
Generalnie preferuje jeden serwer.




WANT PIE NOW!!!!!

marcoos

  • Użyszkodnik
  • Wiadomości: 630
    • Zobacz profil
Stabilnosc serwerow
« Odpowiedź #11 dnia: Wrzesień 28, 2005, 13:54:48 »
Cytat: "StellarSheep"
Roznica jest taka misiu ze w wowie to masz iles setek serwerow.
Tutaj masz jeden.


Oczywi?cie (jak mo?na wywnioskowa? z ca?o?ci mojego postu) te drobn? ró?nic? zauwa?y?em :P

Jednak ca?y czas nurtuje mnie pytanie odno?nie limitów userów per server w wowie (albo innych licz?cych si? gier tego typu)
Bermuda Syndrome [BAS-3]

black_wic

  • Gość
Stabilnosc serwerow
« Odpowiedź #12 dnia: Wrzesień 28, 2005, 14:57:16 »
Cytat: "marcoos"

LOL - ciekawe co taki blizzard mówi?, jak im milion userów p?k? ;)
(a przy okazji - wie kto? jaki jest limit na jeden serwer w WOWie?)


Serwery blizza robia sie full gdzies przy okolo 3k-4k graczy i wtedy pojawiaja sie kolejki.

btw. milion to tylko w europie :-)

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #13 dnia: Wrzesień 28, 2005, 16:40:05 »
No nie znowu po restarcie serwera nie mog? si? po??czy?. Ju? mnie zaczyna powoli to wszystko dobija?. Powiedzcie chocia?, ?e macie podobnie to nie b?d? niszczy? co logowanie klawiatury...

Aenyeweddien

  • Użyszkodnik
  • Wiadomości: 421
    • Zobacz profil
  • Imię postaci: Aenyeweddien
  • Korporacja: Unseen Academy
  • Sojusz: The Unseen Company
Stabilnosc serwerow
« Odpowiedź #14 dnia: Wrzesień 28, 2005, 16:43:20 »
Cytat: "RIPsento"
No nie znowu po restarcie serwera nie mog? si? po??czy?. Ju? mnie zaczyna powoli to wszystko dobija?. Powiedzcie chocia?, ?e macie podobnie to nie b?d? niszczy? co logowanie klawiatury...


Ja nie jestem w domu ale jeszcze rano nie mia?am najmniejszych k?opotów
Wróg mojego wroga jest moim przyjacielem

Beware I am witch

Alterego Kirh'aard; nezma

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #15 dnia: Wrzesień 28, 2005, 16:48:14 »
Rano te? nie mia?em ?adnych problemó ale teraz nie mog? po??czy? si? z tym je$#%#%$ serwerem.

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #16 dnia: Wrzesień 28, 2005, 16:49:25 »
Cytat: "RIPsento"
No nie znowu po restarcie serwera nie mog? si? po??czy?. Ju? mnie zaczyna powoli to wszystko dobija?. Powiedzcie chocia?, ?e macie podobnie to nie b?d? niszczy? co logowanie klawiatury...


Zawsze po DT (restarcie serwera) eve'ka sciaga jakies mikro-patche... o roznej wielkosci, czasem po kilka MB... i jesli masz wolne lacze, to moze to wygladac na klopoty z logowaniem...

Moja rada (zeby to sprawdzic)... w katalogu z EVE masz program o nazwie Log Server, albo jakos tak... Uruchom go najpierw, potem odpal EVE, wpisz dane do zalogowania, a nastepnie obserwuj Log Server...
Powinienes tam widziec, czy jakies dane sa transmitowane miedzy serwerem a klientem... jesli tak - no to juz wiesz... cos sie sciaga... jesli Ci sie zatnie na oczekiwaniu na kolejny pakiet... to moze powinienes sprawdzic swoje MTU na karcie sieciowej (polecam 576 lub 1000).

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #17 dnia: Wrzesień 28, 2005, 17:03:05 »
Cytuj
3811   2005.09.28 14:09:30:917   Timeslice warning order 1, 250ms (408ms in tasklet) : returning from:
3812   2005.09.28 14:09:30:917   ->AutoContext::<b>PoolHelper()</b> in c:/builds/files/client/script/../../common/script/sys/uthread.py(541) from c:/builds/files/client/script/../../common/script/sys/uthread.py(49)
3813   2005.09.28 14:09:30:917   ->ParallelHelper::AutoContext::<b>_ClickConnect()</b> in c:/builds/files/client/script/ui/login/login.py(618) from c:/builds/files/client/script/../../common/script/sys/uthread.py(49)
3814   2005.09.28 14:09:30:917   ->Marshal::Load
3815   2005.09.28 14:09:30:917   ->PyOS::CyclicGC
3816   2005.09.28 14:09:31:354   Timeslice warning order 1, 323ms (845ms in tasklet) : returning from:
3817   2005.09.28 14:09:31:354   ->AutoContext::<b>PoolHelper()</b> in c:/builds/files/client/script/../../common/script/sys/uthread.py(541) from c:/builds/files/client/script/../../common/script/sys/uthread.py(49)
3818   2005.09.28 14:09:31:354   ->ParallelHelper::AutoContext::<b>_ClickConnect()</b> in c:/builds/files/client/script/ui/login/login.py(618) from c:/builds/files/client/script/../../common/script/sys/uthread.py(49)
3819   2005.09.28 14:09:31:354   ->Marshal::Load
3820   2005.09.28 14:09:31:354   ->PyOS::CyclicGC
3821   2005.09.28 14:09:31:427   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_dgmtypeattribs', '', 8, 36) ,**kw= {} )
3822   2005.09.28 14:09:31:484   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_messages', '', 9, 36) ,**kw= {} )
3823   2005.09.28 14:09:31:509   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_Statistics', '', 10, 36) ,**kw= {} )
3824   2005.09.28 14:09:31:525   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_allianceshortname s', '', 11, 36) ,**kw= {} )
3825   2005.09.28 14:09:31:542   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_categories', '', 12, 36) ,**kw= {} )
3826   2005.09.28 14:09:31:577   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_invtypereactions', '', 13, 36) ,**kw= {} )
3827   2005.09.28 14:09:31:624   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_dgmtypeeffects', '', 14, 36) ,**kw= {} )
3828   2005.09.28 14:09:31:650   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_EncyclopediaTypes', '', 15, 36) ,**kw= {} )
3829   2005.09.28 14:09:31:667   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_ChannelTypes', '', 16, 36) ,**kw= {} )
3830   2005.09.28 14:09:31:681   ChainEvent( ProcessLoginProgress ,*args= ('loginprogress::gotcachedobject_config_BulkData_owners', '', 17, 36) ,**kw= {} )
3831   2005.09.28 14:09:31:697   Write:  Packet::CallReq (Address::Client(clientID="0",callID="2",service="None"),Address::Node(nodeID="1000102",service="objectCaching",callID="None"),153 bytes,(1, 'GetCachableObject', (1, 'config.StaticOwners', (127723837611548422L, 52859), 92138), {'m
3832   2005.09.28 14:09:31:697   - achoVersion': 1}),{})
3833   2005.09.28 14:09:31:698   ASendEvent::HandleEvent(157, 0) parent=32884656
3834   2005.09.28 14:09:34:900   AsyncPacketSocket::OnRead() 8192 bytes read.  0 bytes in mReadBuffer before
3835   2005.09.28 14:09:34:900   sizeOfMessage=220996 sizeOfBuffer=8192
3836   2005.09.28 14:09:34:900   Reading message, need 220996, got 8192 waiting for more data
3837   2005.09.28 14:09:34:900   AsyncPacketSocket::OnRead() 568 bytes read.  8192 bytes in mReadBuffer before
3838   2005.09.28 14:09:34:900   sizeOfMessage=220996 sizeOfBuffer=8760
3839   2005.09.28 14:09:34:900   Reading message, need 220996, got 8760 waiting for more data
3840   2005.09.28 14:09:37:439   AsyncPacketSocket::OnRead() 1460 bytes read.  8760 bytes in mReadBuffer before
3841   2005.09.28 14:09:37:439   sizeOfMessage=220996 sizeOfBuffer=10220
3842   2005.09.28 14:09:37:439   Reading message, need 220996, got 10220 waiting for more data
3843   2005.09.28 14:09:49:364   AsyncPacketSocket::OnRead() 1460 bytes read.  10220 bytes in mReadBuffer before
3844   2005.09.28 14:09:49:364   sizeOfMessage=220996 sizeOfBuffer=11680
3845   2005.09.28 14:09:49:364   Reading message, need 220996, got 11680 waiting for more data
3846   2005.09.28 14:10:09:909   Releasing expired cache object after 0 uses
3847   2005.09.28 14:10:09:909   Releasing expired cache object after 0 uses
3848   2005.09.28 14:10:09:909   Releasing expired cache object after 0 uses
3849   2005.09.28 14:10:09:909   Releasing expired cache object after 6 uses
3850   2005.09.28 14:10:09:909   Releasing expired cache object after 3 uses
3851   2005.09.28 14:10:09:909   Releasing expired cache object after 2 uses
3852   2005.09.28 14:10:09:909   Releasing expired cache object after 0 uses
3853   2005.09.28 14:10:09:909   Releasing expired cache object after 0 uses


To s? ostatnie linijki po których wszystko si? zatrzymuje. Rozumiecie co? z tego?

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #18 dnia: Wrzesień 28, 2005, 17:17:57 »
jak widac z ponizszego wycinka 3832 2005.09.28 14:09:31:697 - achoVersion': 1}),{})
3833 2005.09.28 14:09:31:698 ASendEvent::HandleEvent(157, 0) parent=32884656
3834 2005.09.28 14:09:34:900 AsyncPacketSocket::OnRead() 8192 bytes read. 0 bytes in mReadBuffer before
3835 2005.09.28 14:09:34:900 sizeOfMessage=220996 sizeOfBuffer=8192
3836 2005.09.28 14:09:34:900 Reading message, need 220996, got 8192 waiting for more data
3837 2005.09.28 14:09:34:900 AsyncPacketSocket::OnRead() 568 bytes read. 8192 bytes in mReadBuffer before
3838 2005.09.28 14:09:34:900 sizeOfMessage=220996 sizeOfBuffer=8760
3839 2005.09.28 14:09:34:900 Reading message, need 220996, got 8760 waiting for more data
3840 2005.09.28 14:09:37:439 AsyncPacketSocket::OnRead() 1460 bytes read. 8760 bytes in mReadBuffer before
3841 2005.09.28 14:09:37:439 sizeOfMessage=220996 sizeOfBuffer=10220
3842 2005.09.28 14:09:37:439 Reading message, need 220996, got 10220 waiting for more data
3843 2005.09.28 14:09:49:364 AsyncPacketSocket::OnRead() 1460 bytes read. 10220 bytes in mReadBuffer before
3844 2005.09.28 14:09:49:364 sizeOfMessage=220996 sizeOfBuffer=11680
3845 2005.09.28 14:09:49:364 Reading message, need 220996, got 11680 waiting for more data


masz coraz wolniejsze przesylanie przychodzacych paczek... co czesto jest oznaka gubienia pakietow... zmien sobie MTU i wtedy zobacz.
Powinno pomoc.

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #19 dnia: Wrzesień 28, 2005, 17:29:46 »
No mo?e ok ale co to jest MTU i jak i gdzie si? to zmienia?

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #20 dnia: Wrzesień 28, 2005, 17:33:54 »
Cytat: "RIPsento"
No mo?e ok ale co to jest MTU i jak i gdzie si? to zmienia?


Polecam opcje SEARCH (w prawej gornej czesci strony forum)...
i znajdziesz np. to:
(http://forum.eve-centrala.pl/viewtopic.php?p=18208#18208)
(MTU - Maximum Transfer Unit)

a takze: http://www.cisco.com/warp/public/105/38.shtml#win2k

seamon

  • Gość
Stabilnosc serwerow
« Odpowiedź #21 dnia: Wrzesień 28, 2005, 17:38:56 »
Witam mam problem...

1786   2005.09.27 14:31:21:511   AsyncSocket::OnRead: mReadCont = 10, returning 645 bytes to python
1787   2005.09.27 14:31:21:513   Read:  Packet::Notification (Address::Node(nodeID="92164",service="None",callID="None"),Address::BroadCast(broadcastID="OnRemoteExecute",narrowcast="[]",idtype="userid"),LARGE PAYLOAD(1080 bytes),{})
1788   2005.09.27 14:31:21:513   sizeOfMessage=220996 sizeOfBuffer=919
1789   2005.09.27 14:31:21:513   Reading message, need 220996, got 919 waiting for more data
1790   2005.09.27 14:31:21:533   AsyncSocket::Recv.  The input queue is empty will wait for next message, mReadCont = 11
1791   2005.09.27 14:31:22:249   AsyncPacketSocket::OnRead() 1438 bytes read.  919 bytes in mReadBuffer before
1792   2005.09.27 14:31:22:249   sizeOfMessage=220996 sizeOfBuffer=2357
1793   2005.09.27 14:31:22:249   Reading message, need 220996, got 2357 waiting for more data
1794   2005.09.27 14:35:36:813   Timeslice warning order 1, 340ms (368ms in tasklet) : returning from:
1795   2005.09.27 14:35:36:833   ->Main tasklet
1796   2005.09.27 14:35:36:833   ->BeOS::System
1797   2005.09.27 14:35:45:644   Timeslice warning order 1, 360ms (393ms in tasklet) : returning from:
1798   2005.09.27 14:35:45:645   ->Main tasklet
1799   2005.09.27 14:35:45:667   ->BeOS::System
1800   2005.09.27 14:35:45:667   ->Trinity
1801   2005.09.27 14:35:45:667   ->Trinity::TriDevice::Render
1802   2005.09.27 14:35:57:022   Timeslice warning order 1, 350ms (368ms in tasklet) : returning from:
1803   2005.09.27 14:35:57:068   ->Main tasklet
1804   2005.09.27 14:35:57:085   ->BeOS::System
1805   2005.09.27 14:37:25:489   Timeslice warning order 1, 249ms (258ms in tasklet) : returning from:
1806   2005.09.27 14:37:25:489   ->Main tasklet
1807   2005.09.27 14:37:25:490   ->BeOS::System
1808   2005.09.27 14:37:25:490   ->Trinity
1809   2005.09.27 14:37:25:491   ->Trinity::TriDevice::Render
1810   2005.09.27 14:37:25:887   Timeslice warning order 1, 320ms (322ms in tasklet) : returning from:
1811   2005.09.27 14:37:25:943   ->Main tasklet
1812   2005.09.27 14:37:25:943   ->BeOS::System
1813   2005.09.27 14:37:58:474   Timeslice warning order 1, 204ms (211ms in tasklet) : returning from:
1814   2005.09.27 14:37:58:534   ->Main tasklet
1815   2005.09.27 14:37:58:534   ->BeOS::System
1816   2005.09.27 14:38:19:505   AsyncPacketSocket::OnRead() 5752 bytes read.  2357 bytes in mReadBuffer before
1817   2005.09.27 14:38:19:505   sizeOfMessage=220996 sizeOfBuffer=8109
1818   2005.09.27 14:38:19:505   Reading message, need 220996, got 8109 waiting for more data
1819   2005.09.27 14:38:23:300   Timeslice warning order 1, 230ms (256ms in tasklet) : returning from:
1820   2005.09.27 14:38:23:300   ->Main tasklet
1821   2005.09.27 14:38:23:312   ->BeOS::System
1822   2005.09.27 14:38:33:985   Timeslice warning order 1, 208ms (266ms in tasklet) : returning from:
1823   2005.09.27 14:38:34:047   ->Main tasklet
1824   2005.09.27 14:38:34:047   ->BeOS::System
1825   2005.09.27 14:38:46:648   OnMachoTimeout, packet= None
1826   2005.09.27 14:38:46:650   An exception occurred while getting an initial cached object
1827   2005.09.27 14:38:46:680   EXCEPTION #1 logged at  2005-09-27 16:38:46
1828   2005.09.27 14:38:46:680   Traceback (most recent call last):
1829   2005.09.27 14:38:46:681   File "c:/builds/files/client/script/../../common/script/net/machoNet.py", line 1200, in __GetCachedObjectHelper
1830   2005.09.27 14:38:46:682   File "c:/builds/files/client/script/../../common/script/net/cachedObject.py", line 168, in GetCachedObject
1831   2005.09.27 14:38:46:684   File "c:/builds/files/client/script/../../common/script/net/cachedObject.py", line 162, in __UpdateCache
1832   2005.09.27 14:38:46:687   File "c:/builds/files/client/script/../../common/script/net/objectCaching.py", line 430, in GetCachableObject
1833   2005.09.27 14:38:46:689   File "c:/builds/files/client/script/../../common/script/net/ServiceCallGPCS.py", line 163, in RemoteServiceCall
1834   2005.09.27 14:38:46:691   File "c:/builds/files/client/script/../../common/script/net/ServiceCallGPCS.py", line 236, in RemoteServiceCallWithoutTheStars
1835   2005.09.27 14:38:46:692   File "c:/builds/files/client/script/../../common/script/net/ObjectCallGPCS.py", line 187, in CallDown
1836   2005.09.27 14:38:46:694   File "c:/builds/files/client/script/../../common/script/net/ExceptionMappingGPCS.py", line 26, in CallDown
1837   2005.09.27 14:38:46:696   File "c:/builds/files/client/script/../../common/script/net/ExceptionWrapperGPCS.py", line 95, in CallDown
1838   2005.09.27 14:38:46:697   File "c:/builds/files/client/script/../../common/script/net/machoNet.py", line 2693, in _BlockingCall
1839   2005.09.27 14:38:46:699   File "c:/builds/files/client/script/../../common/script/sys/uthread.py", line 320, in receive
1840   2005.09.27 14:38:46:700   RuntimeError: ('OnMachoTimeout', {'what': 'A low-level timeout occurred during a remote service request'})
1841   2005.09.27 14:38:46:700   This function was called with arguments:
1842   2005.09.27 14:38:46:701   self :      <stackless.channel object at 0x0313D620>
1843   2005.09.27 14:38:46:701   The local namespace contained nothing in addition to the arguments.
1844   2005.09.27 14:38:46:702   eve.session was <Session: (sid:19, clientID:0, mutating:0, corprole:0x0, languageID:PL, role:0x1, rolesAtAll:0x0, rolesAtHQ:0x0, rolesAtBase:0x0, rolesAtOther:0x0)>
1845   2005.09.27 14:38:46:702   calltimer.key was objectCaching::GetCachableObject



eee co jest grane panowie? po restarcie niemoge sie polaczyc;/

Seamon

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #22 dnia: Wrzesień 28, 2005, 17:43:59 »
LUDZIE!!!

1) Czy Wy myslicie, ze my tutaj siedzimy po to aby czytac Wasze logi za Was? Troche wysilku, i mozna zobaczyc co jest nie tak...

2) Czy Wy myslicie, ze my jestesmy programami debug'ujacymi? Nie wklejajcie tu tych logow... jesli ktos bedzie chcial taki zobaczyc, to:
...a) albo sam sobie taki wygeneruje
...b) albo poprosi Was o to (w razie udzielania pomocy)



grrrr.... jeszcze 13 minut i wychodze z roboty  :D

seamon

  • Gość
Stabilnosc serwerow
« Odpowiedź #23 dnia: Wrzesień 28, 2005, 17:46:47 »
wkleilem log bo myslalem ze to pomoze... dzieki za pomoc normalnie odpowiedz byla powalajace... w wolnym tlumaczeniu trza bylo napisac:
"radz sobie sam"

Seamon

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #24 dnia: Wrzesień 28, 2005, 17:49:39 »
Cytat: "seamon"
wkleilem log bo myslalem ze to pomoze... dzieki za pomoc normalnie odpowiedz byla powalajace... w wolnym tlumaczeniu trza bylo napisac:
"radz sobie sam"

Seamon


Seamon... jestem juz troche zmeczony po calym dniu pracy... z tad ten ton...
A jesli bys porownal swoj log z tym co jest 2-3 posty wczesniej, to zauwazylbys podobienstwo (nie odebrales calej paczki - np. "need 220996, got 2357 waiting for more data " i potem juz nie ma... czyli pakiety wcielo...). Zastosuj rade ktorej udzielilem poprzedniej osobie...

Tomash Kovahlsky

  • Użyszkodnik
  • *
  • Wiadomości: 601
    • Zobacz profil
  • Imię postaci: Tomash Kovahlsky
  • Korporacja: Polish Task Forces
  • Sojusz: C0VEN
Stabilnosc serwerow
« Odpowiedź #25 dnia: Wrzesień 28, 2005, 17:51:30 »
Cytat: ireul
.

Ire... to byl ktos inny...




a Tobie sie nie chcialo nick'ow przeczytac :P
« Ostatnia zmiana: Luty 16, 2013, 18:41:15 wysłana przez Ireul Taar »

seamon

  • Gość
Stabilnosc serwerow
« Odpowiedź #26 dnia: Wrzesień 28, 2005, 17:53:47 »
przeczytalem noi wlasnie dlatego dalem loga bo niebylem pewien.... wole sie zapytac niz zaczac grzebac i zepsuc...

Seamon

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #27 dnia: Wrzesień 28, 2005, 18:37:57 »
Cytuj
Windows 2000/XP

Note: The modification of the Windows NT TCP/IP parameters involves editing the registry. This should only be attempted by experienced system administrators because mistakes can render the system unbootable. After these registry changes are done, reboot to apply the changes.

Disable PMTUD:

PMTU discovery is enabled by default, but can be controlled with the addition of this value to the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
\EnablePMTUDiscovery
 
PMTU Discovery:  0 or 1 (Default = 1)
 
Data Type:  DWORD

A "1" enables discovery while a "0" disables it. When PMTU discovery is disabled, a MTU of 576 bytes is used for all non-local destination IP addresses. The TCP MSS= 536.

When you set this parameter to 1 (True), it causes TCP to attempt to discover the Maximum Transmission Unit (MTU or largest packet size) over the path to a remote host. With the discovery of the Path MTU and the limitation of TCP segments to this size, TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs. Fragmentation adversely affects TCP throughput and network congestion.


Dobra wszystko jest jasne tylko u mnie nie ma takiej ?cie?ki dost?pu. Nie ma nigdzie katalogu EnablePMTUDiscovery i nie mog? wpisa? tam warto?ci wy??czaj?c? t? opcj?. Chyba, ?e nale?y wpisa? ca?y klucz do rejestru ??cznie z tym katalogiem, ale tego nie jestem na 100% pewien wi?c narazie poczekam na jak?? podpowied?.

Cytuj
Set Interface MTUs to 1500:

These parameters for TCP/IP are specific to individual network adapter cards. These appear under this Registry path, where "adapter ID" refers to the Services subkey for the specific adapter card:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
Interfaces\[Adapter ID]
 
MTU: Set it to equal the required MTU size in decimal (default 1500)
 
Data Type:  DWORD

This parameter overrides the default MTU for a network interface. The MTU is the maximum packet size in bytes that the transport transmits over the underlying network. The size includes the transport header. Note that an IP datagram can span multiple packets. Values larger than the default for the underlying network result in the transport using the network default MTU. Values smaller than 68 result in the transport using an MTU of 68.


To pozmienia?em na 576 tak jak przeczyta?em na forum, jednak nic to nie pomog?o. mo?e dlatego ?e nie znalaz?em powy?szej opcji.
Niech mnie kto? o?wieci bo ju? ca?kowi?ie zg?upia?em.

seamon

  • Gość
Stabilnosc serwerow
« Odpowiedź #28 dnia: Wrzesień 28, 2005, 18:48:34 »
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
\EnablePMTUDiscovery

niemam takiej sciezki

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
Interfaces\[Adapter ID]

tego rowniez niemam....
przeinstalowalem gre... nic
zrestartowalem kompa.... tez nic
przekierowalem porty..... tez nic....

jakies sugestie?

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #29 dnia: Wrzesień 28, 2005, 19:08:29 »
Dupa zbita podopisywa?em te klucze i nic nie pomog?o sytuacja si? powtarza i jako? nie widze nadzieji na popraw?. Mo?e jednak znajdzie si? kto? kto podpowie mo?e co? jeszcze.

Xarthias

  • Użyszkodnik
  • *
  • Wiadomości: 6 512
  • Spamin' the World
    • Zobacz profil
  • Imię postaci: Xarthias
  • Korporacja: GoonWaffe
  • Sojusz: Goonswarm Federation
Stabilnosc serwerow
« Odpowiedź #30 dnia: Wrzesień 28, 2005, 19:42:30 »
Ja si? tam nie znam za mocno, ale jak masz router to wydaje mi si?, ?e to si? na routerze zmienia.
Ja mam np (przy neo 512) 1492 i dzia?a... zazwyczaj :P
Przedwieczny.

RIPsento

  • Gość
Stabilnosc serwerow
« Odpowiedź #31 dnia: Wrzesień 28, 2005, 19:46:03 »
Nie mam routera tylko po??czenie kablowe czy jakie? lan nie jestem pewien co to dok?adnie jest. Najgorszy jest fakt ?e wszystko dzia?a?o dzisiaj rano. Praktycznie nie by?o problemów do godziny 12.00 naszego czasu. Pó?niej po restarcie nie mog?em si? ju? po??czy?. Nie wydaje mi si? ?eby wina le?a?a po stronie mojego ??cza ale sam nie jestem ju? niczego pewien.

Xarthias

  • Użyszkodnik
  • *
  • Wiadomości: 6 512
  • Spamin' the World
    • Zobacz profil
  • Imię postaci: Xarthias
  • Korporacja: GoonWaffe
  • Sojusz: Goonswarm Federation
Stabilnosc serwerow
« Odpowiedź #32 dnia: Wrzesień 28, 2005, 20:34:51 »
Zamorduj admina  :twisted:
Ja ??cz?c si? przez lan u mojej kobiety to cz?sto nawet skilla zmieni? nie mog?em... Dopiero interwencja u admina pomog?a.
Przedwieczny.

black_wic

  • Gość
Stabilnosc serwerow
« Odpowiedź #33 dnia: Wrzesień 28, 2005, 23:38:34 »
Hmm, nie wiem czemu ale ta gra gryzie sie z win2k3. Pod win xp nie mam problemow z logowaniem na serwer (ustawienia firewalli itp nie wchodza w gre bo akurat na tym sie znam).

marcoos

  • Użyszkodnik
  • Wiadomości: 630
    • Zobacz profil
Stabilnosc serwerow
« Odpowiedź #34 dnia: Wrzesień 29, 2005, 08:56:57 »
Odno?nie MTU to proponuje: http://neostrada.info/download/pafiledb.php?action=file&id=12
(praktycznie sprawdzone u jednej osoby) :)
Tylko jeden tip: po zmianie konieczny jest restart windowsów!

Odno?nie MTU - To faktycznie jest sprawa routerów, ale ?le skonfigurowany router nie defragmentuje pakietów (czyli sam nie zmniejsza pakietów) i dlatego obej?ciem tego problemu (i aby nie prosi? o pomoc niedouczonych adminów ;) ) jest w?a?nie wymuszone zmniejszenie d?ugo?ci pakietów TCP/IP
Bermuda Syndrome [BAS-3]