Wysoki ping i niski transfer - Netia 10 Mb.

[wieslaw531]

Reklamowałem. Pojawiła się ekipa i wówczas było OK więc mogłem tylko potwierdzić poprawność usługi.

Niunia w trakcie reklamacji potwierdziła, że jest źle.

Wydaje mi się, że grają w kulki. Jestem świadom, że ta wartość 10 Mb oznacza - DO. Czyli to co w obrazkach mieści się w granicach.

 

 

net-log.txt

[DawidS28]

Jestem świadom, że ta wartość 10 Mb oznacza - DO. Czyli to co w obrazkach mieści się w granicach.

 

Cóż. Opcja "do 10 Mb/s" zaczyna się, jeśli dobrze pamiętam, gdzieś w okolicach 990 kb/s, czyli nieco poniżej 1 Mb/s. Czekam, aż wreszcie dostawca będzie musiał określić widełki pasma i gwarantowaną przepustowość, bo inaczej nic się nie zmieni.

 

Ping to nic, ten w checku z Netii jest zadziwiająco niski, pokusiłbym się nawet o stwierdzenie, że w normie. Prawdziwe testy pokazują coś innego (wartość uśredniona ze 100 wykonanych):

 

  0                                           192.168.1.2 
                               0/ 100 =  0%   |
 1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1 
                               0/ 100 =  0%   |
 2   66ms     4/ 100 =  4%     4/ 100 =  4%  195.114.190.150 
                               0/ 100 =  0%   |
 3   68ms     4/ 100 =  4%     4/ 100 =  4%  83.238.250.38 
                               0/ 100 =  0%   |
 4   70ms     0/ 100 =  0%     0/ 100 =  0%  83.238.251.166 
                               3/ 100 =  3%   |
 5   70ms     3/ 100 =  3%     0/ 100 =  0%  83.238.251.99 
                               0/ 100 =  0%   |
 6   83ms     4/ 100 =  4%     1/ 100 =  1%  141.136.97.105 

 

Do pierwszego węzła Netii jest już 66 ms i dosyć znaczne straty pakietów. Podstawa do zgłoszenia usterki na pewno jest.

 

Chciałbym zobaczyć parametry ADSL z modemu.

[wieslaw531]

Chciałbym zobaczyć parametry ADSL z modemu.

Obecnie:

Napisz co konkretnie.

Czy o to chodzi?

[DawidS28]

Tak, dokładnie o to. Kilka rzeczy, które zwraca moją uwagę.

 

Masz niskie tłumienie. Przy 16 dB, to powinno 15 Mb/s iść, a nie tyle, co tu widzimy. Synchronizuje się na 6,5 Mb/s, faktycznie wyciąga jakieś 30% tego, czyli bardzo słabo. Co zresztą pokrywa się z resztą parametrów. SNR Margin w okolicach 6 dB, co zupełnie nie pasuje do tego tłumienia i wskazuje na niski SNR (czyli obrazowo powierzchnię przekroju poprzecznego rury, którą płyną dane). Często przy niskiej odległości od centralek moc nadawania jest zaniżana, żeby nie zakłócać sąsiednich linii, co objawia się spadkiem SNR Margin, ale nie zbija się zazwyczaj aż do takich wartości. A tutaj wcale nie jest blisko centralki (sądząc po tłumieniu, to ponad kilometr), a dodatkowo widać bardzo dużo błędów CRC (RS uncorrectable errors) i FEC (RS correctable errors).

 

Duży ping pochodzi po części z tego, że jest włączona korekcja błędów dla downstream. Widać to chociażby po Interleaver depth i Delay, a także tym, że wykrywane są błędy FEC. W brak błędów dla upstream nie wierzę, prędzej w to, że router nie umie ich liczyć. Przy takim SNR Marginie nie uwierzę, że cała komunikacja idzie zupełnie bez błędów. Swoją drogą, widać tutaj nieścisłość parametrów, bo masz Type: Fast, a jednocześnie Interleaver depth: 4 (Fast determinuje 1). Gdyby to był Fast, to błędów FEC by faktycznie nie było, bo nie miałoby co ich wykrywać.

 

A drugim głównym powodem dużego pingu jest ilość retransmisji danych, jakie muszą być wykonywane, ponieważ pojawiają się problemy z łączem.

 

Problem gdzieś między centralką dostawcy kilometr dalej a modemem. Ciężko odpowiedzieć, co dokładnie, stawiam na jakiś kabelek. W infrastrukturze dostawcy, ewentualnie Twojej instalacji.

[wieslaw531]

Dawid

Mam około 1,5 km do centralki.

Ale jest coś znacznie ważniejszego. Zobacz na obrazek poniżej:

 

O co tu chodzi? Nigdy takich systuacji nie miałem. INFEKCJA ROUTERA?

[DawidS28]

Adres 83.27.227.122 to ja. Przepraszam.

 

