abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 0
včera 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 16
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 2
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 767 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Prehazene a duplicitni odezvy z pingu

24.6.2013 11:33 Bill Gates
Prehazene a duplicitni odezvy z pingu
Přečteno: 803×
Zdravím, předně se omlouvám, možná je toto téma špatně zařazeno, nicméně nebyla by tu dobrá kromě ostatních poraden také "Síťová poradna"? Zde by se mohly řešit problémy týkající se sítí a vůbec komunikace? Jen návrh.

Nicméně zpět k problému. Může mi prosím někdo popsat jak je možné že dochází k následujícímu jevu duplicitních a přeházených odezev z pingu? Stalo se mi to nedávno u jednoho poskytovatele internetu, kterému už asi týden vypadává net, stále si ale nejsem jist, zdali je problém u mě a nebo mimo mou domácí síť a tak hledám, zkouším.

Narazil jsem na následující problém u pingu:
[10:09:42]-[/usr/bin]
[root@ntb]# ping seznam.cz
PING seznam.cz (77.75.72.3) 56(84) bytes of data.
64 bytes from 77.75.72.3: icmp_req=2 ttl=245 time=674 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=1 ttl=245 time=14159 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=3 ttl=245 time=3622 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=4 ttl=245 time=2530 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=6 ttl=245 time=9837 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=5 ttl=245 time=13102 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=7 ttl=245 time=14184 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=7 ttl=245 time=17390 ms (DUP!)
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=15 ttl=245 time=11620 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=13 ttl=245 time=14350 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=12 ttl=245 time=16774 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=17 ttl=245 time=13375 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=18 ttl=245 time=12574 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=20 ttl=245 time=10851 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=21 ttl=245 time=9920 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=11 ttl=245 time=20012 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=24 ttl=245 time=7462 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=26 ttl=245 time=6189 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=19 ttl=245 time=13645 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=14 ttl=245 time=18680 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=16 ttl=245 time=17135 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=25 ttl=245 time=8277 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=30 ttl=245 time=4021 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=10 ttl=245 time=24395 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=32 ttl=245 time=3543 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=29 ttl=245 time=7813 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=8 ttl=245 time=28966 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=22 ttl=245 time=15267 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=28 ttl=245 time=10120 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=27 ttl=245 time=13552 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=23 ttl=245 time=18216 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=31 ttl=245 time=11875 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=35 ttl=245 time=12881 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=36 ttl=245 time=12319 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=37 ttl=245 time=12975 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=39 ttl=245 time=11405 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=39 ttl=245 time=11514 ms (DUP!)
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=38 ttl=245 time=13337 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=34 ttl=245 time=17351 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=33 ttl=245 time=18356 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=43 ttl=245 time=8616 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=41 ttl=245 time=10810 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=42 ttl=245 time=9984 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=47 ttl=245 time=5641 ms
64 bytes from www.seznam.cz (77.75.72.3): icmp_req=44 ttl=245 time=8918 ms
a) horzné odezvy

b) ztrátovost paketů

c) přeházené odezvy (to by se možná dalo pochopit i když považuji to za bordel)

d) duplicitní odezvy (nechápu)

Tohle jsem viděl v momentě kdy providerovi asi týden blbnul net. Mezi mou wifi a AP providera signál naprosto v pohodě, ale jeho AP mě sem tam odhlašovalo a znovu přihlašovalo na POE, některé jeho AP občas mizely a zase se objevovaly (restarty AP?). Střídal jsem několik providerových AP ve vzdálenosti od 2 do 12km, problém se projevoval na všech jeho AP i když signál na všechny AP mám relativně dobrý.

Dnes se mi ale zdá, že se to vrátilo do normálu a jede to stabilně, poznám to protože poslouchám jeden internetový stream a minulý týden to byla katastrofa, jak odezvy webu, tak přerušování streamu, který nestíhal bufferovat a ani tunelování VPNkou na jiný můj server a tím jiného providera si s tím neporadilo. Dneska od rána bez výpadku. Možná právě provider něco řešil a blbla mu chvíli infrastruktura, nevím, hádám.

