Atlantis napisał:

>> Zastanawiam się obecne błędy w teście z pingami nie mają jakiejś innej
>> przycyzny. Widzę chociażby, że dość często pojawia się błąd przy
>> rozmiarze 1453.
>
> Ok. Okazuje się, że to także nie jest już problemem. Nie zauważyłem,
> że nie podmieniłem adresu IP w skrypcie do testu z pingami i testowałem
> pingując serwer w publicznym internecie.

Jak przeczytałem poprzednie, popadłem w zadumę. Bo liczby 1452/1453 brzmią
mi znajomo. Ale nijak się mają do pingowania komputerka leżącego na stole.
No niec, wyjaśniło się.

> Trochę zastanawia mnie dlaczego płytka nie chce się synchronizować w
> trybie 100 Mbps z tanim switchem Fast Ethernet, ale już z gigabitowym
> nie ma problemu. No cóż... Mogę z tym żyć. :)

Może w tanim switchu siakiś kwarc też taki nie taki? Też tani.

--
Jarek

do góry

On Thu, 29 Feb 2024 21:28:04 +0100, Atlantis wrote:
> Jak wspominałem w poprzednich wiadomościach, zabrałem się ostatnio za
> uruchamianie "antycznego" linuksowego komputerka SBC (jeszcze sprzed
> czasów Raspberry Pi) Sarge-at91. Polska konstrukcja na AT91RM9200,
> działająca pod kontrolą Linuksa Angstrom. Mam dwa egzemplarze - jeden
> złożony i uruchomiony, w drugim brakuje jeszcze kilku elementów.
>
> Ostatnio podczas eksperymentów natknąłem się na ciekawą przypadłość. Za
> nic nie byłem w stanie połączyć się z płytką za pomocą SSH. Proces
> łączenia utyka na "expecting SSH2_MSG_KEX_DH_GEX_REPLY".
> Początkowo chciałem to zrzucić na niekompatybilność pomiędzy zabytkowym
> serwerem SSH na płytce, a współczesnym klientem. Googlując trafiłem
> jednak na informację, że lekarstwem na podobną przypadłość (na zupełnie
> innym sprzęcie) okazywała się zmiana parametru MTU na interfejsie
> sieciowym serwera na mniejszą wartość. Faktycznie pomogło - zmiana MTU z
> 1500 na 567 umożliwiła zestawienie połączenia SSH. Wydaje mi się to
> jednak dziwne, bo 1500 jest prawidłową wartością dla Ethernetu.

Ale moze nieprawidłową dla tego procesora/software'u.

Jesli ma krótszy bufor, to gdzies moze zachodzic dzielenie
pakietów/negocjacja MTU i może być skopane.

> Zwyczajnie zaintrygowało mnie dziwne zachowanie interfejsu sieciowego.
> Łączy się, pobiera adres z DHCP, można przesyłać dane, odpowiedzi na
> pingi przychodzą w obydwie strony, ale SSH się wywala o ile nie
> zmniejszę MTU...

a probowales pingi dlugimi pakietami?

J.

do góry

On Sun, 3 Mar 2024 13:56:07 +0100, Jarosław Sokołowski wrote:
> Atlantis pisze:
>>> A kwarc od ethernetu pracuje na takim f jakie ma na obudowie?
>>
>> Podpiąłem oscyloskop. Nie udało mi się zmierzyć częstotliwości na
>> kwarcu, ale na pinie rx_clk mam 2,50557 MHz (zgodnie z dokumentacją
>> dla 10Mbps powinno być 2,5 MHz). Czy ta odchyłka może powodować
>> problemy z przesyłaniem większych pakietów?
>
> Różnica około dwóch promili. Bez wdawania się w szczegóły działania
> ethernetu, można zauważyć, że jak trybiki jednego kółka w przekładni
> zębatej będą węższe o dwa promile, to na długości pięciuset ząbków
> nastąpi przesunięcie o jeden. Zdaje się, że przy MTU koło 500 coś
> się zaczyna rypać.

Bajtów. 4 tys bitów.

Wątpie, aby to miało znaczenie. generatory po dwóch stronach nigdy nie
będą zgodne, więc ethernet musi miec jakis mechanizm do
synchronizacji.

W UART np do RS232 wiadomo jak to jest zrobione, ale tu musi być jakos
inaczej.

No ale Atlantis pisze, ze pomogło.
Czyzby rzeczywiscie jakis problem z trybikami?
I to na bajtowym poziomie?

P.S. Z trybikami problemu nie będzie - dostosują się, bo styk krótki.
Ale juz dwie długie zębatki miałyby problem.

Kiedys w socjalizmie/komunie były złącza krawędziowe o słusznym
rozstawie 2.50 mm, nie bedzie Zachód pluł nam w twarz ...

J.

do góry