Chciałem sprawdzić ścieżkę do Ciebie i przy okazji gdzie giną pakiety. Jak widać, Twój router mnie zablokował.

[wieslaw531]

Ulżyło mi. Mam takich blokad multum.

Sprawdzałem adresy i głównie to skośnoocy.

 

Kable u siebie - od puszki na ścianie zewnętrznej przez gniazda pośrednie sprawdzone. Mikrofiltr na telefonie wymieniony.

Czy mogę w jakiś sposób wykonać log stanu łącza w czasie tak aby przy reklamacji podeprzeć się danymi przesyłając stosowny mail z wynikami?

 

BTW

Poszły maile w temacie zapotrzebowania na praktyki i wolontariat.

Zapotrzebowanie powinno pojawić się na stronie.

Wiesz o co chodzi.

[DawidS28]

Ulżyło mi. Mam takich blokad multum.

Sprawdzałem adresy i głównie to skośnoocy.

 

Ja też mam wiele połączeń z Kazachstanu i Chin. Normalne. Zwłaszcza, że Twój router jest nieco nadgorliwy i odrzuca nawet zwykły ping, który bardzo często stosuje się do wykrywania topologii sieci.

 

Czy mogę w jakiś sposób wykonać log stanu łącza w czasie tak aby przy reklamacji podeprzeć się danymi przesyłając stosowny mail z wynikami?

 

Nie wiem, jaki to router.

 

Najprościej programem DSL Modem Tool albo bezpośrednio przez telnet. Poniżej lista modemów, do których można się prosto dobrać przez DMT:

http://dmt.mhilfe.de/

 

Z góry przepraszam za język. Ja mam od dawna uraz do niemieckiego.

[wieslaw531]

Modem to: D-Link DSL-2740B Rev. C2. Najnowszy Firmware.

Którą wersję pobrać i jak użyć DMT. Przepraszam ale nie bawię się w tego typu narzędzia chociaż Twoja wiedza o mnie sugerowałaby coś innego.

Tam działają całkowicie inne zasady.

[DawidS28]

Podałem link, bo tam jest kilkanaście wersji przygotowanych pod różne modemy. Akurat żadnego D-Linka tam nie ma. Teraz pytanie: możesz się z nim połączyć po telnet?

 

Przydałoby się sprawdzić otwarte porty na modemie.

 

Zainstaluj WinPcap:

http://www.winpcap.org/

 

Potem pobierz to, wrzuć w jakieś miejsce, z którego będziesz mógł łatwo z CMD korzystać, ponieważ może kiedyś się przydać, to polecam Windows\System32, nie trzeba będzie za każdym razem ścieżki wpisywać: http://netdiag.pl/programs/tracetcp.exe

 

Potem otwórz Wiersz poleceń, wpisz komendę tracetcp 192.168.1.1 -t 20 -s 1 65535 > C:\cmd_log.txt i po kilku minutach, jak się wykona, to type C:\cmd_log.txt | find "OPEN" > C:\cmd_log_filtered.txt i poproszę C:\cmd_log_filtered.txt jako załącznik.

[wieslaw531]

1. Tracerpt.exe a nie tracetcp

2. Pierwsza komenda daje taki wynik:

Argument t jest nieznany.

Argument 20 jest nieznany.

Argument s jest nieznany.

Argument 1 jest nieznany.

Argument 65535 jest nieznany.

 

BˆĄd:

Parametr jest niepoprawny.

Albo coś źle robię.

[DawidS28]

Nie, to ma być ten zewnętrzny programik o nazwie tracetcp.

[wieslaw531]

Coś jest nie tak. Plik o wadze 0 b.

Ale instalacja softu w logu ma to:

WinPcap 4.1.0.2001 Installation LOG

-----------------------------------------------------

Debug Information

 

Operating system detected on registry: 7 - AMD64

True operating system (kernel.dll): 7 - AMD64

npptools.dll present on the system: false

netnm.inf present on the system: false

nmnt.sys present on the system: false

End of log

[DawidS28]

U mnie pobiera się poprawnie. Tutaj alternatywne źródło:

http://sourceforge.net/projects/tracetcp/files/tracetcp/tracetcp-0.99.4beta/tracetcp-0.99.4beta.zip/download

[wieslaw531]

To identyczny plik. Porównałem wg zawartości. Po instalacji WinPcap (Start przy starcie Win) + restart.

Zwróć uwagę na log instalacji WinPcap z poprzedniego posta.

Wynik komendy pierwszej : ARP::whoHas: no response.

[DawidS28]

Ciekawe...

Spróbuj podstawić za 192.168.1.1 adres 213.238.76.5. Nie mam pojęcia, czemu nie znajduje adresu MAC na podstawie IP w sieci lokalnej. Jeżeli to nie zadziała, przyjrzę się temu bliżej.

 

Dobra, wiem, o co chodzi. WinPcap nie radzi sobie z pewną grupą kart bezprzewodowych. Możesz to zrobić po kabelku?

 

http://www.winpcap.org/misc/faq.htm#Q-16

 

