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í
×

16.11. 23:44 | IT novinky

Společnosti Dell a Canonical společně představily 5 nových počítačů Dell Precision s předinstalovaným Ubuntu. Jedná se o 4 notebooky a 1 all-in-one počítač. Cena počítačů s Ubuntu je o 100 dolarů nižší než jejich cena s Windows 10.

Ladislav Hagara | Komentářů: 9
16.11. 22:55 | Nová verze

Po pěti měsících vývoje od vydání verze 4.8 byla vydána nová verze 4.9 svobodného open source redakčního systému WordPress. Kódové označením Tipton bylo vybráno na počest amerického jazzového muzikanta a kapelníka Billyho Tiptona.

Ladislav Hagara | Komentářů: 0
16.11. 22:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 146. brněnský sraz, který proběhne v pátek 17. listopadu od 18:00 hodin v restauraci Bogota na Nových Sadech.

Ladislav Hagara | Komentářů: 0
16.11. 21:55 | Nová verze

Dle plánu byla vydána nová verze 9.2.1 živé linuxové distribuce Slax. Novinkou je především přechod ze Slackware na Debian a z KDE na Fluxbox.

Ladislav Hagara | Komentářů: 2
15.11. 22:44 | Zajímavý projekt

Vítězným projektem letošního ročníku soutěže určené vývojářům open source hardwaru Hackaday Prize se stal podvodní kluzák (YouTube, Onshape). Cenu za nejlepší produkt získala braillská klávesnice pro chytré telefony Tipo (YouTube).

Ladislav Hagara | Komentářů: 0
15.11. 06:33 | Nová verze

Byla vydána verze 3.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Řešena je také řada bezpečnostních problémů.

Ladislav Hagara | Komentářů: 3
15.11. 00:11 | Nová verze

Byla vydána beta verze Linux Mintu 18.3 s kódovým jménem Sylvia. 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.3 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
14.11. 21:44 | Nová verze

Byla vydána verze 5.2.0 svobodného integrovaného vývojového prostředí KDevelop. Přímo z menu KDevelopu lze nově analyzovat aplikace napsané v C/C++ pomocí nástroje Heaptrack. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je binární balíček s KDevelopem 5.2.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 8
14.11. 17:33 | Nová verze

MojeFedora.cz informuje, že bylo oficiálně oznámeno vydání Fedory 27. Ve finální verzi vycházejí dvě edice: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server vzhledem k náročnosti přechodu na modularitu vychází pouze v betaverzi a finální verze je naplánována na leden. Vedle nich jsou k dispozici také alternativní desktopy v podobě KDE Plasma, Xfce a další a k tomu laby – upravené vydání Fedory například pro designery, robotiku, vědecké použití atd. Stahovat lze z Get Fedora.

Ladislav Hagara | Komentářů: 21
14.11. 17:22 | Pozvánky

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt – tradičně první čtvrtek před třetím pátkem v měsíci: 16. listopadu od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).

xkucf03 | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (73%)
 (14%)
Celkem 680 hlasů
 Komentářů: 36, poslední včera 18:43
    Rozcestník

    Dotaz: Prehazene a duplicitni odezvy z pingu

    24.6.2013 11:33 Bill Gates
    Prehazene a duplicitni odezvy z pingu
    Přečteno: 827×
    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: 61 | 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: 61 | 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: 61 | 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.