- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Lassan Quake-ezni is lehet rajta :D
320 Mbps down, 20 Mbps up egyáltalán nem rossz ...
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Mármint per műhold? Mert az nem tűnik soknak, főleg ha pl 5-en használják egyszerre és abból csak 1 torrent mániás.. :D
- A hozzászóláshoz be kell jelentkezni
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Valami régebbi cikkből rémlik, hogy mivel fix távolság van a műhold és a Föld között, így lesz egy minimum késleltetés, ami nekem valami 320ms-nél dereng.
De fixme.
- A hozzászóláshoz be kell jelentkezni
szerintem a geostacinarius muholdra gondolsz, az joval a spacex magassaga felett van.
- A hozzászóláshoz be kell jelentkezni
1 millisec az 300km, igy alacsony fold koruli palyan (500...800km) keringo muhodaknal azert az RTT olyan 5-6millisec koruli szintrol indul. Szoval nem tragikusan sok, ugyanakkor te nem a muholdat pingeted meg hanem valamit amit a muholdak halozatan es/vagy a muholdak foldi allomasokkal alkotott halozotan ersz el.
- A hozzászóláshoz be kell jelentkezni
Akkor az inkább 10-12 ms lesz, mert 4-szer kell megtennie ugyebár az utat, hacsak a műhold nem egy UTP kábelen "lóg". :)
- A hozzászóláshoz be kell jelentkezni
Van az úgynevezett Application Performance Management technika, amikor a korábban látogatott oldalakat, megnyitott fájlokat beteszik lokális cache-be. Talán valami ilyesmivel trükköznek it is.
- A hozzászóláshoz be kell jelentkezni
Szerintem ez két különböző dolog (APM és lokális cache).
Kifejtenéd bővebben, hogy mire gondolsz?
...úgyis jönnek...
- A hozzászóláshoz be kell jelentkezni
Valami olyasmire gondoltam, mint amit a Riverbed kínál:
- A hozzászóláshoz be kell jelentkezni
Nem, gondolom implementáltak egy tetszőleges flow-queueing AQM-et vagy ha Linux fut rajtuk, akkor bekapcsolták az fq_codel/fq_pie AQM-et. Ez pont azt csinálja, hogy round-robin üríti ki a sorokat, így hiába van egy torrent vagy más TCP forgalom meg egy interaktív SSH/web folyam, mindkettő azonos eséllyel kerül kiszolgálásra.
Érdemes rákeresni a "starlink bufferbloat"-ra, vannak mérések, hogy letöltés mellett a ping felmegyek 1 másodpercre is akár. A terjedési késleltetésnél ez több nagyságrenddel magasabb, vagyis rossz queueing, nem pedig rádiós zavar okozza. Nyilván ha valaki a bolygó túloldalát pingeli, azon ez sem segít :-)
- A hozzászóláshoz be kell jelentkezni
AI: már azelőtt elindul a válasz csomag, hogy odaért volna a kérés csomag!
Amúgy kíváncsi lennék, hogy ezt hogyan tudják elérni. A fizikai korlátok nem változnak, a hardvereket nem tudják lecserélni. Lehet, hogy benne maradt egy sleep(100) a szoftverben és most kiveszik belőle.
- A hozzászóláshoz be kell jelentkezni
Semmi kulonos. Implementalni kezdik lassankent pl. az URLLC-t (3GPP rel15). Esetleg az LTE_HRLLC, ha meg 4G-n alapulna esetleg a halozatuk.
- A hozzászóláshoz be kell jelentkezni
nem értek hozzá csak agyalok
lehet hogy meg tudják oldani a kisebb latency-t de más lesz az ára
pl kisebb sávszél, több adatátviteli hiba
voice-ra és videóra ez elfogadható
adatra pedig marad a régi
- A hozzászóláshoz be kell jelentkezni
Szerintem még több fölldi átjáró kell, valamint az útválasztásnál ki kell választani a legjobb RTT-jű útvonalat a túloldalon lévő állomásokhoz, akár kapcsolatonként, hogy meddig érdemes az űrben pattogtatni a csomagot és hol érdemes a földre dobni, és lehet, hogy nem a távoli állomáshoz legközelebbi átjáró lesz a nyerő.
- A hozzászóláshoz be kell jelentkezni