AirPort Expressin nopeus

[pepe82]

Sellaista kysyisin. Minulla on 100/10 meganen soneran valokuituyhteys. Airport express 802.11n. Saan langattomasti noin 80 megabytesia sekunnissa ladattua. Ethernet piuhalla suoraan seinästä noin 100 megabytesiä sekunnissa.

Onko normaalia, että langattomasti ei saa ladattua niin kovaa kuin piuhalla vai onko expressissä jotain vikaa?

[Lare]

Sellaista kysyisin. Minulla on 100/10 meganen soneran valokuituyhteys. Airport express 802.11n. Saan langattomasti noin 80 megabytesia sekunnissa ladattua. Ethernet piuhalla suoraan seinästä noin 100 megabytesiä sekunnissa.

Onko normaalia, että langattomasti ei saa ladattua niin kovaa kuin piuhalla vai onko expressissä jotain vikaa?

No, johan on nopea yhteys!

Normaalia se on, WLAN aiheuttaa viivettä, ja siksi aikaa menee kuittausten odettelussa TCP:llä. Jos siirrät useampaa tiedostoa yhtäaikaa, yhteinen siirtonopeus onkin suurempi.

[painman]

Wlanin teoreettista maksiminopeutta tuskin saavutetaan missään, mutta lähelle voi päästä laittamalla tietokoneen ihan kiinni Expressiin.

[htc]

Olisko nyt kuitenkin megaBITTIÄ sekunnissa? Toivon, muuten pitää lähteä kauppaan ja äkkiä ;-) Menee välillä sekaisin itsekin... ;-)

[tsjlehti]

Normaalia se on, WLAN aiheuttaa viivettä, ja siksi aikaa menee kuittausten odettelussa TCP:llä. Jos siirrät useampaa tiedostoa yhtäaikaa, yhteinen siirtonopeus onkin suurempi.

Ei tuolla nopeudella vielä wlanin pitäisi aiheuttaa ongelmia kuittausten kanssa. TCP:llä on kuitenkin aika iso ikkuna noille. Se wlanin aiheuttama viive on kuitenkin mitätön vaikkapa pitkiin välimatkoihin verrattuna. Useampi yhtäaikainen lataus auttaa siinä, ettei pakettien katoaminen ja siitä toipuminen pätkäise koko viestintää.

TCP joutuu tässä tapauksessa myös lähettämään kuittaukset samaa satamegasta kanavaa pitkin kuin vastaanottamaan tulevan datan. Piuhat taasen ovat yleensä full-duplex-mallisia.

[Lare]

Ei tuolla nopeudella vielä wlanin pitäisi aiheuttaa ongelmia kuittausten kanssa. TCP:llä on kuitenkin aika iso ikkuna noille. Se wlanin aiheuttama viive on kuitenkin mitätön vaikkapa pitkiin välimatkoihin verrattuna. Useampi yhtäaikainen lataus auttaa siinä, ettei pakettien katoaminen ja siitä toipuminen pätkäise koko viestintää.

TCP joutuu tässä tapauksessa myös lähettämään kuittaukset samaa satamegasta kanavaa pitkin kuin vastaanottamaan tulevan datan. Piuhat taasen ovat yleensä full-duplex-mallisia.

Suuremmilla nopeuksilla se viive juuri haittaakin, TCP on 70-luvun protokolla, eikä taivu suuriin siirtonopeuksiin.
Tuolla on noita kaavoja: http://onlamp.com/pub/a/onlamp/2005/11/ ... uning.html
Jos yhtäaikaa tuetaan b/g/n ja n-verkkoja, se lisää WLANin viivettä. Pingillähän voi kokeilla mikä se 2-suuntainen viive on WLANin yli.

[tsjlehti]

