Chwilowy spadek transferu

[Kriss_1981]

Witam

Otoz moj problem polega na tym ze w trakcie pobierania lub wysylania mam chwilowy spadek do 0 niezaleznie z czego sciagam Od pocztaku tak mam po jakims czasie wykonalem TCP/IP Patch czyli zmiania pliku systemowego tcpip.sys, bez zmian Sprawdzalem pod w2k i bylo ok. Czy ktos wie gdzie lezy problem?

Dane:
system w2k8
karta bezprzewodowa ralink rt61

Pozdrawiam

[KrissTofferr]

A jaką prędkość gwarantuje Twój dostawca (w umowie)?

[Kriss_1981]

w dzien 1,5 mb a po 23 2 mb ale zawsze daje troszke wiecej Ale to nie ma nic do rzeczy bo na starszych systemach dobrze chodzi he stabilnie bez skokow

[KrissTofferr]

na starszych systemach dobrze chodzi he stabilnie bez skokow

Wejdź na http://www.speedguide.net/analyzer.php i gdy wyświetli się jeden długi link to podaj go nam w następnym poście.

[Jo_gurt]

Kriss_1981, jakieś firewalle/antywirusy/pakiety bezpieczeństwa?

[Kriss_1981]

KrissTofferr tak moze byc?

Jo_gurt outpost firewall pro 2009 i kaspersky mhm pakiety bezpieczenstwa? Akurat ten firewall tez mam pod w2k i jest ok zobacze pozniej jak idzie bez antivira

[Jo_gurt]

utpost firewall pro 2009 i kaspersky

Kaspersky też ma firewalla zdaje się, masz oba odpalone?

[KrissTofferr]

Kriss_1981, Z tej analizy wynika że masz bez potrzeby włączone wykrywanie rozmiaru MTU i trochę za małe okno odbioru (receive window)- jak na te 2 Mbit/s. Możliwe że taka kombinacja tych parametrów powoduje czkawkę. Musiał byś spróbować ustawić programem TCP Optimizer:
"MTU" -- 1492
Zaznaczona opcja "Modify all network adapters",
"TCP Receive Window" -- 63888
"MTU Discovery" -- No
"Black Hole Detect" -- Default
"Window Scaling" -- pozostaw nie zaznaczone
"Timestamps" -- pozostaw nie zaznaczone
i pozostałe parametry bez zmian.

[ Dodano: 2009-03-28, 12:14 ]
Dodatkowe informacje:
Largest MTU shows packet loss from 1465 to 1472 using PPPoE
PPPoE MTU stuck under 1486 in Windows XP_2k

[Kriss_1981]

KrissTofferr to nic nie pomoglo he. Na dodatek wylaczylem Karta Microsoft 6to4#2 i IPv6 ale to i tak nic nie daje bo sie dodaje nowe "Karta Microsoft 6to4#3"

Mhmm co do mtu standardowo mialem 1480 i przestawilem na 1492 czyli powiadasz zebym pokombinowal z tym?

Jo_gurt nie uzywam kis tylko sam antivir Mialem wylaczone calkowicie i bez zmian

[KrissTofferr]

Kriss_1981, Pokaż znów wyniki z http://www.speedguide.net/analyzer.php

[Kriss_1981]

wlasnie chcialem Ci pokazac, mialem z tego niezly ubaw jak zobaczylem wynik, chyba cos nie trybi ten optimizer pod w2k8

[KrissTofferr]

Jak widać "TCP Optimizer" potraktował w2k8 jako system w2k i tylko namieszał w rejestrze.
W TCP Optimizer wybierz: File -- Restore backed up settings -- wybierz plik .spg z datą.

Programu stricte kompatybilnego z w2k8 nie znam

[Kriss_1981]

Kurcze raz mi sie udalo zmienic ale potem cos znowu przestawilem i dalej nie chce mi zalapac a jakby tak recznie zmodyfikowac? jest jakas komenda na te rwin i mtu discovery?

[KrissTofferr]

jakas komenda na te rwin i mtu discovery?

Najpewniej w podręczniku do Windows Server 2008. Jak ustalisz tytuł to łatwo też znajdziesz eBook (.chm/.pdf)

[Kriss_1981]

he znalzlem cos takiego http://winoptymalizacja.republika.pl/ar ... a-mtu.html i po sprawdzeniu wychodzi 5696 czyzby mtu powinno byc u mnie ustawione na 1464?

[KrissTofferr]

co do mtu standardowo mialem 1480

Jak pamiętasz po pierwszej analizie na speedguide.net widać było że system jednak używał MTU = 1492 (właśnie dzięki Path MTU Discovery) więc wiadomo już jakie MTU jest optymalne.
Cablenut jest kompatybilny z w2k8?

[ Dodano: 2009-03-28, 17:58 ]
Według Performance Enhancements in the Next Generation TCP/IP Stack

Receive Window Auto-Tuning enables TCP window scaling by default, allowing up to a 16 MB window size. As the data flows over the connection, the Next Generation TCP/IP stack monitors the connection, measures the current bandwidth-delay product for the connection and the application receive rate, and adjusts the receive window size to optimize throughput. The Next Generation TCP/IP stack no longer uses the TCPWindowSize registry values.

