Új hozzászólás Aktív témák
-
Kicsit off, de keresővel nem találtam jobb topicot.
Tudna valaki ajánlani egy képernyőmegosztó programot, ami webserverként üzemel és böngészőből is nézhető az eredeti képernyő, de helyi hálózaton belül működik?
Konkrétan a Windows asztalt, vagy egy tetszőleges részét akarom nézni a telefonomon (csak átmenetileg egy rövid ideig, speciális feladat elvégzésének erejéig) Opera Mobile böngészőből.
Találtam is ilyen szolgáltatást, ami a PC-n Java, és gyönyörűen vitte a telefon is, viszont túl nagy volt a lag, mire keresztülment a központi szerveren (mert web-en keresztül látta a telefon). Nekem viszont alacsony, minimális lag-ra lenne szükségem, szóval ki kéne iktatni a képből azt, hogy oda-vissza körbeutazza az adat a földgolyót, inkább LAN-on menjen minden, helybe kéne a webszerver, amit a mobiltelefon böngészője láthat IP alapján.
Tippek?
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
velizare
#18437
üzenetére
Nem jó, ez épp egy Symbian telefon (és platformfüggetlen megoldást keresek).
A probléma, amin ötletelek az, hogy kimérhessem a mobiltelefon kijelzőket is úgy, mint ahogy az asztali PC és laptopmonitorokat szokás kalibráláshoz és profilozáshoz. Ehhez csak annyi kell, hogy egy kellően nagy (nem is feltétlenül fullscreen), RGB színkódokkal megadott homogén pacát jelenítsen meg a kijelző (de több ilyen színt is ki kell mérni és minél több, annál jobb...).
Első ötletként összeraktam pár képet PhotoShopban és kézzel lapoztam a telefonon, miközben manuális módban mértem pontról pontra. De Így nehéz kellő számú mérést végezni és már minimálisan kevéssel (mondjuk 10-20 közti számban) is nyögvenyelős.
PC-n ez rég automatizálva van, egy program kirajzoltatja a pacát (az előre összeállított RGB kódlistából), kiolvassa az adatokat a műszerből és továbblép a következőre (ha gyorsan mér a műszer, akkor pörög rendesen, több 1000 mintát lehet venni 10-20 perceken belül).
Így egyik megoldás írni egy programot mindenféle mobilplatformra, ami USB-n vagy Bluetooth-on fogad RGB színkódokat és ilyenre színezi a kijelzőt (és PC-re is kell egy progi, ami kiküldi a parancsokat - az profilozó programban már van olyan mód, ami infót szolgáltat ehhez, de tovább még senki sem jutott vagy nem publikálta a software-eit..). A másik, hogy minimális késéssel (mondjuk max 0.2sec, de amit próbáltam web interfész, az inkább 0.5-1sec volt) megjelenítjük valahogy a PC monitor képét a telefonon -> amire már eleve léteznek megoldások, csak valahogy a lagot kéne kezelni. -> Mondjuk úgy, hogy nem megy körbe az adat a földgolyón, csak local webserveren.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#18438
üzenetére
Talán érthetőbben megfogalmazva:
Az itthoni gépemen akarok indítani egy webserver-t, ami egy egyszerű, akár komolyabb mobiltelefonos böngészőből is elérhető és kellően sűrű mintavételezéssel/frissítéssel dolgozik (~15-30fps kéne a lag miatt).
Bár lehetne ez egy videó stream is, olyan felbontással és formátumban, amire egy telefon is rá tud kattanni, a lényeg, hogy a PC monitor aktuális képét közvetítse minimális késéssel, és helyi hálózaton belül is közvetlenül elérhető legyen egy IP címről (a wifi routerhez csatlakozó PC és mobil közé ne ékelődjön be az internet).
És alkalmankénti kis lag nem gond, annyira értelmes a software, hogy felismeri, mikor félremér (besaccolja hogy mi lehetséges egy nézhető monitoron, és eldobja azt, ami nem tűnik annak).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Pusztán érdekességből akartam megnézni, hogy mennyibe kerülhet egy >1Gb sebességű FiberChannel PCI-E kártya és hatalmas meglepetésemre találtam ilyesmiket: ebay
Ez tényleg ilyen olcsón megoldható, hogy veszek két ilyen filléres használt kártyát és összekötök itthon két gépet több gigabittel (pl. a RAID-5 tömbös NAS és az asztali PC-m közé épp ideális lenne a 4Gbps), vagy ezek csak speciális szerver alaplapokban hajlandóak működni, esetleg nem is alkalmasak switch/router nélkül felállítani egymás közt egy IP alapú halózati kapcsolatot, hanem valamilyen linces-elt szoftver kezeli?TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Próbálkozott már valaki olyasmivel, hogy fog egy Prolific PL27A1 vagy hasonló chip-es USB 3.0 kütyüt (mint például ez: [link]) és egy pár passzív USB - RJ45 adaptert, hogy Linux, illetve Windows közt ezen keresztül RNDIS-es felállítson egy ~5Gbps TCP/IP hálózatot?
Ugyan itt elfogadok bármi más tippet >=2Gbps-re, ami olcsóbb, mint a szabványos Base-T 10Gb.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Amartus
#30832
üzenetére
Nem a jövő, már több éve elérhető olcsón otthonra, de az új szabványok egyre több csatornát fognak be, amikből 5Ghz-en többet használhatsz, igy valamelyest igaz, hogy "időtállóbb" a soksávos AC, ami 2GHz-n nem megy (otthon is legálisan).
Szerintem nem érdemes olyanra előkészülni, amit nem tervezel használni. Később minden még olcsóbb lesz, ami ma elérhető és talán még ujabb dolgokra vágsz majd ha akkor nagyot frissül a kliens oldal (az AC is draft most).
Ahhoz általában "hardware NAT" kell, tehát olyan chipset, ami tudja + persze olyan driver és OS, de a gyári általában kezeli, ha megvan a hardver.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Amartus
#30842
üzenetére
Azt egymagában olyan triviális "feltörni", mint mikor az jelszó, hogy: jelszó
A "biztonság" az valahol ott kezdődik, hogy kizárólag WPA2/AES (WEP és WPA/TKIP kompatibilitás nélkül -> akkor is, ha ez a legöregebb eszközök frissítését/cseréjét igényli) QSS nélkül (egyszer rá kell szánni magad, hogy körbevidd, szükség esetén kézzel begépeld a jelszót), valamilyen random generált 50+ karakteres jelszóval (ha fontos fejben tartani, és nem ér nagy veszteség akkor sem, ha feltörik, akkor is legalább ~10 karakter, "megcifrázva" amennyire lehet, nem egy szál értelmes szó).Általában hirdeti ezt a gyártó, hogy milyen gyors NAT-ra képes a kütyü. Vagy leírják ezt, hogy "hardware NAT", "Gigabit NAT", "wire-speed NAT", stb, vagy konkrét számok szerepelnek a leírásban, amik a saját belső méréseik (ilyenkor általában durván 150-300 a szoftver, vagy 850-1600 a hardware NAT, a hálózat és a szűrés bonyolultságától függően, ami 1500-as MTU alatt drasztikusan csökkenhet, mert a csomagok száma a mérvadó, nem a méretük, így nagyjából ugyan annyi megy át a kisebb csomagokból is).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Volt itt szó nemrég a gigabites NAT-ról. Próbaképp áttettem a NAS-om egy külön VLAN-ra a WDR4300 switch-én, és ezzel másik interfészre, illetve IP tartományba. Így ~45MB/s-re csökkent a nagy file-ok másolási sebessége ~100MB/s-ről (SMB3, RAID-5). Kicsit tuningolva van a SoC, de az csak olyan +10%. Ezek szerint sokat gyorsult az OpenWRT szoftveres NAT az utóbbi években, mikor méregették a hardware és szoftver NAT közti különbséget (nemrég forgattam magamnak frisset, miután viszonylag rég nem nyúltam hozzá). A lényeg, hogy ez elég lenne egy képzeletbeli 300/30 Mbps netcsomagnak. Nem gigabit, de felénk pl. 120/10 a rendelhető legmagasabb...
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Bekockáztattam egy ilyet: MELLANOX CONNECTX-2 2-port, mert a többi hirdetéshez képest kedvezőnek tűnt a két optikai modullal együtt (feltéve persze, hogy "nyerek a zsákbamacskán" és működik a kártya és a modulok is) és gondoltam mellé beszerezni még egy ilyet: CONNECTX-2 1-port, hogy áttegyem ebbe az egyik optikai modult a 2 portosból, amik közt egy crossover üvegszál-pár futna (kártyából-kártyába, egy NAS és egy asztali PC közt).
A harmadik ponttal akadtam el: szeretnék egy olcsó 1000Base-T RJ45 modult találni a 2 portos kártya második portjába. Viszont sohasem volt még dolgom ilyen eszközökkel, így azt sem tudom, hogy az SFP+ visszafelé kompatibilis-e a régebbi ("sima") SFP modulokkal, vagy azon túl is nagyon le van-e szűkítve, hogy egy-egy kártya milyen modult fogad, vagy teljesen rugalmas a szabvány (és akkor átdugnám ide a kábelmodemem, hogy a NAS-ból egyben router is legyen, a WiFi-s kütyük pedig csak AP-ként dolgozzanak).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Bacusuz
#31036
üzenetére
Átmeneti megoldásnak javaslom próbáld ki, hogy az eszközkezelőben a WiFi adapter beállításainál vedd le a pipát arról, hogy a gép kikapcsolhatja azt az eszközt. Nekem egy régi (még XP-vel előtelepítve érkezett) notin van erre szükség durván Win8 óta (rég megszűnt már az Intel NG4xxx driver támogatása).
(Ui.: nem biztos, hogy ez segít, csak tipp, nálam a hibajelenség is már egy kicsit.)[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
GabN73
#31043
üzenetére
Ha be tudnád tenni durván a közepére, akkor szerintem ellennél egy erősebb fajta ASUS-al (vagy haosnló, jobban összerakott kütyüvel, amiből nincs kispórolva az anyag). Letilthatod a UPC-s doboz WiFi-jét és ezt használhatod tetszés szerint vagy router, vagy AP-ként (előbbi csak akkor, ha a UPC kütyüjét át tudod és akarod tenni bridge módba).
A repeater módot szerintem hanyagold, ha meg tudod oldani a kábelezést, de ha nem, akkor nyilván csak ez marad.
Nemrég nagyon átvertem magam, mikor csak a jelszinteket néztem, de aztán LAN<->WLAN sebességeket is mértem és oda-vissza (fel és letöltésben is) lemosta a WDR4300-at az RT-N66U, amin közbeékelődött legalább egy bútor, vagy ajtóval megszakított fal, de főleg ha födém (bár a vasalt födém érthető okokból már mindkettőt szépen megfogja, főleg az 5GHz-t).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Alapesetben minimum megfelezi a sávszélességet azon a kütyün, ami a repeater-re csatlakozik, illetve vegyes véletlenszerű leosztásban (az AP-n és repeater-en is lóg legalább egy-egy kliens) jelenthet némi korlátozást (alapesetben minden egy csatornán osztozik, a repeter-en átmenő forgalom duplán, kivéve pl. ha az AP és repeater is két [vagy még több] rádiós és véletlenül pont el tudod ideálisan rendezni ezeket és a klienseiket úgy, hogy ne zavarják egymást, de ez már elég speciális, nem épp "plug and play" eset).
Nem minden gyári OS támogatja és egyforma custom OS-el sem minden chipset tud WDS módban együttműködni (ami egyénfüggő, hogy probléma-e vagy sem, de lehet) és ha igen, akkor sem mindig triviális felépíteni egy WDS-t (ismét: ha kell... de lehet hogy most nem is gondol rá, hogy kell, később viszont egyszerűen nem érti majd, hogy mi a baj, "miért nem látja a TV a telefont?" és hasonló kérdések merülnek fel...).
Ne mindig működik egyszerűen és jól, hogy az egyes eszközök automatikusan a nekik ideális (hozzájuk közelebbi / kevéssé árnyékolt) AP-re csatlakozzanak, manuálisan pedig kínos kapcsolgatni, főleg véletlenszerűen mozgó eszközök esetén (márpedig a WiFi-t jellemzően mobil eszközök használják, amik azért mobilk, hogy mozoghassanak is...)
Biztos lehetne még sorolni, de szerintem kiindulási alapnak elég.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Kifogytam az ötletekből, hogy mi lehet a gond.
Van két távoli telken (mindkettőn külön-külön ugyan ez):
100Mbps switch-en 4db kamera (max ~6Mbps) + egy SXT-L5 + 2Ghz WiFi AP
Egy harmadik helyszínen egy 1000Mbps switch-be fut be a két SXT-L5 párja, és még egy kamera, majd ez megy tovább egy másik 1000Mbps switch-be, amin a "szervergép" is lóg, ami rögzítené a kamerák képét.A szervergéppel egy telken lévő kamera képének rögzítése problémamentes.
A távoli helyszínekre ellátogatva is elérhető a helyi ~65Mbps WiFi AP-n át a kamerák képe (bár ott rögzíteni még nem próbáltam, de a magas bitrátájú stream élőben dekódolva ránézésre folyamatos a képernyőn).
Az SXT-k közti szintetikus sávszélességmérés szerint bőven elég a kraft. (A hibakereséshez már áttettem őket 20-ról 40Mhz-re és így tartósan 100Mbps felett mérek.) Bár UDP csomagokkal tesztelve látszik némi packet loss.
Mikor a központi gép próbál rögzíteni, akkor hibásak a távoli kamerák videói.Gondolom az lehet a probléma, hogy a kamerák UDP-n stream-elnek, az SXT-k közt pedig van packet loss, így vesznek el csomagok, amik nélkül nem lehet korrektül dekódolni a videót.
Erre valami megoldási tipp, vagy más ötlet, hogy mi csúszik félre?
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Soma01
#31476
üzenetére
Ezzel így valószínűleg egyértelműek lesznek a számok:
ilyen, ha csak egy kamerát nyitok meg (~6Mbps) screenshot
ilyen, ha generálok némi szintetikus forgalmat is (~100Mbps) screenshot
De ha rányitok még 1-2 kamerára, akkor elkezd kimerevedni/szétesni a kép.Az SXT-ket már átállítottam úgy (mindkét oldalon), hogy az ethernet nem Auto negotiation, hanem fixen 100Mbps Full-duplex, mert már erre is gyanakodtam, hogy a switch esetleg 10Mbps-ben egyezik csak ki. Illetve próbáltam váltogatni a protokolokat szabvány 802.11 és NV2 közt, illetve játszogattam a beállításaikkal, de mindhiába. Min ha lenne valahol egy 10Mbps dugó.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Soma01
#31485
üzenetére
Többet egyszerre problémás nézni, mert elkezd megállni és széthullani a kép, majd megszakad. A kamerákhoz kapott program jobb erre, egyrészt mert szoftver dekóderes (nem lehet gond a 4x1080p, ha a DXVA-t erőltetné a VLC, a CPU viszont elég erős ezen a gépen, ahol most próbálgatom), illetve folyamatosan próbál újracsatlakozni, de ott is csak ritkán látok kimerevített állóképet, inkább az "initializing.." vagy "lost, reconnecting..." van az ablakokban, vagy egy pillanatkép odafagyva.
Kipróbáltam itthon a lánc több elemét is külön-külön, mielőtt felszereltem távolra. Be voltak kötve az itthoni helyi hálóra a kamerák és nézegettem a képüket, rögzítettem pár órát, stb. Illetve az SXT-ken is lövöldöztem át adatokat szobán belül. De az valahogy kimaradt a tesztfázisban, hogy az SXT-ken lövöm át a kamerákat.
A felvevő az egy AMD 5600K CPU-s PC, ami egyben a NAS-om is. SMB-n nem kottyan meg neki kihajtani a gigabites vonalat (3db 7200RMP HDD van RAID5-ben).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Soma01
#31487
üzenetére
Vidék. Szinte minden csatorna üres, mikor scan-elek (és tesztképp próbáltam már átpimaszkodni olyanra is, amire nálunk nem szabadna, mert az még valószínűbb, hogy tényleg üres), illetve futtattam már hosszabb időn át ezt a szintetikus mérést, sohasem esik olyan alacsonyra, ami ne lenne elég borravalóval együtt is ahhoz, amit maximum generálhatna a négy kamera.
Nem hiszem, hogy a nyers WiFi sebességgel lenne a gond, inkább valami szoftveres "ütemezési" problémára tippelnék, akár a switch-eknél, akár az SXT-nél az ethernet és WLAN oldal közt. De igazából csak "lelkes amatőr" vagyok, nem értek hozzá pontosan, hogy mi lehetséges és mi nem.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Azt hiszem sikerült közelebb jutni a megoldáshoz: visszaálltam NV2-re és kipróbáltam a TDMA Period Size két végletét Auto helyett fix manuális módban, ami gyakorlatilag a minimális ping idő is lesz egyben. 1ms-el sokkal jobb, mint 10-el. Tehát úgy néz ki, hogy erősen latency érzékeny is a dolog.
Úgy néz ki, hogy a sávszél elég 1ms beállításon is, bár ezzel is véletlenszerűen 1-10 közt landol valahol a ping (de 10-el 10 és 30 közé, néha többre), ami még mindig sokkal több, mint ha végig lenne kábelezve néhány switch-en át (ezt nem úgy értem, hogy valós alternatíva 1-2km közti távolságokra a kábel, csak összevetésül ahhoz a kamerához, aminél nincs wifi a szerverig és jól működik).Ha NAT-olnék a távoli helyszíneken, az vajon a WiFi link késésétől függetlenül is ugyan azt érné el, mint ha 1ms alá tornáznám a ping időt? A kamerákat és az SXT-t csak egy switch választja el és az SXT is tudna NAT-olni, bár lenne más hátránya, szóval csak akkor csinálnám így, ha ezt a gondot biztos megoldaná, más egyszerű megoldás viszont nem lenne ezen kívül (olyan, amihez nem kell további aktív hardware és/vagy hozza magával valami formában azokat a hátrányokat, mint a NAT-olás).
(#31493) Soma01
Azt már írtam, hogy ha kimegyek laptoppal és felugrok az ottani AP-re, akkor minden jó. Ebből következtettem, hogy alapvetően a WiFi sem probléma és hogy a switch is rendben van.
És nem is komoly AP-k, öreg TP-Link 740-esek 20Mhz-re állítva 65Mbps a névleges sávszél. Csak azért lettek lerakva, hogy kint is élőben lehessen nézni a képet, míg beforgatjuk a kamerákat (és ott maradt még gondolva erre, hogy ha hibát kell nyomozni, mert amúgy 2000Ft-ot érhet...).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Soma01
#31496
üzenetére
Egyelőre annyit értem el, hogy meg lehet nyitni egyszerre három stream-et és nem feltűnően hibásak, de ha megmozdul egy kutya, akkor azért látszik, hogy kicsit darabos és néha átvillan az egész képkocka szürkébe.
Inkább pont azon gondolkozom, hogy korlátozni kéne a sávszélt, mert arra nincs igazán szükség, a packet loss és/vagy latency lehet inkább érdekes (de utóbbi akkor is nő, ha előbbi miatt [akár többször] újra kell küldeni egy csomagot). Alacsonyabb sebességeken elvileg magasabb lehet a txpower is (így jobb lehet a jel/zaj viszony, ha ez épp [is] a gond) és attól függetlenül is jobb eséllyel ér célba épségben egy csomag (bár ennyire nem értek a WiFi-hez, hogy pontosan miért is, de ezt már sok helyen olvastam és láttam is, hogy hiba esetén mindig alacsonyabb rátán próbál újraküldeni, gondolom nem olyan "sérülékeny" a kevéssé komplikált moduláció?).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Kicsit piszkáltam még a beállításokat és próbaképp előbbre ugrottam az RC verziós OS-re (előbb vissza próbáltam lépni a korábbi bugfix ágban lévőre az eredeti stable-ből, de nem volt jobb az se, így "egy f@sz" alapon kipróbáltam ezt is...) és mértem egyet szimultán oda-vissza WiFi-n: [link], és ezt a másikat csak az egyik oldalon tudtam ma eljátszani (a másikon nincs semmi "intelligens" eszköz, amivel ilyen szintetikus tesztet csinálhatnék): lemértem ugyan így a szimultán oda-vissza sebességet a két AP oldali SXT-n is a helyi switch-en keresztül: [link] -> ez kb. ugyan annyit fut, mint a WiFi rész, tehát összességében elmondható, hogy gyakorlatilag van egy "tökéletes" Duplex 100Mbps hálózatom a két helyszín közt.
(Azért is váltottam vissza 802.11-re, mert valamelyik OS verzióval néha bontotta a kapcsolatot az N* módokban, de mint látszik amúgy is mindegy, megvan a "wirespeed" a levegőben...)És... még épp van időm átszerkeszteni a hsz-em, hogy fogalmam sincs pontosan mitől, mert már ötször oda-vissza áttúrtam a beállításokat mindenen, ami közbeesik és konfigurálható, de most valamitől használhatóvá váltak a kamerák. Még egyszer utoljára ránéztem a videó ablakokra, mielőtt feladtam mára és most épp jó.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Soma01
#31512
üzenetére
Ismerem a fórumtémát, annak idején ott mondták el, hogy érdemes hidalni az SXT-kkel (illetve hogy ezekkel az RSO L3 eszközökkel egymás közt gyakorlatilag pont csak ezt lehet csinálni, így kvázi a "működik" és "nem működik" közt lehet célba lőni, ami a bridge-elést illeti...).
Azért nem kérdeztem még ott újra, mert most sem vagyok meggyőződve róla, hogy kizárólag az SXT-k közt lenne a hiba. Ma leültem az egyik távoli helyen, rácsatlakoztam a laptop-ommal kábellel az ottani WiFi AP ethernet switch-ére, és próbáltam file-okat mozgatni a noti, illetve az itthoni NAS közt. Néhány percen belül le vagy fel tudtam tölteni annyi adatot, amit egy óra alatt termelnek a kamerák. Konkrétan videó file-t mozgattam SMB-n, durván négyszer akkorát, mint amekkorát az itthoni kamera generál az 1 órásakra vágott file-okba, csak hogy empirikus alapon is kizárjak egy esetleges "tömörítési trükköt" a szintetikus mérsé során, vagy egy bagatel mértékegység félreértést, hogy mennyi is az annyi...
Ma átraktam automatáról konstans 6Mbps-re a kamerák encoder-ét, hogy ha esetleg 10Mbps-t alkudnak ki a switch-el 100 helyett, még abba is mindenképp bele kelljen férniük overhead-el együtt, az itthoni kamerát pedig áttettem egy szimulált 10Mbps switch portra, amin még mindig jól érzi magát (van egy hibás switch-em, amin az egyik port max 10Mbps-re képes a hajdani 1000 helyett).
És nem, igazából nincs megoldva a gond. Épp csak annyi történt, hogy tegnap éjjel véletlenül épp jó volt, de most megint nem az.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Úgy tűnik jó volt az egyik korábbi sejtésem a kamerás problémát illetően.
Találtam egy ffmpeg paramétert, ami az alapértelmezett helyett (ami ez esetben UDP, mert először azt próbálja és tartalékként próbálkozna TCP-vel, ha az UDP nem válaszol) explicit módon TCP-t próbál használni RTSP stream-eknél (és szerencsém van, hogy a kamerák bele is egyeznek ebbe, mert lehetnének "válogatósak") és így egyelőre használhatónak tűnnek a rögzített videók (élőben pedig úgysem nézem, de ott is biztos megoldható lenne a TCP kényszerítése valamilyen videólejátszóban is, vagy ha más nem megy, akkor tűzfallal tilthatnám az UDP-t az adott IP-ken, stb...).TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#31560
üzenetére
Hát nem.
TCP-vel véletlenszerűen, de túl sűrűn teljesen bontódik a kapcsolat (néha végigbírja az 1 órát, ahol az ffmpeg újraindul, hogy új file-t kezdjen, máskor egymás után többször is leáll 1-3 percenként) úgy, mint ami jól végezte dolgát (debug loglevel mellett sincs semmi hibaüzenet, csak kiírja zöld betűkkel az ffmpeg, hogy nincs tovább mit kiírni, ezért leáll).
Gyanítom, hogy ugyan az a véletlenszerű esemény következik be, mikor TCP-vel teljesen bontódik, mint amikor UDP-vel zagyvasággá válik a rögzített anyag.
Kipróbáltam a HTTP-tunneling módot is (az UDP_Multicast módtól amúgy sem várnék sikert, de egyik kamera sem támogatja, több opció pedig már nincs az RTSP szabványban), ami elsőre biztató, de ezt 9-ből csak 5 kamera támogatja (a szenzor és az encoder chip elvileg ugyan az mind a 9-ben, de a firmware más, a frissebbik 4 nem válaszol a HTTP kérésre).
Lehet, hogy az lesz a vége, hogy mindkét helyen le kell tennem valami olyasmit, mint pl. egy Raspberry Pi, amin egy Samba share-be dolgozik az ffmpeg.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#31592
üzenetére
Ezt ideteszem, hátha másnak is lesz még hasonló problémája...
A protokoll 802.11 vagy NV2 helyett Nstreme, de [dynamic size] helyett [best fit] framer és 3200 helyett 1524 framer limit (ezt az értéket empirikus alapon kellett iterálással belőnöm, de tudtam, hogy 1500<=X<=1536, amit keresek, mert 1500 az ethernet MTU és alapértékekkel nekifutva, mikor egy pillanatra rá tudtam pislantani a sűrű szakadozás közepette, akkor épp 1536-ra lőtte be magát a dynamic). Így nincs torlódás a wireless hídon.
Plusz mindezek fejében az RTSP-től az alapértelmezett UDP helyett TCP kapcsolatot kell kérni az adatcsomagokhoz is, és akkor nincs effektív packet loss se (csak szép nagy extra forgalom az ACK-k miatt, de ez úgyis egy erre dedikált és bőségesen tág vonal, szóval elférnek...).Az Nstreme a Mikrotik sajátja, de más hasonló gyártóknál is lehet hasonló egyedi megoldás, aminél van ilyen lehetőség, illetve talán 802.11-hez is beállítható valamiképp az effektív frame size, mert végül is ez a kulcs (és itt azért érdekes az nstreme, mert itt ez engedte ezt manuálisan szabályozni, hogy megolajozhassam a hidat és kisimuljon a forgalom).
Nem volt egyszerű történet.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Még mindig szenvedek az IP kamerákkal.
Lennie kell valami triviális dolognak, ami felett elsiklom.A WiFi link optimalizálása és UDP-ről TCP-re váltás csak félmegoldás volt.
Az egyik távoli helyszín már használható, a másikon viszont időnként reboot-olnak a kamerák (ilyenkor több másodperc is kimarad, és gondolom hosszú távon "nem egészséges" nekik óránként többször reset-elődni...). Hardware-esen mind a 9 hasonló, de a kényesebbik 4-en más a firmware, mint a többi 5-ön, mert két külön rendelésből jöttek. Kizárásos alapon talán ez lehet az ok a némileg eltérő viselkedésre.
(Illetve az automata bitráta miatt is változékony, de most felhúztam mindet a maximális 8Mbps-re a teszteléshez, hogy ez ne verjen át.)Most otthagytam egy Windows-os laptop-ot az egyik helyszínen, leállítottam a távoli rögzítést (ami Gentoo Linux alól menne) és helyben próbálkozom UDP-vel és TCP-vel is, de ugyan az a helyzet, mint WiFi-n át. Nagyjából ez történik UDP-vel:
- egy kameráról vígan írja ki az ffmpeg file-ba RTSP-ről a H264 stream-et
- kettőnél nagyon ritkán, de már előfordul packet loss (bár használható marad a file)
- háromnál sűrűn dobja az ffmpeg a packet loss üzeneteket és szemetel a kép
- négynél már vadul pörögnek a packet loss üzenetek és használhatatlanok a file-ok
Ugyan ez TCP-nél arra változik, hogy egynél több kamera mellett egy kevéssé egyértelmű üzenet jelenik meg néha (de sokkal ritkábban, mint UDP-nél, és a videókban nagyon nehéz kiszúrni, hogy épp ilyenkor veszik-e el 1-2 képkocka, mert nem esik szét úgy a kép, mint mikor UDP csomagok vesznek el), viszont minél több kamera fut egyszerre, annál sűrűbben, durván 2-30 perces időközönként reboot-olnak a kamerák (ennek nyoma van a kamerán tárolt naplófájlban is, illetve ha loop-olva van az ffmpeg, hogy azonnal újrainduljon, amint tud, akkor látni is, ahogy tükrözött sötét képpel indul el a videó, majd átvált tükörképre és beszintezi a fényerőt...)A reboot-ra a tipp-jeim, hogy vagy próbál bufferelni, míg megtelik a RAM és emiatt jön egy pánik, vagy egy watchdog szerűség vélt/valós hálózati hiba esetén reset-el. A másik 5 kamerán, amik nem reboot-olnak, ott gondolom vagy több és elég erre a szabad RAM, vagy nem komplett reboot történik, hanem eldobja a buffer tartalmát, mikor megszorul, vagy esetleg nem is alakul ki ugyan az a szituáció, amiért a másik 4 reboot-ol (mert talán a másik 4-nek sem szabadna, hanem ez egy firmware bug az adott verzióban...). Passz.
Na de ezzel most mi lehet a gond.
Ha egyszerre egy (bármelyik) kamera OK, akkor a switch és a kamera közt nem szűk a keresztmetszet.
A laptop és az SXT közt is megvan a 100Mbps a swith-en át, mert stabil ~10MB/s-el tudok róla SMB-n file-okat hazaküldeni.Sőt, itthon mind a 9 kamera átmegy egy 1000Mbps switch-en, az is amelyik itthon van, az mégsem érzékeny a távoliakra (soha semmilyen formában, az mindig hibátlanul rögzül, bármit is csinál a többi 4+4).
Amikor még a WiFi-re gyanakodtam, ott a RouterOS-ben használtam a Packet Sniffer-t és azt láttam, hogy többnyire 1500 byte-os csomagok mennek a kamera felől a szerverhez és TCP esetén fele ennyi 52 byte-os csomag megy vissza. Utóbbi UDP esetén nincs (így ez nagy valószínűséggel mind TCP ACK csomag és UDP-nél nem is, vagy csak nagyon ritkán nyugtáz vissza az RTSP).
Egy-egy kamera <10Mbps forgalmat generál.
Miért lehet akkor, hogy 4 kamera "megfojtja egymást" a 100Mbps hálón és mi erre a megoldás?
Létezhet olyan, hogy ha egy switch-en több 10Mbps-en működő portból irányul forgalom egy 100Mbps portra, akkor utóbbi is gyakorlatilag összesen 10Mbps-re korlátozódik? Ezt valamilyen switch hibakén fognám fel, de már próbáltam switch-et cserélni (az egyik egy noname kínai, amit még a kamerák forgalmazójától vettem [és miért árulnának pont olyat, ami épp idióta mód inkompatibilis a kameráikkal...?], a másik egy hazai kiskerből találomra felkapott TP-Link 10/100 PoE switch.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31757
janos666
nagyúr
Gubek-Einste
#31749
válasz
Gubek-Einste
#31749
üzenetére
Nem (szerverről frissül a saját lábán, és mikor tegnap ránéztem, akkor letöltött egy novemberi build-et a szeptemberi helyett, de visszafelé nem látok utat, illetve igazából változhatott a SoC is, nem szedtem őket szét, csak a szenzort és encoder chip-et figyeltem a specifikációknál), de még akkor is erősen félmegoldásnak tűnik, illetve továbbra is kérdés, hogy 4 független ffmpeg folyamat esetén (így gondolom nem a programon belül van a hiba, de próbáltam úgy is, hogy egy ffmpeg folyamat kezeljen 4 stream-et, de úgy is csak annyival "jobb", hogy nehezebb átlátni a debug üzeneteket és nem tudom loop-al újraindítani a leszakadozó szálakat) miként folytja el egymás elől a sávszélességet, ha sokszor ennyinek is bele kéne férnie a keretbe?
Az OS-re is nehéz gyanakodni, miután próbáltam Linux-al és Windows-al is, illetve ffmpeg helyett gstreamer-el is, utóbbi az még érzékenyebb és követhetetlenebb. Vagy van esetleg mindkét OS-ben valami szűk limit UDP forgalomra?TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31759
janos666
nagyúr
Smktrooper
#31758
válasz
Smktrooper
#31758
üzenetére
Feltettem már ezt a kérdést, de elakadt a "hogyan" résznél.
Tegyük fel, hogy hibás az egyik (vagy akár az összes) kamera kábele, vagy valami inkompatibilitási okból Half-duplex 10Mbps-re vált(anak azok) a switch port(ok).
Az alapján, hogy egyszerre bármelyik tetszőleges kamera működik egyedül UDP-vel, a laptop és(/vagy) SXT felé pedig megvan a duplex 100Mpbs (ez ellenőrzötten, tesztelten), akkor ebből elvileg még nem lehetne gond. (Amúgy még nem néztem soha passzív PoE adapterrel és managed switch-el, vagy közvetlenül NIC porton, hogy normál esetben milyen módban üzemel egy-egy kamera portja, a PoE-s unmanaged switch-ek pedig nem jelzik ezt.)
Sok switch-en van pl. >=4db 100Mbps és 1db 1000Mbps "uplink" port, vagy akár 32-64db 100-as és egy-két >=10Gbe SFP+, stb. De pl. UDP esetén nincsenek ACK-k, így ott még az sem szabadna, hogy bezavarjon, ha az "uplink" port (itt az SXT vagy a laptop) visszavált Half-Duplex 100Mbps módba (amikor feltételezett Half-Duplex 10Mbps porttal kommunikál), hisz úgyis kvázi egyirányú a forgalom.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31761
janos666
nagyúr
Smktrooper
#31758
válasz
Smktrooper
#31758
üzenetére
Ennél a példánál TCP-t használ az ffmpeg és próbaképp vissza van véve az fps 30-ról 15-re, a bitráta pedig 2048-ra (az normális, ha nem bitre pontosan 2048 van a parancssorban, az egy átlagérték, amit az ffmpeg számol, és a 2048 csak egy "target" érték a hardware encoder-nek, amitől normális, ha picit eltér...). Nem úgy néz ki, mint ha a meg lenne halva a hálózat pusztán attól, hogy aktív egy-egy kapcsolat a kamerák felé. Itt most távoli asztalon nézem a laptop-ot és ott másolok át egy videófile-t (nem tömöríthető adat) WiFi-n az itthoni NAS-ról az ottani Windows asztalra: [link] - szerintem elég szépen szalad és nem szakad meg a rögzítés sem (utóbbi akkor történik, ha reboot-ol a kamera 10-20 percen belül).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Ez egyre rejtélyesebb. Most végigpróbáltam mind a 4 kamerán egyesével, hogy egyszerre csak egyet, de azt párhuzamosan négyszer nyitom meg UDP-n, négy külön ffmpeg folyamattal. Így jól működik (elvétve jelez néhány packet loss-t, de használható mind a négy videófile, egyiken sem észlelhető számottevő képhiba).
Ugyan az az egy kamera (bármelyik) négyszer sima UDP-vel (nem multicast, olyat szerintem nem is tud, de nem is kértem) az OK.
Ha ráindítok így egy második kamerát egyszer, már kezdődnek a bajok (ugyan úgy, mint ha csak egyszer-egyszer nyitnék meg egy-egy kamerából kettőt: még nem vad, de már kezdődik a packet loss üzenet áradat).
Négy kamera külön-külön egyszerre UDP-vel pedig katasztrófa.
TPC-vel hiába butítom a képminőséget, 10-20 percenként reboot...Ez talán mégiscsak valami OS vagy szoftver bug lesz. Google-el találok 2010-től 2015-ig erre vonatkozó hibajelentéseket. Általában mindig le van zárva valamilyen patch-el, vagy javaslattal, hogy mit írjon az ember a parancssorba a buffer növelésére. Már az udp.c-ben is feltoltam a sokat emlegetett buffer méretét, de van felső korlátja és az nem elég, vagyis gondolom inkább más a baj.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31772
janos666
nagyúr
Smktrooper
#31768
válasz
Smktrooper
#31768
üzenetére
Irreleváns, mert nincs NAT, csak LAN, a WiFi is Bridge móban van, de a tesztelésre kint hagyott laptop az közvetlenül abba a PoE-s unmanaged switch-be ment, amibe a kamerák is.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31774
janos666
nagyúr
Smktrooper
#31773
válasz
Smktrooper
#31773
üzenetére
Azt nem tudom miért nem jutott eddig eszembe komolyabb súllyal figyelembe venni, hogy a kamerákhoz mellékelt Windows-os kínai szotyi (aka "CMS2") látszólag probléma nélkül tud rögzíteni az itthoni Windows-os asztali PC-men WiFi-n át is, ami nem olyan meglepő, hisz eddig is tudtam vele nézni élőben a nagy felbontású stream-eket szimultán 2x2 kiosztásban is. Szóval szerintem szűkíthetünk egyet a körön, hogy csak RTSP esetén van probléma. Bár eddig ezt át sem gondoltam, hogy ez a szoftver talán nem RTSP-n hozza be a stream-eket, hanem valami "natív proprietary" (vagy egyszerűen csak nem feltüntetett nyílt szabványos) módon. Bár végül is lehet, hogy RTSP az, csak valami speciális klienst tákoltak hozzá, ami kikerüli a bug-ot (vagy direkt lehetetlenítették el a szabványos RTSP klienseket?).
Nemrég kipróbáltam az RTSP-t VLC-vel is, ami nem ffmpeg-et használ ehhez, hanem egy másik RTSP megoldást. Ugyan az a szituáció (1 kamera OK, kettőtől több sok, 4 már SOKK), csak sokkal csúnyábban száll el (elkezdi "végtelen sebességgel", azaz a HDD írási sebességével teleírni a TS file-t, ami utána nem nyitható meg player-el).
Mondjuk ettől még továbbra is fura, hogy miként tudnak "interferálni" RTSP használatakor (azt a fenti tény tisztázza, hogy a nyers sávszélesség az rendelkezésre áll), mert nem egyszerűen csak szar az RTSP implementációjuk, hanem akkor van baj, ha egyszerre több kamera is RTSP-t használ ugyan azon a 100Mbps vonalon át.
Teljesen úgy néz ki, mint ha pl. egymásnak is elküldenék az RTSP stream-eket valamiféle peer-to-peer jelleggel, de ezt hihetetlen nehéz elképzelni, hogy miért és miként.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31817
janos666
nagyúr
Smktrooper
#31775
válasz
Smktrooper
#31775
üzenetére
Feleslegesen messzire megyünk vissza. Aktuális összefoglaló:TCP-vel mind a 9 kamera képe hibátlan. Az egyetlen gond, hogy így 4db X típusú kamera rendszeresen reboot-ol, csak 5db Y típusú stabil (így valószínű, hogy a TCP-s reboot-olás az X típusú kamerák eredendő hibája -> ezért erőltetném [az egyébként alapértelmezett] UDP-t, bár persze lehet, hogy a TCP-s reboot gond is megszűnne, ha eltűnne a másik probléma, ami az UDP-t is érinti...).
UDP-vel soha sehol nincs reboot és egyszerre 1db (tetszőleges) X típusú kamera rögzíthető az Y-októl függetlenül, de egyszerre kettőnél több már használhatatlan.
A problémás 4 kameránál semmi sem változott, mikor ott helyben switch-et cseréltem alattuk, vagy mikor kivittem oda egy laptop-ot is, és bekötöttem közvetlenül abba a switch-be, amibe a kamerák is kötnek és azzal is próbáltam rögzíteni (sőt, a szerveren Gentoo Linux, a laptop Windows 10 van).
A kinti laptop és itthoni gépek közt ~10MB/s-el tudtam file-okat mozgatni. Zavartalan 100Mbps-el kommunikált a kinti switch-en át a laptop és az SXT olyankor is, mikor a kettő közül valamelyik épp rögzíteni próbálta a kamerákat, akár TCP-vel, akár UDP-vel.
Mikor épp mind a 4 kamera vissza volt véve 0.2MB/s-re, gyakorlatilag meg sem látszott a fájlmásolási sebességen, ami előtte durván 9-11 közt, aztán 9-10 közt hullámzott.Szóval bárhogy próbálom körbejárni, csak a 4db Y típusú kamera okoz zavart, és azok csakis egymás működésében. Nem fullad le tőlük teljesen sem az egész switch, amibe bekötnek, sem más eszközök, amik ebbe a switch-be kötnek be, egymást viszont megölik (1fejenként ~4Mbps is sok lesz nekik).
Mondjuk egy kifelé 8 vagy 9 portos switch odabent lehet pl. két darab 5+1 portos lapka, és talán ilyenkor az egyik ág lehal úgy, hogy a másik lapka felé is csak 10Mbps megy tovább, a másik ág viszont a többi porton 100Mbsp marad..? Viszont ha egy 10Mbps eszköz lefullaszt egy egész ágat, akkor a második ágat is ugyan úgy le kéne fullasztania a két lapka közti 10Mbps vonalnak, szóval...
(Persze ha nem egyforma lapkák... de két különböző típusú switch-el is ez van...)Ping-elni is próbáltam már a kamerákat 1472 byet-os csomagokkal, letiltott tördeléssel. Nem igazán lehet észrevenni, hogy épp megy-e rögzítés róluk egy szálon, vagy sem.
..................
Most valami olyan szálon próbálok előbbre jutni, hogy az ffmpeg és vlc vajon nem csak a saját, de az OS UDP stack buffer beállításait is átkonfigurálják-e, és volt-e esetleg olyan alaposan és ügyes valaki, hogy pontosan egy átlagos 1080p30 stream-re legyen elég, többre ne.
De próbáltam UDP-t használni azokkal a kamerákkal, amik nem reboot-olnak TCP-vel és mióta alaposan átrágtam a WiFi beállításokat, azóta mehet velük az UDP (tehát egyszerre 5db Y típusúval is jó az UDP, de ha ezeket leállítom, akkor sem jó 4db X típusúval). Szóval ez megint nem látszik vezetni sehová.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Azt hiszem fognom kéne egy passzív PoE adaptert és közvetlenül rákötögetni egyesével minden kamerát egy laptop-ra, megnézni, hogy úgy milyen kapcsolat áll fel (10 vagy 100Mbps, full vagy half duplex, van-e számottevő packet drop, ha úgy nekilátok rögzíteni fixen maximumra húzott videó bitrátával egyszerre több szálon...).
Vajon bármelyik passzív PoE adapter jó erre célra? Elfogják egyáltalán az 802.3af eszközök a passzív 48V-ot? Vagy esetleg etethetem ezeket átmenetileg a Mikrotik 24V-os passzív PoE adapterével? (Szinte biztos, hogy úgyis 12V-ot csinál a bemenetből és ilyen lenne kéznél...)
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#31855
janos666
nagyúr
Smktrooper
#31820
válasz
Smktrooper
#31820
üzenetére
Nem tudom, ROS Level3-al alapvetően csak Bridge-et lehet csinálni és Station Bridge módban nem biztos, hogy tud NAT-olni (és macerás, ha úgy derül ki, hogy reset-elni kell gombnyomással). Arra is gondoltam már, hogy veszek 4 passzív PoE adaptert és bekötöm őket egy 1000Mbps router-be és minden portot külön VLAN-ba rakok (próbaképp, mert amúgy pazarlás, semmi sem gigabites ott, mert nem is kell...).
Közben tuningoltam és teszteltem picit. Ezt tudja a helyi 1000Mbps hálózaton két gép egymás közt:
C:\WINDOWS\system32>iperf3 -u -c 192.168.1.101 -b 1000M -l1472
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 887 MBytes 744 Mbits/sec 0.016 ms 0/631606 (0%)
[ 4] Sent 631606 datagrams[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
bambano
#31857
üzenetére
Máshogy vannak kiosztva az érpárok? Csak a PoE injektort venném kölcsön, 48V-os adapter az van kéznél szabadon.
Egyébként úgy rémlik, hogy 12-48V közt fogadnak a kamerák (és még erre jön a +/-10%), de ez lehet hogy csak arra a verzióra igaz, amin lóg egy külön kis tápcsati is azon túl, hogy UTP-n is fogad af-es swith-ből 48-at (ezekben egy külön opcionálisan rendelhető modul az af tápleválasztó), és ezek pont nem olyanok (ezeknek csak RJ45 konnektoruk van).
---
Még egy kis update:
Fogtam itthon három különböző eszközt: egyik UTP-vel, másik 2GHz-es WiFi-n, a harmadik 5GHz-es WiFi-n csatlakozik (a WiFi-k jó jelerősséggel, idehoztam őket egy kupacba) és mindegyiken megnyitottam egy-egy kamera képét élőben VLC-vel és ugyan úgy szétesik a kép, mikor rányitok a harmadikra. Szóval nem OS stack buffer....
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
#27813376
#31945
üzenetére
Nem biztos, hogy működni fog, mert még csak Linux-os Samba-val csináltam ilyet, bár a konfigurálást Windows alól végeztem:
A legfelső mappának, amit megosztasz, állítsd be a legtágabb jogokat és alkalmazd minden "gyermekre" (azt hiszem így fordítják az "örökösöket", de angol felületet használok). A korlátozni kívánt almappáknál egyesével (a Windows-os grafikus felületen szerintem kénytelen vagy egyesével, mert ha többet jelölsz ki egyszerre, akkor másféle menüt hoz be a mappatulajdonságoknál, vagy legalább én nem tudom miként lehet ilyenkor előhozni a megfelelőt) tiltsd le az öröklést és szűkítsd a jogosultságokat.
Lehet, hogy Windows-nál ehhez az adminisztrátori megosztást kell használnod és/vagy le kell tiltanod a családi/otthoni módot (homegroup - az alternatíva, hogy felhasználói fiók alapján azonosítson), tehát egy, a "szerver" gépen (is) létező név/jelszó párossal kell elérni a kliensről a megosztott cuccokat, nem "vengég" (everyone, avagy "mindenki")-ként, mert azt a fiókot ki kell dobnod a jogosultak közül.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
#27813376
#31949
üzenetére
Legalább két eltérő néven futó fiók kell, és figyelni kell arra, hogy melyik gépen mikor melyik fiók van bejelentkezve helyben/távolról (távolra első körben azzal próbál bejelentkezni, amibe helyileg be vagy, és csak akkor kérdezi meg, hogy milyen néven szeretnél, ha ez nem nyer, szóval ha mindkét gépen megvan minkét fiók, akkor ezt össze lehet téveszteni).
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Tudja esetleg valaki, hogy a ZyXel GS-108B switch-nél pontosabban hogy működik a port alapú QoS?
A kiemelt portokon beérkező csomagok, a céljuktól függetlenül kapnak magas prioritást (és semmi más)?Az addig világos, hogy a kiemelt prioritású portokra kötöm az érzékeny eszközöket (valós idejű UDP csomagok), a normálra pedig az érzéketleneket (pl. WiFi AP). Na de hova kötöm a szervert? (Ami a helyi UDP csomagokat fogadja,de más eszközök számára a WAN felé is NAT-ol?)
Gondolom, hogy a Normal-ba, mert nem hiszem, hogy a fogadó irányra is érvényes lehetne a QoS (egyrészt ez talán túlmutatna egy unmanaged switch képességein, másrészt akkor a végére kvázi minden egyforma prioritásra kerülne, ha oda-vissza működne...)[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
abridabri
#33629
üzenetére
A "modern win"-nek sok beépített driver-e van (ezt azt jelenti, hogy rajta van a lemezen és kérés nélkül feltelepül a HDD-re is, nem azt hogy nem használ ilyeneket) és még többet le tud tölteni a Windows Update (ami nem elég széles körben használt eszköz ahhoz, hogy felkerüljön a lemezre, vagy még nem is létezett, mikor utoljára megjelent egy hivatalos Windows telepítő kiadás...), de utóbbi nyilván csak akkor működik, ha van működő internetkapcsolat.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#33653
janos666
nagyúr
Gubek-Einste
#33651
válasz
Gubek-Einste
#33651
üzenetére
Érdemes lehet megpróbálni feltelepíteni a driver csomagot kompatibilis módban és szükség szerint még kézzel a driver-t az eszközkezelőből.
A Win8 és 10 is kiírta, hogy a Dell féle custom ALPS touchpad Win7-es driver-e problémát fog okozni, de mégis jól működik (így lehet vele scroll-ozni is).
Ugyan ebben a régi Dell gépben retail Intel WiFi kártya van és tesz fel hozzá driver-t a Windows Update, ami az Intel szerint maximum Win7-ig volt jó, így gondolom talán más WiFi driver-ek sem váltak használhatatlanná a Win7 óta 10-ig bezáróan.Egy sokkal újabb Dell laposban (AC-s Intel WiFi) viszont sokszor szakadozott nálam a kapcsolat, miután egyszer frissített Intel WiFi driver-t a WU, így visszafelé is érdemes lehetett próbálkozni, ha nem "legacy" driver jár hozzá.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Van egy viszonylag triviális dilemmám, ami rég kísért, mert nem látom át teljesen a dolgot. Ma más miatt át kellett néznem a tűzfalszabályokat és megint fennakadtam ezen a soron (*nat):
-A POSTROUTING -j MASQUERADE
A leírás, amit annak idején a nulláról indulva követtem (Gentoo WiKi - Home Router), az általam is érthető következességgel a WAN interfészre limitálja ezt a szabályt:iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE
... viszont később praktikus okokból fontossá vált, hogy a külső DNS címen át (ami dinamikus IP-re mutat) is el lehessen érni pár gépet a helyi hálózaton belülről is (hogy el lehessen menteni a DNS címet a hordozható eszközökön és bárhonnan működjön az elérés). Mikor feltűnt, hogy ez nem működik, hamar eljutottam oda kis olvasgatással, hogy miért, és ekkor egyszerűen kivettem ebből a szabályból az interfészt, majd úgy is veszett "örökre", miután működni kezdett a dolog és azóta is furdal picit, mikor meglátom, hogy van-e ennek valami számottevő hátránya (akár biztonság, akár teljesítmény szempontból). Abszolút nyugodtan hagyhatom így, vagy mit nézzek meg, mint "szélsőséges eset", ahol ez számíthat (csak nem biztos, hogy eddig épp kiszúrtam, ha gondot okoz)?És ha már írok, egy másik furcsaság, ami régóta így van (csak azért nem üldöztem sokat a bakit, mert pont elég az 5Gbps is). Idő közben már kicseréltem egyszer a NIC-eket a két gép közt (kíváncsiságból, hogy ez megfordul-e) és kábelcsere is volt (mikor hosszabb kellett), de mindig ebbe az irányba asszimetrikus a sebesség:
PS C:\Program Files (user)\iperf-3.1.3-win64> .\iperf3.exe -c 192.168.1.11
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 5.22 GBytes 4.49 Gbits/sec sender
[ 4] 0.00-10.00 sec 5.22 GBytes 4.48 Gbits/sec receiverPS C:\Program Files (user)\iperf-3.1.3-win64> .\iperf3.exe -c 192.168.1.11 -R
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 11.0 GBytes 9.42 Gbits/sec 0 sender
[ 4] 0.00-10.00 sec 11.0 GBytes 9.42 Gbits/sec receiver(A "szerver" oldal Gentoo Linux, a "kliens" Windows 10)
Az egyetlen "babrálás" linux oldalon van a QoS miatt, minden más alapértelmezett konfiggal fut:
ethtool -K enp1s0 gro off
Erre állítólag szükség van akkor is, ha csak a WAN felé akarok fq_codel-t és HTB-t.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
janos666
#41775
üzenetére
Hopsz, a második kérdést végül is megválaszoltam magamnak, a GRO tehet róla, de a fura az, hogy ha akkor tiltom csak le a GRO-t, ha már fut az iperf, akkor linux szerver oldalon mindkét CPU mag ~100%-on dolgozik (kis Pentium G4400) és ~8Gbps-t mérek, míg ha úgy indítom az iperf-et, hogy már tiltva van a GRO, akkor az egyik mag gyakorlatilag idle, és a felére esik a mért sebesség. Ez valami nem várt, vagy ismert jelenség? Van rá valami áthidaló megoldás?
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Mi lehetne arra a megoldás, hogy mikor Windows 10 kliensen törlök nagy file-okat (több 10 giga), ami a Linux + Samba 4.x (minden viszonylag friss verzió, Linux és Windows oldalon is, de igazéból évek óta ilyen, nem verzióspecifikus probléma) szerver oldalon sokáig tart (Btrfs-el néha nagyjából addig tart törölni egy file-t metadata szinten, mint ameddig szekvenciális írással tart felírni annyi adatot, szóval akár percek kérdése is lehet mondjuk ~100Gb), akkor a művelet végéig "megfagy" a Windows filekezelő?
Ha szerver oldalon kezdek el nagy file-okat törölni (pl. ssh-ból rm parancs), akkor Windows kliens oldalon normális sebességgel lehet tallózni a mappákat és olvasni a file-okat, szóval nem a filerendszer és/vagy I/O-scheduler (bfq-mq) ragad bele teljesen a törlési műveletbe, hanem maga a Windows filekezelő (mereven vár, míg véget ér a törlés, addig semmi mást nem enged).
Windows kliens vagy Linux szerver oldalon kéne babrálgatni valamit?
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Des1gnR
#43068
üzenetére
Mert az a paraméterezés logikája, hogy Auto-val elérheted az 1G-t, mikor lehetséges, a többi pedig arra való, hogy lentebb korlátozd ha valamiért szeretnéd. Szóval végül is elérhető minden.
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
Pubszon
#43113
üzenetére
Az a gond, hogy alapértelmezésben a WAN interfészre érvényes csak a NAT.
Ha custom firmware vagy linux lenne, akkor így kéne átírnod:iptables -t nat -F
iptables -t nat -A POSTROUTING -j MASQUERADE
Most viszont így néz ki:
-A POSTROUTING -o WAN -j MASQUERADE
(Az a WAN persze gyakorlatban inkább eth1, enp1s0 vagy vlan_wan1, stb).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
MaCS_70
#43131
üzenetére
Szerintem teljesen logikus és kényelmes is, hogy egy LAN = egy SSID, ha van fizikailag átfedés (belenyúl egymásba a két rádió által fedett terület), ha nincs (pl. két külön épület közepén egy-egy 5G rádió). Már akár csak azért is, hogy a mobil kütyükön is kezelhetőbb legyen a hálózati lista (nem mindenkinek 1234 a WEP jelszava, van akinek 30 random karakter a WPA2 és nem mindig megy a copy-paste, illetve tiltott a WPS, szóval percek kérdése bepötyögni és mondjuk amúgy sem akarsz 5+ redundáns bejegyzést látni a listán, főleg mobilon).
A kliensnek mindig meg kéne tudnia különböztetni a MAC cím alapján az AP-t, vagy ha azonos a MAC, akkor az általában szándékos (valami prorpietary seamless roaming megoldás). Ezzel együtt pedig letilthatod az egyes AP-kről az egyes kliens MAC címeket, ha szeretnéd őket egy bizonyos AP-re erőltetni.
Mondjuk a lenti eset nekem is azt sugallja, hogy szándékosan már SSID-t szeretne a tulaj (neki biztos így egyszerűbb, mint MAC alapján tiltogatva terelgetni, vagy talán még csak nem is egy LAN az).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
Mi lenne a legegyszerűbb/szebb megoldás arra, hogy okostelefonról elérjek gagyi okoseszközöket, mint pl. légkondicionáló, RGB-LED falilámpa, stb, amik csak archaikus WiFi szabványokat támogatnak (pl. erősen limitált hosszúságú jelszót), ezért nem akarom őket úgy felengedni a meglévő helyi hálóra, hogy mást is elérnek (hogy még a szomszéd kisgyerek is feltörje a jelszót egy Kali-s okostelefonnal és elkezdjen TickTok videókat megnyitni a TV-men)?
Leporoltam egy régi TP-Link WDR4300-at és raktam rá friss OpenWRT-t.
A házi szerveren (ami a WAN router és DHCP szerver) Gentoo fut és van rajta egy kvázi-szabad LAN port.Gondolom onnan indulnék, hogy létrehozok egy VLAN-t az "új" router-nek, aztán beállítok rajta egy 2.4GHz WiFi-t, amire még a trabantrádió is tud csatlakozni, aztán...?
Hogy NAT-olok és/vagy tűzfalazok úgy a VLAN és LAN közt, hogy a telefonon lévő faék alkalmazás látja a légkondit, de mást nem?Vagy ez spéci/bonyolult dolgok nélkül nem is működik úgy, hogy nem lépek át átmenetileg a telefonnal a dínók router-ére?
Vagy hogy szokott ez működni? Interneten át is elérhetők ezek, és akkor elég WAN-ra NAT-olni a dínóVLAN-t, a telefont a meglévő LAN-on hagyni, és "körbejárják a Földet" az adatcsomagok telefon és légkondi közt?A fent említett okok miatt nincs ezzel tapasztalatom, hogy mit csinálnak ezek a WiFi-vel.
Szer.: Oh, mondjuk ha switch-en nem is megy keresztül, akkor VLAN sem kell, csak egy külön dínóLAN.
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#66272
janos666
nagyúr
MasterMark
#66271
válasz
MasterMark
#66271
üzenetére
WAN <-> Gentoo PC <-> WiFi-AP-k és kábeles PC
Még azon gondolkozom, hogy kell-e két UTP kábel is az új WiFi AP felé, ha esetleg úgy helyezném el, hogy a kertbe szórja a main LAN-t is WiFi-n (pl. azt 5GHz-en).
Nagyjából sejtem hogy működik a VLAN, de még sohasem állítottam be.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
válasz
csaszi75
#66273
üzenetére
Ezért értetlenkedek, mert én sem tudom mit csinál a WiFi-vel a légkondi/falilámpa, még sohasem engedtem fel ezeket egy "password" jelszavas SSDI-n LAN-ra.
A "routeren" (PC, amit "házi szerver"-nek hívok, mert router és NAS is) van 1 szabad UTP port (összesen 5 van, az alaplapi a WAN, a 4 portos kártya a LAN).
#66274MasterMark
A Gentoo-s x86 PC NAT-ol, iptables-el tűzfalaz (és még miegymás).[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#66277
janos666
nagyúr
MasterMark
#66276
válasz
MasterMark
#66276
üzenetére
Kb. 10 éve raktam ezt így össze (persze azóta cserélődött pár hardware és kalapálódott a szoftver, de akkor "született" a konstrukció). Ezen okokból:
- Zavart a HDD-k hangja (passzív vízhűtés és félpasszív túlméretezett táp mellett), így akartam egy NAS-t, de nem akartam "lefojtani" a többlemezes RAID sebességét.
- Nem volt még mainstream 2.5 Gb ethernet UTP-n, de találtam Ebay-en két Mellanox kártyát optikai modulokkal olcsón. -> Kész volt a gyors NAS.- Az akkori megfizethető SoHo router dobozok rohadtul nem bírták a QoS-t / traffic shaping-et lekezelni az internetcsomag sebességén pl. sok torrent futtatása mellett.
- Egy olcsó AMD Bulldozer ezt röhögve bírta, bármiféle qdisc és prio csokorral. Kész lett a gyors router.- Mindig utáltam a gagyi kínai IP kamera rögzítődobozokat. -> Ez is mehet a "szerverre".
- Software RAID helyett sokkal jobban tetszett a Btrfs RAID (cheksum miatt tudja, hogy melyik másolat a jó és melyik a rossz akkor is, ha a lemez téved/hazudik - mondjuk később a HDD-ket is olcsón szerzett datacenter modellekre cseréltem, de akkor nem az volt).
- És még sorolhatnám (pl. mindig szemeztem egy VPN-el is, de sohasem jutottam el addig, 5 éve próbálom magam rávenni, hogy csináljak magamnak egy minimalista weboldalt, és nem akarok fizetni a hostingért, stb... ezt is elbírná a Pentium CPU is napi 0.1 látogatóval).
Nem érzem mazochizmusnak. Szinte mindenre volt WiKi leírás (többnyire a Gentoo WiKi-n is, de ha nem, akkor az Arch-én, régen még aktívabb volt az élet a Gentoo körül). Könnyű lenne bővíteni bármivel (ha nem lennék lusta dög, akkor lennének ötletek, pl. a fent felsoroltak, vagy még pl. NVMe SSD caching a HDD-s RAID tökmbnek...).
[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
-
#66279
janos666
nagyúr
MasterMark
#66278
válasz
MasterMark
#66278
üzenetére
5 perc volt beállítani a WireGuard-ot, de aztán rájöttem, hogy IKEv2-t akarok, mert azt támogatja natívan a Windows és az Android is. Aztán elakadtam az SSL résznél.
"Ezt most mi csinálja nálad?" -> Még mindig a Gentoo-s PC. Mondom, sok dolgot már rég csinál, és van sok limbó dolog, amit csinálhatna.
Igazából egy A4 lapra elférne minden config paraméterezésem, és mindent megold, amire szükségem van, vagy limbóban vár.[ Szerkesztve ]
TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."
Új hozzászólás Aktív témák
- Anglia - élmények, tapasztalatok
- Konzolokról KULTURÁLT módon
- BestBuy ruhás topik
- Milyen billentyűzetet vegyek?
- 3D nyomtatás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Microsoft Excel topic
- Fujifilm X
- További aktív témák...
- 1151 V2 CPU-k / I5-8500 / I5-8400 / BESZÁMÍTOK!
- Intel i5-10400 hatmagos processzor + doboz + gyári új hűtő
- Nintendo Switch játékok (ง '-' )ง Budapest Nyugatinál
- Fekete Sony PlayStation 5 Cover (Lemezes változat)
- Samsung Galaxy S23 Ultra 5G 256GB Dual SIM Phantom Black Gyárilag független Csere/beszámítás is!