Kde taková věc - viz ping výše může vzniknout? Setkal se někdo někdy s něčím podobným a zjistilo se co je příčinou?

Dík za informace a názory.

Odpovědi

24.6.2013 12:24 NN
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
smycka ve smerovani, HW problemy etc.
26.6.2013 16:48 Bill Gates
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Provider odpovedel ze pry je to asi problem se signalem moji wifi.

Dalsi zajimavy ping ze vcerejska:
[root@ntb]# ping seznam.cz
PING seznam.cz (77.75.76.3) 56(84) bytes of data.
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=3 ttl=245 time=12.4 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=12.9 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=23.0 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=245 time=128 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=9.44 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=128 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=245 time=240 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=11 ttl=245 time=276 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=11 ttl=245 time=283 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=7.68 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=23.0 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=13 ttl=245 time=126 ms (DUP!)
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=14 ttl=245 time=7.06 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=16 ttl=245 time=9.16 ms
64 bytes from www.seznam.cz (77.75.76.3): icmp_req=17 ttl=245 time=9.19 ms
^C
--- seznam.cz ping statistics ---
22 packets transmitted, 8 received, +7 duplicates, 63% packet loss, time 25616ms
rtt min/avg/max/mdev = 7.065/86.609/283.238/101.122 ms
Muj signal na jeden 11km vzdaleny AP providera:

Signal strength: -75 dBm

Noise floor: -89 dBm

Transmit CCQ: 90.2%

TX/RX Rate: 9.0 Mbps / 12.0 Mbps

Muj signal na druhy 3km vzdaleny AP toho sameho providera:

Signal strength: -72 dBm

Noise floor: -90 dBm

Transmit CCQ: 93.8%

TX/RX Rate: 24.0 Mbps / 18.0 Mbps

Je to spatny nebo dobry signal?

26.6.2013 17:43 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Niektore pakety sa musia opakovat a caka sa na ich potvrdenie, preto mozu dorazit v inom poradi. Je to normalny prejav zarusenej linky, pricom vzdialenost nehra az taku dolezitu ulohu. Ved to mozes vidiet sam. Doporucoval by som pripojit sa na take AP, kde budes dosahovat lepsie CCQ pri downloade. Meranie CCQ, ked sa nic neprenasa, alebo len sem-tam nejaky ping nema prave velku vypovedaciu hodnotu.
26.6.2013 18:43 Bill Gates
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
To CCQ ktere uvadim je pri zatezi kolem 300kbytes/s download neboli asi 2.5mbps. Stahovan byl v tom momente gparted.iso odsud (139.5 MB).

Chapu to spravne ze mnou uvadene CCQ je hodne dobre? To znamena cim vyssi hodnota tim lepsi ?
26.6.2013 19:06 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Cim vyssie CCQ tym by to malo chodit lepsie. Bohuzial toto je len nejake meranie tvojeho klienta. Pre posudenie, kde moze byt problem by bolo potrebne mat k dispozicii meranie z obidvoch stran v rovnakom case. Take nieco dokaze robit provider. Mozno preto to vyhodnotil ako problem u teba. Blizsie sa k tomu neda povedat o moc viac, pretoze ak pouzivas 2.4G wifi klienta a mas ho napojeneho na svoje domace wifi, ktore je tiez 2.4G, tak sa mozes spolahlivo zarusit sam. Je to celkom dost casty pripad, zvlast ak sa pouzije domace wifi na 40MHz. Treba brat do uvahy, ze rusi nielen domaci router, ale aj pocitace nanho napojene. Antena, ktora je na streche ti spolahlivo chyti vysielania aj z domacich pocitacov a routra. Pravdepodobne pouzivas 24dBi antenu. Ak ano, tak signal z druheho AP by si mal mat aspon o 10dB lepsi, pokial to druhe AP nema nahodou opacne otocenu antenu.
26.6.2013 19:49 Bill Gates
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Wifi je Ubiquity AirGrid M5-HP, tedy na 5ghz, odtud kabelem do switche a odtud kabely do konkretnich PC. Kolik dBi ma moje antena to nevim, ale dostal jsem to jako original k ubiquity a je to velke sito.
26.6.2013 22:47 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
ta kilometráž je strašná. Pokud je to AP, které má mnoho klientů, tak je to neuvěřitelný bordel. Kdysi dávno, když byl Ethernet na sběrnici a koaxu nebo později na UTP a na HUBech platilo, že síť může být maximálně tak veliká, aby i nejmenší paket (84 oktetů) byl dostatečně velký na to, aby jeho čelo při vysílání dosáhlo i nejvzdálenější systém dříve než vysílání skončí. Pak byl v celé síti jen jeden paket a pomocí CDMA/CD se řešilo, kdy mohu vysílat a jak poznám, když vyrobím kolizi.