Wygląda na to że w Windows Vista i Windows Server 2008 nie da się ustawić stałego rozmiaru okna odbioru.
Jeśli ten system jest tak elastyczny to nie jestem już pewnien co jest przyczyną tych przerw o których mówiłeś na początku.

[ Dodano: 2009-03-28, 18:17 ]
Ostatecznie znalazłem wpisy rejestru pozwalające na modyfikację MTU oraz MTU Discovery.
Download details TCP_IP Registry Values for Microsoft Windows Vista and Windows Server 2008

[Kriss_1981]

Cablenut pisza ze jest pod viste wiec raczej tak no to sprobujemy

Recznie probowalem zmienic Default TCP Receive Window (RWIN) i nie trybi MTU Discovery (RFC1191) tez nie da rady wylaczyc

Znalazlem cos takiego http://smallvoid.com/article/tcpip-rwin-size.html oraz http://smallvoid.com/article/vista-tcpip-auto-rwin.html i nie pomaga he. Co do rwin wystarczy 16384?

A tak mam standardowo pod w2k

[KrissTofferr]

Ciekawe informacje znalazłeś o poleceniu netsh ale mówisz że nie wprowadza zmian... Może sprawdź Regmon-em z www.sysinternals.com jakie parametry z rejestru są modyfikowane w czasie wykonywania polecenia.

RWIN = 16384 bajtów jest zbyt mały jak na łącze 2 Mb/s (250KB/s). Tak to sugeruje kalkulator BDP w TCP Optimizer.

Według Performance Enhancements in the Next Generation TCP/IP Stack

Can be scaled up to 1 gigabyte (GB) with window scaling Window scaling, defined in RFC 1323, allows TCP to negotiate a scaling factor for the window size during connection establishment. You can enable window scaling by setting the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts registry value to 1 or 3. By default, window scaling is only used on a connection if the received synchronize (SYN) segment contains the Window Scale option.

Według TCP_IP Registry Values for Microsoft Windows Vista and Windows Server 2008

Tcp1323Opts
Key: Tcpip\Parameters
Value Type: REG_DWORD—number (flags)
Valid Range: 0 or 2
0 (disable the use of the TCP timestamps option)
2 (enable the use of the TCP timestamps option)

Default: No value.
Description: This value controls the use of the RFC 1323 TCP Timestamp option. The default behavior of the TCP/IP stack is to not use the Timestamp options when initiating TCP connections, but use them if the TCP peer that is initiating communication includes them in their synchronize (SYN) segment.

Czyli według jednego dokumentu zmieniając Tcp1323Opts (wartość 1 lub 3) można wpływać na skalowanie okna odbioru a według drugiego można wpływać tylko na timestamps (wartość 0 lub 2). Haha. Ostatecznie decyduje flaga w SYN... Obydwie strony muszą wyrazić chęć skalowania. Dlatego nie wiem czy wynik ze speedguide jest miarodajny. Może zawsze będzie pokazywał że "RWIN Scaling (RFC1323) = 0 bits" ?

Jeszcze dla porównania konfiguracja Windows Server 2003:

Microsoft Windows Server 2003 TCP/IP Implementation Details
Tcp1323Opts
Key: Tcpip\Parameters
Value Type: REG_DWORD—number (flags)
Valid Range: 0, 1, 2, 3
0 (disable RFC 1323 options)
1 (window scaling enabled only)
2 (timestamps enabled only)
3 (both options enabled)

[Kriss_1981]

Może sprawdź Regmon-em z www.sysinternals.com jakie parametry z rejestru są modyfikowane w czasie wykonywania polecenia.

Ten akurat nie dziala pod viste ale ProcessMonitor owszem Tylko jak to wylapac jak caly czas cos dodaje w ulamku sekund

Może zawsze będzie pokazywał że "RWIN Scaling (RFC1323) = 0 bits" ?

Wiesz akurat pare razy mialem inaczej. Mhmm moze i faktycznie ten analyzer po tych zmianach nie wyswietla dobrze? Zobacze jak bedzie wygladalo Tcp1323Opts pod 1 i 3 he

Edit:
Juz nie mam sil na to tcp optimizer dodaje dwa wpisy GlobalMaxTcpWindowSize oraz TcpWindowSize a zeby bylo RWIN Scaling (RFC1323) = 2 bits (scale factor: 2^2=4) to w nim musi byc zaznaczone window scaling roznie kombinowalem i net chodzil troche gorzej a transfer i tak skacze Dlaczego na starym kompie pod w2k dobrze chodzi? Sprobuje za jakis czas na xp he

Tak mialem

[Kriss_1981]

Witam ponownie

Po tym kombinacjach przeszedlem na xp i hulala az milo Niedawno problem sie rozwiazal otoz pojawila sie nowa wersja ktora oficjalnie jeszcze nie wyszla na stronie ralinka W wersjach 2.1.0 i 2.1.3 nie moglem korzystac gdyz http://www.heise-online.pl/news/Luka-w- ... ksa--/7310 co powodowalo zawiechy kompa heh i jedyne wyjscie bylo korzystanie z starszej wersji co powodowalo takie spadki Teraz wereszcie moge korzystac z ulubionego windowsa

KrissTofferr dzieki ze probowales mi pomoc

Pozdrawiam wszystkich

[KrissTofferr]

hula az milo

No to fajn
Czyli że można było wykryć ten problem wymieniając kartę wi-fi
na jakąś inną niż z chipsetem Ralink'a.