Użytkownik "PM" <pm@xx.xx> napisał w wiadomości
news:n9f8iv$2nrh$2@adenine.netfront.net...
Rozumiem... to próbuj go po prostu przekręcać na stole, przenosić w
różne miejsca, itd, żeby znacząco zmieniał pozycję.
To już było robione, bo najpierw pomyślałem że może być właśnie problem w
"nakładaniu się" fali.
Może być, acz coraz bardziej skłaniam się ku problemom w warstwie logicznej,
zaraz to objaśnię.
A spróbuj je (lapy) zamienić miejscami, lub wstaw repeater między AP a
drugiego...?
Taka kombinacja działa, jak wyżej. Problem jest tylko wtedy kiedy oba
kompy pracują z tym samym AP, jeżeli są wpięte do różnych działa bez
problemowo.
Czyli potwierdza się problem w części radiowej, jednakże jak wspomniałem,
coraz bardziej prawdopodobna wydaje mi się zbyt agresywna logika, acz nie
jako wyłączny powód.
Dla testów jeden z nich wyłączałem i też nie bangla. Odległość niema
znaczenia - czy są metr od siebie, czy 8 to i tak się wlecze.
Wietrzę tu problem logiczny, powiązany z warstwą fizyczną. Być może,
podkreślam _być_może_, któryś z odbiorników, załącza się po nadawaniu ze
zbyt dużą zwłoką, podejrzewam AP, przez co po nadawaniu, nie rejestruje
potwierdzenia transmisji, AP, nie odebrawszy go zapytuje +- "gdzie stoimy?",
komputer odpowiada, dopiero wtedy potwierdzenie dociera i transmisja idzie
dalej. Czekanie na potwierdzenie, ponowna emisja tegoż, trochę trwa.
Za cholerę nie mogę sobie przypomnieć, jak kiedyś ustawialiśmy w firmie
tak że sprzęt gadał ze sobą, bez pośrednictwa Apka i to na pełnej
prędkości, a nie 1/3 tak jak tutaj.
Przypuszczam, że chodziło o tryb ad-hoc i można było na sztywno spiąć
komputery.
To wygląda tak jakby sprzęt nie umiał się łączyć z dwoma urządzeniami
równocześnie. Wiem jak to brzmi, ale chyba rozumiesz o co mi chodzi ;)
Wiem, spoko. Acz pewności co do diagnozy nie mam, gdybam jedynie, ale na
podstawie kilkuletnich obserwacji urządzeń posługujących się protokołem
AX25. 15 lat temu , gdybyś miał taki zestaw, kroczek po kroczku bym ci wrecz
podyktował, co i jak ustawić.
AP (i repeater)pracuje na 13, bo ten jest w miarę czysty(do okoła
jakieś 15-20 innych sieci).
U mnie właśnie 13 jest problematyczny... Idzie, ale ma tendencję do
rwania, mimo, iż router w trybie werwisowym zeznaje, że kanał jest
względnie czysty, a inne są severed, dokładniej, pokazuje ilość
interferencji. Wymuszenie na czwórkę w miarę poprawia sytuację.
Hmm, to muszę sprawdzić :)
Sprawdź! I miej też na uwadze, że niekoniecznie tam najlepiej, gdzie pusto.
Też myślałem że może apek gubi kompa, ale w takim razie czemu gubi tylko
kompa, a nie drugiego ap, dlatego wykluczyłem taką możliwość, a może
jednak...
Jak pisałem, zapewne tu mamy inną agresywność radia, inne zależności
czasowe, być może lepsze buforowanie ramek (o, tu znów kolejna możliwa
przyczyna, że transmisja idzie, jak krew z nosa - też wyczajona z AX25, więc
znów mamy gdybanie). Za początków Packet Radio, mało który komputer miał
dostęp do dysku z użyciem DMA, co w naszej historii jest niezwykle istotne.
Mało też który z operatorów, miał klasycny modem TNC, z własną logiką.
Posługiwali się więc modemem typu BayCom, gdzie konstrukcja urządzenia była
maksymalnie uproszczona - połączenie przez RS, z niemal dokładnie wprost
kluczowaniem generatora 1200/2200 Hz (jakoś tak), z prędkością 1200 bps. Aby
zapewnić połączeniu logikę, stosowane były programowe sterowniki, udające
TNC na Baycomach. Problem powstawał taki, że każdy dostęp do dysku
wstrzymywał kluczowanie generatora, przez co nadawana ramka była totalnie
zniekształcona, przy pełnej długości, emisja jednej trwała ok. 2 sekund (256
bajtów), zwykle uszkadzana była ramka druga, emitowane było 7 ramek, tyle
przewiduje specyfikacja AX25. Nie to najgorsze, że niektórzy mieli zbyt
agresywnie ustawioną odpowiedź i po odebraniu paczki potwierdzana była każda
z ramek, mimo, ze w zupełności wystarczyło potwierdzić ostatnią, to tez było
w protokole. I teraz, gdy ktoś miał włączone buforowanie ramek, co
oznaczało, że skoro odebrał wszystkie dobre, wystarczyło mu ponownie wysłać
tylko tę uszkodzoną i już można było iść dalej, bez powtarzania ramek już
odebranych. Szczęśliwie, pierwsza ramka nie była uszkadzana. Jeśli ktoś miał
buforowanie wyłączone, to po odebraniu ponownie wysłanej ramki uszkodzonej,
tym razem już prawidłowej, żądał ponownego wysłania ramek, które już zostały
odebrane, co łatwo oszacować, że przepływność takiej transmisji malała
średnio 5-krotnie,. tragedia... Nie wiem, jakim cudem, mój Commodore 64,
mając własny modem i program do Packet-Radio, z także własnym, programowym
TNC, takie uszkodzone ramki odbierał bez kłopotu, rzadko się zdarzało, by i
on nie dał rady. Zdarzało się więc, że koledzy z problemem uszkadzanych
ramek korzystali z mojego komputera jako węzła/powtarzacza, co wbrew
pozorom, potrafiło znacznie przyspieszyć transfer! A to wszystko "umiał"
jednomegowy procek i 64 KB pamięci.
Chyba będzie trzeba posłuchać co hula w sieci.
Popieram. Sam też jestem mocno ciekaw, na ile moje gdybania, oparte na
kilkuletnich doświadczeniach z Packet-Radio, mogą pomóc przy rozwiązywaniu
problemu.
pomocnym rozwiązaniem byłoby zastosowanie, znanego z AX25, protokołu
DAMA, gdzie węzeł jest guru i mastaha, i bez jego pozwoleństwa, stacje
podrzędne, nawet nie prykną.
Co ja bym dał za takie posłuszeństwo sprzętu :)
Zastanawiam się, czy we właściwościach routera wifi nie ma takiej opcji...?
Muszę ze swoim zobaczyc, mam momenty, że też by mi się przydało. Tylko by
coś takiego mogło uziemić nadawanie wszystkich okolicznych stacji, taka jest
właściwość tego protokołu. Jego zadaniem jest zminimalizowanie konfliktów
transmisji w sytuacji, gdy poszczególne stacje się nie słyszą i na węźle w
nieskończoność zagłuszały by się, przez co transmisja niemalże nie ma szans
zaistnieć. Stale latały by tylko żądania powtórek, podtrzymania (są
krótkie), oraz nieskuteczne powtórki, bo już są dłuższe. Węzeł, przejmując
nadzór, wyznacza stacje do nadawania, sygnując pakiet dodatkowym
znacznikiem, tak to w uproszczeniu wygląda, tyle po 15 latach pamiętam :)
(no, trochę więcej, ale nie miejsce teraz na to) I wtedy nawet, gdy łącze
jest słabe, to w sytuacji, gdy stacje się nie zagłuszają, jest spora szansa,
że szybko przejdzie, co ma przejść. Spowalnia to nieco transmisję, ale i ją
porządkuje, przez co idzie ona szybciej. OIDP, to jest 10-20%, na tyle
oszacowałem. No, ale pogorszyć transfer o 10-20%, a pogorszyć o 60, to
"prawie robi wielką różnicę".
Na próbę, odpaliłbym jakiegoś Linuxa live i zobaczył, jak w podobnej
sytuacji pod nim, czy też tak powoli.
Zobaczę jeszcze na Linuxie, ale podejrzewam że będzie podobnie.
Porównanie zachowań w obu przypadkach pozwoli oszacować, gdzie dokładniej
jest źródło problemu. Jak wspominałem, najprawdopodobniejszy wydaje mi się
AP, ale kart w lapach też nie wykluczam. Gdyby się udało wziąć jeszcze
innego AP i spróbować? A jak chcesz lapy ze sobą, to w trybie ad-hoc. Tylko
tu chyba musisz ręcznie rzeźbić adresy, nie robiłem tego, nie było potrzeby.
Ewentualnie, WiFi direct, obecne w smartfonach.
--
To nie wstyd być biedakiem, ale, żeby to był zaszczyt,
to ja tego też nie powiem!
(C) Tewje do Pana Boga.
|