Suuremmilla nopeuksilla se viive juuri haittaakin, TCP on 70-luvun protokolla, eikä taivu suuriin siirtonopeuksiin.
Tuolla on noita kaavoja: http://onlamp.com/pub/a/onlamp/2005/11/ ... uning.html
Jos yhtäaikaa tuetaan b/g/n ja n-verkkoja, se lisää WLANin viivettä. Pingillähän voi kokeilla mikä se 2-suuntainen viive on WLANin yli.

a-, b-, g- ja n-verkkojen yhtäaikainen tukeminen voi ehkä hieman lisätä viivettä, koska signaloinnissa muut pitää ottaa huomioon. Varsinainen payloadi menee kuitenkin n-stanujen mukaan. Noh minulla ei ole täällä tällä hetkellä käytössä n-verkkoa, jossa kokeilla, mutta g-verkossa n-kykyiseltä MBP:ltä g-tukiaseman kautta toisella ilmatiellä n-kykyiselle Airport Expressille ja takaisin, eli yhteensä 4 hyppyä ilmassa, aikaa kului lähes tyhjässä verkossa kokonaiset 4 ms.

Kotimaista liikennettä samasta koneesta 1 edestakainen hyppy ilmassa ja sitten päälle 12 edestakaista kaapelissa, kestää karvan alle 20 ms. Ja isompi downloadi voi tulla huomattavasti kauempaakin.

En väitä, etteikö viipellä ja puskurin koolla olisi merkitystä TCP:n nopeudelle, vaikka siihen sitten 70-luvun on lääkkeitä tullutkin. Väitän, että se wlanin aiheuttama viive on varsin vähäpätöinen verrattuna viipeeseen, mikä koituu paketeille niiden surffatessa ympäri Internettiä. Tämä noin 600 km yksisuuntaisella matkalla oli noin 10 % yhden paketin otannalla.

Ihmettelisin myös suuresti, mikäli OS X olisi vielä TCP:nsä osalta 70-luvun tasolla eikä osaisi TCP:n window scaling juttusia. Windowspuolella tuo on ollut olemassa w2k:sta lähtien ja ainakin Vistasta lähtien oletuksena päällä.

Onlapin artikkelia vähemmän teknistä lukemistoa asiasta kiinnostuneille englannin kielisessä wikipediassa TCP window scale optiosta.

[Lare]

a-, b-, g- ja n-verkkojen yhtäaikainen tukeminen voi ehkä hieman lisätä viivettä, koska signaloinnissa muut pitää ottaa huomioon. Varsinainen payloadi menee kuitenkin n-stanujen mukaan. Noh minulla ei ole täällä tällä hetkellä käytössä n-verkkoa, jossa kokeilla, mutta g-verkossa n-kykyiseltä MBP:ltä g-tukiaseman kautta toisella ilmatiellä n-kykyiselle Airport Expressille ja takaisin, eli yhteensä 4 hyppyä ilmassa, aikaa kului lähes tyhjässä verkossa kokonaiset 4 ms.

Kotimaista liikennettä samasta koneesta 1 edestakainen hyppy ilmassa ja sitten päälle 12 edestakaista kaapelissa, kestää karvan alle 20 ms. Ja isompi downloadi voi tulla huomattavasti kauempaakin.

En väitä, etteikö viipellä ja puskurin koolla olisi merkitystä TCP:n nopeudelle, vaikka siihen sitten 70-luvun on lääkkeitä tullutkin. Väitän, että se wlanin aiheuttama viive on varsin vähäpätöinen verrattuna viipeeseen, mikä koituu paketeille niiden surffatessa ympäri Internettiä. Tämä noin 600 km yksisuuntaisella matkalla oli noin 10 % yhden paketin otannalla.

Ihmettelisin myös suuresti, mikäli OS X olisi vielä TCP:nsä osalta 70-luvun tasolla eikä osaisi TCP:n window scaling juttusia. Windowspuolella tuo on ollut olemassa w2k:sta lähtien ja ainakin Vistasta lähtien oletuksena päällä.

