- Augusztustól nagyot változik a Shein élete
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Hálózati / IP kamera
- 3 évig még biztosan nem rendelhetünk Xiaomi EV-t
- DIGI internet
- Agyi chipes gyártóba fektetett a kriptocég
- Az Apple iPadOS-t is megrendszabályozza az EU
- Milyen routert?
- Ingyenes vagy akciós szoftverek
- WLAN, WiFi, vezeték nélküli hálózat
Új hozzászólás Aktív témák
-
#11
shabbarulez
őstag
Sidaries
#2
shabbarulez
őstag
Ez így sajnos nagyon nem igaz. Nálam LAN van 512/512-es netelőfizetés és igenis jól jönne egy olyan proggy ami Win alatt csinálna normális csomag priorízálást és shapinget ahogy a Cfos teszi, mivel az Op.renszer erre default nem képes. És ez ugyanúgy igaz nagyobb sebességek mellett is, minden kapacitás bedugul ha erősen terhelve van.
-
#25
shabbarulez
őstag
#54715584
#22
shabbarulez
őstag
válasz
#54715584
#22
üzenetére
Juj de nagy marhaság ez. Ha neked a 384-es neted 60k-val tud tölteni ahhoz semmi köze hogy te mit ügyeskedsz a gépeden, hanem az számít szolgáltató milyen profilet állított be és az mekkora sebességet tesz lehetővé, esetleg 512-nek állítottak be tévedésből és most ennek örülhetsz. A nagy számok törvénye alapján bőven lehetne ilyen tévedések, de ennek semmi köze ahhoz te mit gépészkedsz a beállításaiddal. Mellesleg az a QoS 20%-nak semmi hatása nincs a maximális sebességre, ez csak egy mítosz ami tévesen kerint a neten időtlen idők óta.
[Szerkesztve] -
#30
shabbarulez
őstag
#54715584
#27
shabbarulez
őstag
válasz
#54715584
#27
üzenetére
Többféle profile van beállítva pl. fatáv DSLAM-jaiban és ezek a különböző típusú modemekkel párosítva még vegyesebb végeredményt szülnek.Volt idő amikor próbálkoztak egy egységes sebesség kikisérletezésére de szerint idővel rájöttek túl sok macera lenne vele. 384-es csomaggal így lehet hogy van akinél 48k-val jön van akinél 50-52-vel van akinél 56 vagy 60 is mérhető. 512-es profileoknál is elég sok variáció van 63k-68k közötti sebességeket produkálva.
Ezen kívül a az is bőven megtörténhet hogy egy olyan előfizetőnek aki 384-es csomagot rendelt tévedésből 512-est állítanak be. -
#57
shabbarulez
őstag
ReN
#56
shabbarulez
őstag
Semmi köze nincs hozzá cfos-nak, hétvégén és hételején a monorteles előfizetők egy részénél terheléses tesztet végeztek, ezért volt 1500/384-es sebességed. Pontos infó nincs, de tippre ugyanazt játsza el UPC mint anno suxelero közös sebesség szintre hozza kábelnet és dsl portfóliót és a jelenlegi 384/64-es dsl 768/256-re emelkedik.
-
#251
shabbarulez
őstag
dchard
#249
shabbarulez
őstag
Telepítés után az első újraindításig az általad említett két menüpont szürke, úgy néz ki ez a programnál normál működésnek számít. Az adott beállítást pedig azért nem találhattad meg az ini-ben mert egy régi verziót használsz ahol ez még nem létezett. Abban a verzióban még fixen bele van fordítva a cím, nem ismer ilyen paramétert az ini-ből a program.
-
#254
shabbarulez
őstag
shabbarulez
őstag
Milyen profile sebességek vannak a modemben beállítva? Olyan csodát ne várja a cfos-tól hogy párhuzamos töltés mellett mindkét irányba nettó ugyanazt hozza mint külön-külön. Bruttóban közelíteni tudja a max elérhetőt, a nettó sebességek pedig a TCP működési sajátosságai szerint alakulnak. Ha töltesz 275k-val akkor 1500-as MTU érték mellett csak az ACK csomagok 11k-t elvisznek az uploadból azzal hogy visszaigazolják a letöltött csomagok megérhezését.
-
#256
shabbarulez
őstag
dchard
#255
shabbarulez
őstag
Ha netezel akkor ki kell békülnöd az azt működtető protocolok működésével. A TCP pedig küld visszaigazoló csomagot ami jellemzően 60 bytes. Az MTU mérete pedig jellemzően 1500. Így a visszaigazó csomagok a legoptimálisabb esetben is minimum 1:25-öd sávszél kívánnak meg vagy többet.
A feltöltést 1xű limitálni hisz azt a gépeden korlátozni tudod hány csomag menjen ki mekkora méretben. A letöltést már nem ilyen 1xű hisz ebbe a célszervernek direkbe nem mondatod meg hogy mekkora mértékű adatmennyiséggel küldjön feléd.A visszaigazolási adatcsomagok időzítésével és egyéb paramétereket változtatgatásável lehet némi hatást gyakorolni(hisz te csak ezekre tudsz hatást gyakorolni) de ez közel sem ad tökéletes megoldást.Ha pl. megnézel olyan általános programokat mint pl. letöltésvezérlőnél FlashGet akkor láthatod hogy ez 128k-s limitálás esetén nem egy stabil és egyenes töltési diagrammot kapsz hanem egy jól ismert fésűfog képet. Mivel ezek a limitálások átlagra kiadják a célértéket de ezt nem egy statikus eredménnyel érik el. Egyes FTP szervereknél látommal már olyat is hogy 60mp-es időegységgel dolgozott vagy 30mp-ig töltött full speed majd újabb 30-ig áll és így kijött az átlag 50%-ra koltátozott letöltési sebesség. Flashgetnél jóvel kisebb az időszelet de a fésűfog ott is megfigyelhető. A lényeg az hogy a feltöltési oldali trükközéssel nem lehet tökéletes letöltés korlátozást elérni és ezzel a feltöltött adatmennyiség sem fog arányosan csökkeni. Ezért te hiába limitálod le a letöltést attól még az upload ACK nem fog ezzel arányos csökkenést produkálni, ez többnyire inkább csak a ''fölös'' de már megérkezett adatcsomagok eldobását fogja jelenteni, nem pedig a valós adatmennyiség csökkenést.
Ha már ennyire figyelni akarod azt javaslom egy olyan programmal figyeld ami a bruttó sebességeket jelzi ki ne pl. egy FTP program sebesség mérőjét ami nettó sebességeket ír ki. Pl. a DUMeter jól jelzi az interfaceen áthaladó bruttó sebességet. -
#258
shabbarulez
őstag
dchard
#257
shabbarulez
őstag
Bruttó sebességgel mennie kell. Az illető gondolom pl. DUMeterrel nézte az interfacen áthaladó forgalmat és úgy megvolt a kellő adatmennyiség. De az is lehet az illetőnek kevésbé asszimetrikus volt a kapcsolata ezért tudta jobban megközelíteni a korlátokat. Pl. egy 512-es link profileja ha jól emléxem 608/128-as szokott lenni ami jobb arány mint a 2mbps-es esetén.
Utólag mindig könnyű okosnak lenni. Anno 90-es évek elején amikor az ADSL szabványba belefogtak még sehol nem volt p2p, a magas upload igénye nem igazán volt döntő érv a tervezéskor, úgy voltak vele hogy akinek az fontos az vegyen bérelt vonalat. Az ADSL szabványok pedig azóta csak még asszimetrikusabbá váltak mert az elsődleges igény továbbra is a download maximalizálása volt mert a felhasználók nagyobb arányban ilyen jellegű tevékenységre használták a kapcsolatot. Persze az idők változnak és ma már a masszív p2p használat mellett más dolgok is képbe kerültek, mint pl. videotelefon, digitális képek továbbítása, távmunka. Az új szabványok kialakításakor ezt ma már azért figyelembe veszik, persze a korábban kialakított korlátok soxor szűk keretek közé szorítják a lehetőségeket.
A másik dolog a szolgáltató oldaláról hogy engedélyezi a csomagokat abban az esetben ha a hardware lehetőségek adottak. Itt azért elég erősen befigyel a p2p problematika amitől azért tartanak a szolgálatók. Ugye az egy nem túl életszerű, legalábbis elég ritka eset hogy a felhasználó a nap 24h-ban tölt lefelé. Ezt legtöbbször csak addig teszi amíg szüksége van egy adott dologra, pl. meg akar nézni egy filmet. De ezt a tevékenységét csak korlátozott ideig teszi hisz nem néz állandóan filmeket, mondjuk havi 4-6 filmet megnéz mert ennyi szabadideje van. Viszont ugyanezt a usert semmi nem korlátozza abba hogy a gépét magára hagyva akár egész nap p2p-t hostoljon a nagyvilágnak. Ha mindenkinek szimmetrikus kapcsolata lenne akkor ezzel keményen szembesülnie kellene a szolgálatatóknak. Ez is meg a hardwareből eredő korlátok együttese belejátszik abba hogy nem túlzottan erőltetik a nagy uploadú kapcsolatokat. Ez a trend világszerte alig egy éve kezd folyamatosan megtörni, idővel ez majd hozzánk is begyűrűzik ahogy a többivel is ez volt.Persze a hardware adta korlátokat nem lehet átlépni de az olyan csomagok ahol úgymond 'bedobják a gyeplőt'' és hardware adta korlát sebességein szolgáltatnak igen elterjedt csomagstruktúra.
Persze az igazi alternatívát egy FTTN+VDSL2 combo vagy egy full optikai infrastruktúra jelenti, 1x majd ennek is eljön az ideje, reméljük még a mi életünkben. -
#354
shabbarulez
őstag
shabbarulez
őstag
Kinek van olyan tapasztalata hogy a CFosSpeed(nálam 2.12 van fönt) összeveszik egy VoIP alkamazásokkal. Nálam az X-lite és EyeBeam nevű VoIP alkamazások vannak feltelepítve és ez a kettő nem csípi egymás a Cfos állandóan kékhalálba viszi a gépet.
A probléma az ha a VoIP-os alkalmazások benne vannak a priorizált programok között high prioritybe, ahogy értelme lenne akkor a beszélgetés végén hang up-kor a kékhalált csinál az XP a cfosspeed.sys által. Ha kiveszem a priorításból ezen programokat akkor a jelenség megszűnik de ezzel pont azt veszítem el ami a program célja lenne.
De még így sem kerek a működése. Pl. most teszteltem egy olyan hogy vezetékesről felhívtam a KLIP-es hívósámomat. Az EyeBeamben konferenciára a második vonalon pedig ugyanezt a vezetékes hívtam volna amin már beszélek. Ez ugye foglaltat kellett volna hogy jelezzen. E helyett ismét a kékhalál köszöntött, szintén cfosspeed.sys által.
Az XP-vel nincs gond az elmúlt jó két év alatt 1x sem halt, be kékhalált végképp nem produkált. Egyedül a Cfosspeed, X-lite vagy EyeBeam páros vágja haza és ott is a Cfos rendszerfileja az ami a felelős.
A hibajelenségem nem egyedi, NeoPhoneX fórumon többek írtak hasonló jelenségről, és guglival rákeresve máshol is lehet látni visszajelzést.
Kérdés az tud-e valaki erre megoldást, esetleg az új 2.13-as betákban javítva van-e ez a bug?
Azóta ma is fagyott egy VoIP használattól, több kékhalált láttam a VoIP használat mellett az elmúlt pár napban mint az elmúlt években összesen. Szóval ez így nagyon nem jó. Most vajon csak az X-lite és Eyebeam klienseket nemszerete CfosSpeed vagy globálisan az RTP-vel akad össze? -
#408
shabbarulez
őstag
shabbarulez
őstag
Valakinek van már tapasztalata az új 3.00-ás verzióval? A régi 2.12-höz kapott licencet vajon az is megeszi? Majd hétvégén ha lesz jobban időm felrakom az újat, de addig is ha valaki már gyorsabb volt nyugodtan megoszthatja a tapasztalatait.
-
#470
shabbarulez
őstag
Winner_hun
#469
shabbarulez
őstag
válasz
Winner_hun
#469
üzenetére
[link]
Hogy a hullám mi az passz, szerintem inkább csak ilyen látvány cicoma. -
#673
shabbarulez
őstag
birno
#672
shabbarulez
őstag
Nagyon ingadozó sávszél mellett a cfos nem igazán használ semmit, hisz nem tudja megfelelően optimalizálni a sávszélt. Az optimalizáló figyelője igazából csak felfelé skáláz, így ha ez az értél időszakosan megugrik majd visszatér egy tartsó átlagosra akkor azt már nem fogja rendesen kezelni. Nekem is ez volt vele gondom hogy a szolgáltatónál nincs rendes shaping a maximum sebességre csak rate limit ami nagyon EKG-s maximum sebességet ad, sőt egyes IP tartományok felé LAN-os nagyobb sebesség van ami után teljesen meghülyül a működés a normál netes tartományok felé. A cfos igazából ott ad jó eredményt ahol nincs ingadozó maximum érték, a szolgáltató fixen és shapelve limitálja a maximum sebességet mert ott viszonylag jól be tudja lőni a program milyen határértékkel dolgozzon.
Állítani consolból tudod az spd speed paranccsal tudod lekérdezni és utána az egyes változókat tudod manuálisan átállítani. De ha ingazodó a kapcsolat akkor ezzel nem sokat érsz max beállítod kézzel és fixre állítod. Viszont ez sem tökéletes mert nem minden változó fix, annak ellenére is túlcsordulhatnak és akkor megint felborul a rend.
Egyébként kijött az új 4.0-ás verzió amiben már multi-pc támogatás is van.
[link] -
#675
shabbarulez
őstag
birno
#674
shabbarulez
őstag
Amit te állítasz azok az alkalmazás típusok priorításai, hogy melyeket engedje előrébb, mely adatfolyam minősül fontosabbnak és élvez elsőbbséget. A gond nem ott van hanem a cfos traffic shaping alap beállításai körül. Ha megnézed a fenti linket akkor megtalálod Dchard leírását a cikk linkjei között amit már ide is kismilliószor be lett linkelve. Ott van egy részletesebb leírás a beállásra. Amiről én beszélek az már eléggé a macerás beállítások közé tartozik, az spd-vel indított konzolba kell turkálni és belső váltózókat kézzel állítgatni és érteni is kell mit csinálsz. Dchard oldalán valamennyire le van írva mi micsoda én is onnan lestem ki anno.
-
#829
shabbarulez
őstag
delta9
#822
shabbarulez
őstag
Át kell állítani a cfos-t hogy ne a 2. hopot, hanem az elsőt vagy a 3.-at pingelje. Sok szolgáltatónál egyes routerek pingelése le van tiltva vagy csak korlátozott darabszámra válaszol 1 mp-en belül. Ez főleg a cfos megjelenése óta van így mivel a program elég erőszakosan akár 4-5 pinget is küld egy mp alatt és ez folyamtosan végzi. Egy nagyobb szolgáltatónál ahol több száz ezer user van és sokan használnak ilyen proggit, az már elég nagy számú ping floodot eredményez amik mind azonos routert céloznak meg. A routerek elsődleges feladata pedig nem a pingek válaszolgatása, hanem az hogy routoljanak, ezért hogy ne foglaljon a válaszolgatás felesleges erőforrásokat a 2. hop-on amit alapbeállításba megcéloz a cfos jellemzően tiltják az icmp-t. Igazából a cfos-t a legelső hop késleltetése érdekli, de azért van alapból 2.-re állítva mert elég sok usernek van soho routere és abban az esetben a 1. hop lényegtelen a program szempontjából.
-
#831
shabbarulez
őstag
delta9
#830
shabbarulez
őstag
Ha a legelső hopot pingeled akkor az érzékeli hogy ő a célállomás és válaszcsomagot küld, de csak akkor ha ez a képesség épp nincs letiltva vagy korlátozva benne. Ha a másodikat pingeled, akkor először az első hop kapja meg az adatcsomagot, érzékeli hogy nem ő a célállomás és tovább routolja a következő hopnak, az érzékeli hogy ő a célállomás vagy válaszol vagy nem konfigurálástól függően. Ha a harmadik hopot pingeled akkor az első kettő érzékeli hogy nem ő a célállomás és tovább routol, a harmadiknál ér célt az adatcsomag és vagy küld válasz vagy csak lenyeli beállítástól függően. És így tovább.
A te gépeden is ha a tűzfal úgy van bekonfigurálva hogy válaszoljon az ICMP adatcsomagokra, akkor ha megpingelem a gépedet akkor válaszcsomagot fog küldeni. De ha a tűzfalodon tiltod a válaszküldés, akkor a géped a beérkező ICMP csomagokat lenyeli és nem foglalkozik válaszcsomag küldésével. Ezt az én gépem úgy érzékeli ha adott időintervallum után sem kap tőled választ(timeout) akkor elveszett csomagként fogja elkönyvelni és a késleltetési idő helyett a kis csillagokat fogja kiírni.
Attól mert a 2. hop routere nem értékeli ki és válaszol az ICMP csomagokra, attól még a fő feladatát elvégzi és ha kell továbbroutolja az adatcsomagokat a következő állomásoknak. Épp ezért a 3. hoptól az ICMP kiértékelés ugyanúgy megtörténik ha azok válaszolnak, pont úgy ahogy a te esetedben is látható.
Neked szerintem az első hopot kellene nézned és a cfost úgy konfigurálni hogy csak egyetlen hop távolságig nézze a késleltetést(spd sethops x). Persze csak akkor ha az első hop rendesen válaszol és nem dobálja el a kéréseket, ez ki tudod tapasztalni.
-
#833
shabbarulez
őstag
delta9
#832
shabbarulez
őstag
"Útvonal követése a következőhöz: www.cfos.de [194.95.249.23]
legfeljebb 30 ugrással:
1 44 ms 34 ms 8 ms catv-c3b8ba9e.catv.broadband.hu [195.184.186.158]
2 * * * A kérésre nem érkezett válasz a határidőn belül.
3 62 ms 9 ms 8 ms 195.184.167.9
....."Ahogy láthatod a saját tracedből az első hop is válaszol, az a "fejállomás" a környékeden, CMTS az eszköz neve, így néz ki:[link]
A cél IP nem olyan lényeges, ha az alap kplay.de oldalét hagyod meg akkor is ugyanazokat fogod kapni az első néhány hopnak, a cfos ebből csak azt az egyet figyeli amit a sethops-ban beállítasz a többivel nem foglalkozik. De érdemes a cél IP-nek azt a hopot megadni ami a sethops értéke szerint figyelve lesz, mert némileg máshogy működik az ICMP kiértékelés a két esetben.
-
#836
shabbarulez
őstag
delta9
#835
shabbarulez
őstag
Akkor hagyd a cél IP-t az eredeti cfos.de-n, és hop-ot állítsd 1-re. A magyarázat arra hogy a pingre nem válaszol és a tracertre igen, a hálózati eszköz beállításában keresendő.
A ping úgy működik hogy az adott cél IP-re elküld egy ICMP adatcsomagot. Egy ICMP csomagnak többféle üzemet típusa van, ez a csomagba van kódolva. Amikor küldi az ICMP-t a célnek akkor egy echo request-et, vagyis egy visszhang kérés típusú üzenetet küld. Amikor ezt megkapja a célállomás és úgy van beállítva hogy erre válaszoljon, akkor visszaküld egy echo reply, vagyis egy visszhang válasz típusú ICMP csomagot. Amikor a géped megkapja a válaszcsomagot közben mérte az elküldés és a visszaérkezés között eltelt késleltetés és ezt írja ki a ping parancs. Ha a célállomás nem válaszol akkor adott időtartam után(timeout) nem vár tovább és elveszettnek tekinti a csomagot: "A kérésre nem érkezett válasz a határidőn belül."
A tracert is a ping parancsot használja a köztes állomások felderítésére és késleltetéseinek kiírására, de ezt trükkösen teszi. Mivel a géped azt nem tudhatja hogy a célállomásig milyen IP-vel rendelkező routerek vannak, ezért közvetlen ping parancsot nem lehetne küldeni ezekhez. Ezt úgy oldja meg a tracert hogy a TTL(Time to live) mezővel játszik. Minden adatcsomagnak van TTL mezője amiben induláskor ez szám kerül, ami minden egyes alkalommal amikor áthalad egy routeren egyel csökken. Ha eléri a nullát akkor az az adott router ahol ez megtörtént visszaküld neked egy olyan ICMP válaszcsomagot aminek az üzenet típusa TTL exceeded. A TTL-re azért van szükség hogy ha valami ok miatt egy adatcsomag nem ér célba, akkor ne bolyongjon az idők végezetéig a hálózatban, hanem mivel minden router egyes csökkenti az értékét, ha nullára fut kvázi a csomag "elhal", az adott eszköz eldobja és nem foglalkozik vele tovább.
Szóval a tracert azt csinálja hogy küld a ping csomagot a cél IP-nek(ami tegyük fel 12 hop távolságra van, mint a példádba a cfos webszervere), de úgy hogy a TTL-t először egyre állítja. Ezt megkapja az első router a TTL-t egyel csökkenti ami ezzel nullára fut, ezt a router érzékeli és visszaküld neked egy TTL exceed válaszcsomagot. Mivel ezt maga a router küld a feladóban ott lesz az IP címe, és a késleltetés és mérhető. Ezt 3x megismétli a tracert ez az amit a első hopra kiír a tracert parancs. Utána ezt ismételgeti a tracert emelkedő TTL értékekkel így jutva el egyre távolabbi hopokig, egészen addig amíg cél IP-vel meg nem egyezik a válaszoló gép IP címe. Így alakul ki az általad is látható tracert parancs végeredménye.
Nálad az első hopnál ami a CMTS, a echo reply üzenetet küldő ICMP válasz le van tiltva, ezért nem válaszol a ping parancsra, de a TTL exceded nincs, ezért van hogy a tracertben viszont megjelenik. A cfos is hasonlóképpen mér késleltetést ahogy a tracert, a beállított cél IP-re pingel egyet, de a TTL-be a sethops-nál beállítátt értéket teszi, vagyis csak az x. hopra kíváncsi.
-
#838
shabbarulez
őstag
delta9
#837
shabbarulez
őstag
De mindegy. Ezt írtam eddig is, hogy hagyd nyugodtan alapértelmezetten dest ip-t ami a cfos.de weblapjára mutat, hisz oda sosem fog elérni, mert alapértéken kettő a sethops. De mivel a kettő neked nem jó a upc eszköz beállításai miatt, ezért rakd át inkább egyre, vagy ha ez nem válik be akkor háromra. Igazából minél közelebbire érdemes rakni, ha az rendesen válaszol, csak alapesetben azért nem rakják egyre, mert akinek otthon van kis broadband routere, mert a lakásában osztja a netet, az mindig az pingelgetné, de az a pont a cfos rendes működése szempontjából nem megfelelő, hisz ott még nem lépett kis az adatcsomag szolgáltató hálózatába.
-
#844
shabbarulez
őstag
ballington
#842
shabbarulez
őstag
válasz
ballington
#842
üzenetére
#822-től olvasd el a topicot, nem olyan rég volt róla szó, ezért kár volt külön topicot nyitni.
Új hozzászólás Aktív témák
- VR topik (Oculus Rift, stb.)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Mibe tegyem a megtakarításaimat?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kerékpárosok, bringások ide!
- Óra topik
- Ukrajnai háború
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Formula-1
- Milyen CPU léghűtést vegyek?
- További aktív témák...
- Samsung Galaxy S22 Ultra Eladó...
- Vostro 3591 15.6" FHD i5-1035G1 GeForce MX230 16GB 512GB NVMe magyar bill., gar
- ELADÓ 32 DB Nvidia RTX 3060 Ti és 8 DB Zotac Gaming Geforce RTX 3080 Trinity / KOMPLETT BÁNYAGÉP
- Intel NUC5CPYH (Celeron N3050, N3060, J3060) - 4GB RAM, 120GB SSD
- Corsair TX650 V2 650W 80+