Vzduch (nebo vysílací pásmo) je v podstatě taková sběrnice o kterou se všichni perou. Jenže nejsem na ni schopen poslouchat, když vysílám a navíc jednotlivé stanice nejsou schopny slyšet mnohdy jedna druhou. Takže začnou vysílat, když si naměří, že kanál je volný, ale to klidně může být situace, že jiná stanice z druhé strany vysílá. Zvláště v takovýchto kilometrech. Nebo řekněme v případě stanice 3 km vzdálené, tak začne vysílat stanice a 5 us po ní začne vysílat AP protože si také změří, že kanál je volný (čelo vlny dorazí až za 10 us). Mnoho stanic na obrovských vzdálenostech může vyrobit obrovské množství kolizí protože nejsou schopni se zasynchronizovat. A pak si dokážu představit, že 90% času je kolizní stav a jen 10% užitečný datový přenos. A ty duplicity jsou znovu vyslání paketu, který měl kolizi (z pohledu AP) nicméně vám dorazil dobře, protože ostatní signály, které u AP s ním iterferovaly, se vzdáleností (a směrovostí antény) zaslábly.

Pokud je to pro vás jediná možnost připojení, zkusil bych se z poskytovatelem domluvit a instaloval si u něj druhé vlastní Ubiquity a udělal si spojení bod-bod.
27.6.2013 10:36 Jan Kratochvíl | skóre: 12
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
perfektní vysvětlení....
27.6.2013 14:07 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Kazdy vysielany ramec nesie v sebe informaciu o dlzke vysielania a stanice ktore su v dosahu si podla toho nastavia sietovy vektor. Problem je vsak so stanicami, ktore niesu z nejakeho dovodu v dosahu (napriklad su odtienene smerovymi antenami). Znamejsie je to pod oznacenim problem skryteho uzla.
27.6.2013 16:52 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
To jo, ale stanice 3 nebo 12 km bude skoro jistě skrytá těm dalším klientům, navíc, díky konečné rychlosti signálu a velké vzdálenosti, je zpoždění mezi zahájením vysílání a příjmu ostatními stanicemi značné a mezi tím může začít vysílat jiná stanice nebo AP.
27.6.2013 17:30 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Ak by boli pouzite na pracovnom kanali (a kanaloch susednych) len zariadenia ake ma tazatel, tak by problem skyteho uzla neexistoval. Jeho jednotka pracuje v casovej domene modulaciou TDMA, velmi podobne ako GSM, alebo WiMax. Bohuzial na 5G pasme sa pouziva mnozstvo navzajom nekompatibilnych modulacii (napriklad aj radiovy full duplex). Kazdy vyrobca si vylepsuje svoje zariadenie tak, aby to jemu islo lepsie ako konkurencii. Co na tom, ze konkurencne vyrobky sa medzi sebou nevedia dohodnut aby si neprekazali vo vysielani. Ono to potom na tom pasme aj tak vyzera.
28.6.2013 11:18 lertimir | skóre: 58 | blog: Par_slov
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
V podstatě máte pravdu. Na to, aby sdílení kanálu mnoha subjekty fungovalo i na takovýchto vzdálenostech je nutné, aby byl v provozu nějaký systém rezervace media. Třeba RTS/CTS pro všechny stanice, nebo TDMA. Pomocí malých paketů se dohodne, kdo bude vysílat, zde je pravděpodobnost kolize významně menší a když nastane tak nevadí. A datový paket je pak vysílán už na rezervované médium s větší jistotou, že kolize nenastane. (No druhý důvod špatného příjmu v případě tazetele je síla signálu a rušení. To má tazatel dost na hraně.)
28.6.2013 12:57 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
RTS/CTS (rovnako ako CF-Poll/CF-ACK) je metoda pristupu na vyssej vrstve, alebo dalo by sa povedat aj s mensou prioritou. Okrem toho musia byt stanice (ruseny a rusiaci) na rovnakom kanali. Rozpoznane ramce z prilahlych kanalov ovladac karty zvycajne zahadzuje. V pripade interferencie bude ramec dropnuty uz priamo firmwarom karty, pretoze nemusi prejst crc kontrolou. Ovladac si v takomto pripade nenastavi NAV (network alocation vector), tudiz vysielanie nebude odlozene. Problem s NAV je tiez v pripade pouzitia modulacie, ktoru prijimac neovlada. Napriklad jednotky 802.11a nerozpoznaju vysielania v modulacii DSSS, alebo 802.11n v mode GF (green field). Existuje este nizkourovovejsia metoda pristupu na medium pod nazvomm CCA (Clear Channel Assessment), ktora je zalozena na principe merania energie. Specifikacia 802.11 blokuje (odlozi) vysielanie ak je energia na kanali vyssia ako -80dBm pre TXPower > 100mW. Bohuzial CCA modul ma viac modov v ktorom sa kombinuje este energia kanalu s detekciou nosnej, pretoze detekovat len energiu by zapricinilo v urcitych pripadoch takmer aj nemoznost komunikovat. Napriklad vyzarovanie z MW, alebo inych radiovych zdrojov (nie wifi) by moholo podstatne znemoznit spravnu funkcnost. Prave tato detekcia nosnej zapricini zavislost na urcitej modulacii, ktora je neziaducou v pripade interferencii pri roznych modulaciach. Niektore sofistikovanejsie zariadenia (napr.Cisco) maju moznost nastavovat parametre CCA modulu, takze s takymito zariadeniami je mozne sa vyhrat do sytosti. Bezne wifi jednotky maju CCA modul nastaveny len na jeden mod zvycajne ako ED+CS (Energy detect + Carrier Sense) a neda sa to menit aj ked urcita moznost existuje. Niektore ovladace (firmware) maju moznost nastavovat tzv.citlivost (Sensitivity). V Linuxe prikazom: iwconfig wlan0 sens... Tym sa da nastavit treshold pre odmietnutie ramca a je to dost ucinna metoda v pripade interferencii z rovnakeho, alebo prilahleho kanala ak ma stanica signal z AP aspon -60dBm. Zavisi potom na SNR a kvalite ovladaca ako sa to bude spravat.
27.6.2013 13:50 gogol
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Spojenie PtP moze pomoct, ovsem iba v pripade ineho kanalu a merania zarusenia na obidvoch stranach. Ono totiz 5G pasmo nieje az take prazdne ako sa o nom hovori. Bezne na nom chodia PtP linky prevadzkovatelov, ktore spajaju pristupove body v mensich lokalitach napriklad aj na pasme 2.4G. To by este nemuselo vadit, ovsem tieto linky chodia nekompatiblne s wifi specifikaciou, Tudiz wifi klient nic nenaskenuje a pre neho sa zda, ze na tom pasme nic nieje. Velmi dobra pomocka je spektralny analyzer. Niektore Ubi jednotky ho obsahuju uz vo firmware.
27.6.2013 23:29 Igor | skóre: 8
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Zdravim, Pracujem tiez s wifi technologiami.Som tiez pripojeny cez AirGridM5HP..... Vas problem vyzera v zaruseni kanalu.