Onlapin artikkelia vähemmän teknistä lukemistoa asiasta kiinnostuneille englannin kielisessä wikipediassa TCP window scale optiosta.

Itsellä ethernetiä pitkin viive routerille oli n. 0,8ms, WLANin yli n. 1,8 ms edes takaisin. Eli mitätönhän tuo on. Mulla on pelkkä G-moodi, B-moodi disabloitu. Muuta ei voikaan enää kokeilla, sillä Elisa näyttää filteröivän Pingit kokonaan pois. Viivemielessä payload ei ole ongelma vaan usean moodin aiheuttamat "hiljaiset" odottelujaksot. B-moodin ajaksi G-moodi "mykistetään". Samoin n-moodi, jne.

En ole tutkinut, mitä ikkunakokoa nuo mittariohjelmat käyttävät, ja miten TCP window scalingiä niissä käytetään. Mittariohjelmienhan perusteella ihmiset yleensä näitä nopeuseroja ihmettelevät.

[tsjlehti]

Muuta ei voikaan enää kokeilla, sillä Elisa näyttää filteröivän Pingit kokonaan pois. Viivemielessä payload ei ole ongelma vaan usean moodin aiheuttamat "hiljaiset" odottelujaksot. B-moodin ajaksi G-moodi "mykistetään". Samoin n-moodi, jne.

En ole tutkinut, mitä ikkunakokoa nuo mittariohjelmat käyttävät, ja miten TCP window scalingiä niissä käytetään. Mittariohjelmienhan perusteella ihmiset yleensä näitä nopeuseroja ihmettelevät.

Hmm. Täällä on myös Elisan liittymä, tosin Saunalahdeksi brändättynä ja pingit (ja traceroute) kulkevat ainakin ulospäin kiltisti.

Mutta mitä tarkoitat noilla hiljaisilla odottelujaksoilla? Mie hetko sitten lueskelin, miten moodien yhteensopivuus on toteutettu ja nyt muistelisin, että vain signalointi tehtiin hitaimman käytetyn moodin ehdoilla. En ymmärtänyt, että siellä mitään sen kummempia odoteltaisi tai oltaisi hiljaa.

TCP window scaling optio on mielestäni käyttiksen asetuksien ja toiminnan huttua, eikä niinkään ohjelmista kiinni, kunhan puskevat sinne TCP:lle kamaa riittävästi.

[Lare]

Hmm. Täällä on myös Elisan liittymä, tosin Saunalahdeksi brändättynä ja pingit (ja traceroute) kulkevat ainakin ulospäin kiltisti.

Mutta mitä tarkoitat noilla hiljaisilla odottelujaksoilla? Mie hetko sitten lueskelin, miten moodien yhteensopivuus on toteutettu ja nyt muistelisin, että vain signalointi tehtiin hitaimman käytetyn moodin ehdoilla. En ymmärtänyt, että siellä mitään sen kummempia odoteltaisi tai oltaisi hiljaa.

TCP window scaling optio on mielestäni käyttiksen asetuksien ja toiminnan huttua, eikä niinkään ohjelmista kiinni, kunhan puskevat sinne TCP:lle kamaa riittävästi.

Kantoaalto ja sen modulointi ovat epäyhteensopivia eri 802.11-moodeissa. Siksi tukiasema ei käytä hetkeen esim G-moodia, jotta B-moodin laitteet voivat lähettää sanomiansa. Tarkkaa mekanismia en tunne, miten se ajoitus siinä hoidettu. Mutta käsittääkseni kannattaa poistaa nuo vanhat moodit, joita ei käytä. Edit: Ehkä pitää olla hiljaa hetki, että se signaloint toimii.?

Sain kuin sainkin Wiresharkin toimimaan. Lyhyt kokeilu antaisi sen kuvan, että esim YLE.FI käyttää window size 65535 (maksimi ilman skaalausta), mutta esim Homppu käyttää scalingiä.