Tylko tutaj mamy przewodową.

[wieslaw531]

Zrobione i proszę:

[213.238.76.5:21] 128 Dest. in 1 ms. Port OPEN on 213.238.76.5

[213.238.76.5:22] 128 Dest. in 1 ms. Port OPEN on 213.238.76.5

[213.238.76.5:23] 128 Dest. in 1 ms. Port OPEN on 213.238.76.5

[213.238.76.5:80] 128 Dest. in 1 ms. Port OPEN on 213.238.76.5

[213.238.76.5:1028] 128 Dest. in 1 ms. Port OPEN on 213.238.76.5

[DawidS28]

Pobierz PuTTY:

http://tartarus.org/~simon/putty-snapshots/x86/putty.exe

 

Wprowadź adres IP 192.168.1.1 i Connection type na SSH. Spróbuj się połączyć, podając login i hasło ze strony konfiguracyjnej routera.

 

Jeżeli to nic nie da, to zamiast SSH wybierz Telnet.

[wieslaw531]

Zrobione. Co dalej?

[DawidS28]

Pobierz, uruchom:

http://www.2cent.de/dmt/v8/dmt.zip

 

Podaj adres IP (192.168.1.1), port (21), login i hasło i spróbuj się połączyć. Jak się uda, to poproszę screen.

[wieslaw531]

Can not identify modem type.

 

Niunia mnie przegania od kompa obok wyra. Na dzisiaj niestety muszę spadać.

Dobranoc.

[DawidS28]

No to teraz się zacznie zabawa w zgadywanie poleceń, które można wydawać modemowi po SSH/Telnet. Gdzieś powinien się kryć log, zgaduję, że pod jakimś parametrem polecenia adslctl (może adslctl stats), help powinno zwrócić dostępne komendy.

[wieslaw531]

Telnet nie występuje na W7 x64.

 

Dzisiejsza sytuacja:

 

A może powodem jest wąskie gardło u operatora z powodu wzrostu ilości userów.

[DawidS28]

To wygląda zdecydowanie lepiej. Synchronizacja na pełne 10 Mb/s dla downstream. Dla upstream 1192 kb/s, czyli normalna przy tej opcji i takiej odległości (1312 kb/s widziałem może 5 razy w życiu, a modem znajdował się prawie na centralce). Znikoma ilość błędów, te 1108 FEC to prawie nic. Spadł Interleave delay z 16 ms do 8 ms, czyli pingi także powinny spaść o około 10 ms.

 

Zamiast READSL (stosowanego na słabszych i dłuższych, o wiele dłuższych łączach), uaktywniło się ADSL2+, zapewniające przy takim tłumieniu najwyższą wydajność. Wystarczający zapas na SNR Margin (11 dB), o ile parametr nie będzie się wiele chwiał.

 

Wnioski: wczoraj obserwowaliśmy fizyczny problem z linią, ewentualnie samą centralką. Wąskie gardło nie ma tu wiele do rzeczy, problem występowałby przy połączeniu między centralką a siecią operatora, a nie do samej centralki. Wzrost liczby użytkowników może wpływać na zwiększenie zakłóceń na linii, ale według mnie nie w aż takim stopniu, chyba, że Netia korzysta z uszkodzonego kabla telefonicznego, albo masz rozparowaną linię, wtedy faktycznie przy zwiększonym użyciu sąsiednich łącz pojawiają się takie dziwy.

 

Telnet nie występuje na W7 x64.

 

Domyślnie nie. Można go sobie doinstalować jako funkcję Windows. Ale nie warto, PuTTY jest zdecydowanie lepszym klientem Telnet.

 

Spróbuj jeszcze skorzystać z programu RouterStats (podobno wspiera Twojego D-Linka):

http://www.vwlowen.co.uk/internet/files.htm

[wieslaw531]

Niestety ten soft wywala błąd połączenia. Wpisywałem właściwe dane połaczenia. Czasem jest komunikat o przepełnienu stosu.

Bardzo możliwe, że mimo iż teoretycznie soft obsługuje mój router to problem może być w wersji firmware.

Wystarczy mi Twoja interpretacja pokazanych statusów i będę składał reklamację. Wiem już na co zwrócić uwagę.

Testuję co pewien czas stan łącza przez tester.netia.pl i oczywiście wyniki są różne.

Ping zmienia się od 25 do prawie 100 ms i automatycznie transfer jest do bani.

Sprawdziłem i podmieniałem kable do routera - bez widocznych zmian. Był też reset routera.

 

Reklamacja złożona.

 

Odpowidź SMS z Działu technicznego:

"Kłopoty z transferem wynikają z przeciążonej centrali. termin rozbudowy centrali w trakcie ustalania."

 

Myślę, że spokojnie możesz temat zamknąć. Jeżeli nawet ustalą termin to jeszcze jest problem kiedy to zrobią fizycznie.

Edytowane 4 Marca 2013 przez wieslaw531