JA mam taketo statistiky:
Síla signálu: -49 dBm
Noise Floor:-95 dBm
Odchozí CCQ:100 % 
TX/RX Rate:150 Mbps / 150 Mbps
airMAX:Zapnuto
airMAX Priority:High
airMAX Quality: 99 %
airMAX Capacity: 49 %
mne to ide zruba 60-70 Mbit/s....

Na 100% je to zaruseny kanal.
Tell me again what that '-r' option to rm does...?
27.6.2013 23:35 Igor | skóre: 8
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Este som zabudol dodat:
Channel/Frequency:40 / 5200 MHz
Channel Width:40 MHz (Lower)
Vzdálenost: 1.5 miles (2.4 km)
Polarizacia: Horizontal
Tell me again what that '-r' option to rm does...?
28.6.2013 16:35 ironman
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Problem je nejspis v zarusenem prostoru. Oskenovat vzduch na kazde strane a zmenit kanal na nejmene zaruseny.
Jeste bych mel par pripominek ke zminenemu spoji presneji k jeho delce 11km?! To se nekdo asi posral ne. Jako nezlobte se na me, ale radiovy spoj na 11km v 5GHz nemuze nikdy dobre fungovat. Pokud to neni zrovna nad polem, kde neni siroko daleko zadna civilizace.
Dneska poskytuje internet kazdy Tonda (tondove prominou) z vesnice, ktery nakoupi 5GHz technologii od Ubiquiti nebo Mikrotiky. Pak to strili na desitky kilometru daleko a v konecnem zaveru se divi ze to nefunguje.
Kdyby radeji investovali ti radobi pipaci do poradne technologie na 10GHz a poskytli v destinacich kvalitni linku. Ne to chce kazdy byt nejpozdeji do mesice majitelem audin, bavoraku apod. ale kvalita poskytovanych sluzeb stoji za ho.no. Bohuzel clovek bydlici na konci sveta ma smulu. O2 jsou par.hanti, kteri za sve nesluzby chteji neslusny prachy.
28.6.2013 22:57 Bill Gates
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
Bydlim skoro na konci sveta a ten 11km spoj mi svihal na 2.5mbps vklidu a stabilne (coz me osobne tedy uplne staci), az tedy do jiste doby. Nejsem provider, jsem zakaznik providera, ktery nabizi konektivitu na svych ve zdejsim okoli umistenych AP, kdy klient si poridi vlastni technologii nebo mu provider proda nejakou vhodnou a klientova strana zustava majetkem a ve sprave klienta. Ta 11km cesta je kopec / kopec s primym vyhledem, tesne lizajici 2 mesta, ktere jsou asi odhadem 60m pod trasou kudy svisti signal. 3km spoj je na nejblizsi mesto, AP je uvnitr toho mesta.
28.6.2013 23:04 Bill Gates
Rozbalit Rozbalit vše Re: Prehazene a duplicitni odezvy z pingu
No jinak tedy doplnim, ze jsem dnes pootocil antenu na jiny AP stejneho providera (opet kopec / kopec) s primym vyhledem a tentokrat jsem na 2.3 km. Sviha to na me skromne naroky hodne v pohode. Lepe nez predtim a absolutne bez vypadku. Takze asi skutecne problem nekde ve vzduchu. Patrne problem nebyl celou tu dobu az do nedavne doby kdy se neco ve vzduchu zmenilo a bylo po srande. Vypadky patrne v momente kdyz nekdo konkretni zacal vysilat a me tak zarusil drive volny vzduch. Mozna vznikly nove vysilaci stanice a tim to cele slo do kopru. Takze zkratka jsem na jinem AP o 45 stupnu vedle a jedu.

Diky vsem za komenty, dost mi to pomohlo ve vyreseni tady te zahady a dost me to poucilo o zajimavych vecech.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.