Digiboksi ilmoitti, että etsii signaalia, mutta ei löytänyt mitään.
Kanavahaku ei onnistunut eikä tehdasasetusten palautus.
Meni merkkihuoltoon. Ei voinut mitään
tiistai 9. syyskuuta 2008
torstai 28. elokuuta 2008
Samsung kaapeliverkosta antenniverkkoon
Täysdigi TV Samsung piti vaihtaa kaapeliverkosta antenniverkkoon.
Valitaan D-Menu ja sieltä Opas ja sieltä Lautasantenni ja sitten Kanava ja sitten Automaattinen haku ja Automaattinen ja valitaan Antenni
Valitaan D-Menu ja sieltä Opas ja sieltä Lautasantenni ja sitten Kanava ja sitten Automaattinen haku ja Automaattinen ja valitaan Antenni
sunnuntai 17. elokuuta 2008
Tietokoneen digiboksi näkyvyys
Ostin Anyseen digiboksin tietokoneeseen. Omalla digiboksin antennilla ei näy mitään, mutta erillisellä sisäantennilla ja vahvistimella varustetulla antennilla näkyy.
Katvetta näyttää olevan vielä paljon.
Katvetta näyttää olevan vielä paljon.
torstai 7. elokuuta 2008
LG:n digiTV:n alustan kiinnitys
.jpg)
LG digitelkkari piti koota ja siinä oli kahdenlaisia ruuveja alustan kiinnitystä varten. Käyttöohjeen paperiversiossa ei ollut kuvaa tai tietoa mikä ruuvi tulee tiettyyn osaan.
Paketin mukana tuli CD, josta piti löytää kaavakuva asiasta.
Jos laittaa väärät ruuvit jalustan kiinnitysosaan, niin niitä on hankala saada pois.
maanantai 7. heinäkuuta 2008
Handan ongelma
Handaniin ei latautunut kuin kanavat 12:sta eteenpäin ja näkyi vain katselukorttikanavat.
Yleisissä käyttöasetuksissa piti TV-asetuksiin muuttaa, että automaattiset päivitykset eivät ole päällä.
Yleisissä käyttöasetuksissa piti TV-asetuksiin muuttaa, että automaattiset päivitykset eivät ole päällä.
keskiviikko 11. kesäkuuta 2008
Mökin antennihommat
maanantai 2. kesäkuuta 2008
LG digitelkkari
LG digitelkkarin korttipaikassa ei toiminut MTV3Plus-kortti. Telkkuun pitää asentaa Conax-modulilaite: esim. Technisatin valmistaja MultiCrypt tai Tecnisatin TechniCrypt CX
lauantai 24. toukokuuta 2008
Kuvakoko ongelma
RF-modulaattori digiboksi
RF-modulaattorilla varustettu Finlux digiboksi piti virittää RF-modulipaikkaan 40, että sai kanavat näkymään vanhasta telkkarista, jossa oli vain RF-liitäntä.
Telkkarista piti virittää tietyt kanavat sille taajuudelle, josta digikuva näkyi.
Useamman kerran digiboksi oli mennyt sekaisin, koska RF-modulia oli muutettu ja virtajohto oli kesken kaiken kytketty irti.
Force ongelma

Force digiboksi oli kytketty DVD-laitteen yhteyteen siten, että antennikaapeli oli kytketty DVD:n ant in-pistokkeeseen. ja sieltä scartti digiboksiin. DVD:n piti olla päällä jos digiboksista haluttiin kuvaa televisioon.
Digiboksissa ei ollut ollenkaan kanavia ja automaattihaulla ne sitten saatiin haettua ja käyttökuntoon.
lauantai 10. toukokuuta 2008
TCP/IP:n suorituskyky asymmetrisissa verkoissa
Luku 10 TCP/IP Performance over Asymmetric Networks
Langattomien verkkojen suorituskyky-seminaari
Pertti Salo 2008
Asymmetrinen tekniikka
Tekniikka on asymmetrinen, kun tietovirta keskuksesta tilaajalle päin on suurempi kuin päinvastoin
Verkon ominaisuudet yhteen suuntaan ovat erilaiset kuin toiseen suuntaan
Upstream kaistanleveys on usein rajoitettu asiakkaan suunnasta, verrattuna downstream kaistanleveyteen asiakkaan suuntaan
Verkko asymmetria voi vaikuttaa TCP:n suorituskykyyn, vaikka verkkolähde datavirran suunnassa on ilman ruuhkaa, ruuhka toiseen suuntaan voi häiritä feedback virtaa.
Uplink ja Downlink
Kaistanleveys asymmetria
Kahden tyyppisiä tilanteita syntyy yksisuuntaisessa liikenteessä verkoissa: kun vastakkaisessa pullonkaula linkissä on riittävästi jonotusta estämään paketti(ACK) hävikit, tai kun vastakkaisessa pullonkaula linkissä on pieni puskuri.
Jos vastaanotin tunnistaa säännöllisesti enemmän kuin yhden ACK:n jokaista k = 8 data pakettia kohden, vastakkainen pullonkaulalinkki täyttyy ennen kuin asiakkaan suuntainen pullonkaula- linkki, rajoittaen throughputtia asiakkaan suuntaan.
Rajoitettu vastakkainen kaistanleveys ja jonotus vastakkaisessa pullonkaula reitittimessä muuttaa ACK:ien väliä jonka havaitsee lähettäjä. Kun ACK:it saapuvat pullonkaulalinkkiin vastakkaiseen suuntaan nopeammin kuin linkki voi tukea, ne jonoutuvat toistensa taakse.
Erilainen tilanne syntyy kun vastakkaisessa pullonkaulalinkissä on suhteellisen pieni puskuritila ACK:ja varten. Kun siirtoikkuna kasvaa jono täyttyy ja ACK:t putoavat liikenteestä.
Heikentyneelle suorituskyvylle on kolme syytä tässä tapauksessa koska ACK:t ovat epäsäännöllisiä.
1. Ensinnäkin, lähettäjä lähettää dataa suurina purskeina. Jos lähettäjä vastaanottaa vain yhden ACK:n k pakettia kohti, se lähettää dataa k:n suuruisina purskeina (tai enemmän) segmenteissä, koska jokainen ACK siirtää sliding windowta vähintään k (tunnistettua) segmentin verran. Tämä lisää datahävikin todennäköisyyttä, koska reitittimet eivät käsittele suuria pakettipurskeita kovin hyvin.
2. Toiseksi TCP lähetinsovellukset lisäävät niiden ruuhkautumisikkunaa laskemalla ACK:iden lukumäärän, jonka ne vastaanottavat mutta eivät sitä kuinka paljon dataa tunnistetaan ACK:ta kohti. Koska pienepi ACK:iden määrä aiheuttaa hitaamman kasvun ruuhkaikkunassa ja se heikentää suorituskykyä pitkien viiveiden yhteyksissä.
3. Kolmanneksi lähettäjän uudelleenlähetys ja elpymisalgoritmit ovat vähemmän tehokkaita kun ACK:t ovat hävinneet.
10.2 Asymmetrian vaikutus TCP:n suorituskykyyn
Yksisuuntainen datasiirto
Tavallinen esimerkki on käyttäjä, joka lataa dataa palvelimelta. Rajoitetaan tapaus yksinkertaiseen TCP yhteyteen downstream suuntaan.
Jos vastaanotin lähettää enemmän kuin yhden ACK:n jokaista k datapakettia kohden niin upstream pullonkaulalinkki täyttyy ennen kuin downstream. Tämä pakottaa lähettäjän syöttämään dataa hitaammin kuin optimaalia, joka vähentäen troughputtia.
jos upstream pullonkaula jää ruuhkaiseksi pitkäksi aikaa, vastaava puskuri täyttyy, aiheuttaen ACK:ien putoamisen.
keskimäärin vain yksi ACK pääsee läpi jokaista K datapakettia kohti, jotka lähettäjä lähettää, joka voi heikentää suorituskykyä monin tavoin.
Kaistanleveys asymmetrian vaikutus
Ensinnäkin, lähettäjä voi lähettää k määrän paketteja tiettynä aikana, joka lisää datapaketin häviämis-mahdollisuutta, erityisesti kun k on suurempi.
Toiseksi, perinteinen TCP lähettäjän perusruuhkaikkunan kasvu epäsäännöllisessä ACK lähetyksessä johtaa hitaampaan ruuhkaikkunan kasvuun.
lopuksi (the now infrequent) ACKien hävikki muualla verkossa voi aiheuttaa pitkän odotus jakson kun lähettäjä odottaa seuraavan ACK:in saapumista.
Kaksisuuntainen datasiirto
Kirjassa käsitellään tapausta jossa sekä downstream että upstream TCP lähetykset tapahtuvat samanaikaisesti.
Esimerkki tästä on käyttäjä joka lähettää dataa esim sähköposti, kun samalla vastaanottaa toista dataa, esim websivu.
kaksisuuntainen liikenne tehokkaasti lisää kaistanleveys asymmetriaa downstream lähetyksessä.
On myös muita vaikutuksia jotka syntyvät interaktiosta upstream datapakettien ja downstreamin ACK:iden välillä
Erityisesti, edellinen voi nopeasti täyttää upstream puskurin aiheuttaen laajan viiveen ja jälkimmäisen korkean hävikkimäärän
esimerkiksi yksittäinen 1-KB datapaketti upstream siirrossa voi lisätä merkittävän1 sekunnin jonotusviiveen ACK:eille downstream siirrossa
Yhteenveto
yhteenvetona, kaksisuuntainen liikenne pahentaa ongelmia kaistanleveys-symmetrian takia ja vastakkainen vuorovaikutus upstreamliikenteen data- pakettien ja downstream yhteyden ACK:ien välillä.
Media-Access asymmetria
Media-access asymmetria ilmenee monin tavoin: perussyy on kuitenkin sama – epätasainen pääsy jaettuun mediaan, joka muodostuu hajautetuista päätelaitteista.
Hub-and-spokes mallissa, tukiasemalla on täydellinen tieto ja kontrolli downstream liikenteestä; siksi se kärsii alemmasta MAC overheadista kuin hajautetut päätelaiteet jotka ohjaavat uplinkkiä.
toisaalta 3 G verkossa, päätelaitteet ovat samanarvoisia.
turn-around -viiveen aiheuttama MAC overhead tekee työlääksi siirtää paketteja yhteen suuntaan, kun vastakkaiseen suuntaan on käynnissä oleva datasiirto.
Half-Duplex Radios
Koska siirtovoima alentaa tulevaa vastaanottoa samassa taajuuskaistassa, päätelaitteet verkossa ovat half-duplex, Tämä tarkoittaa, etteivät ne voi samanaikaan lähettää ja vastaanottaa dataa.
H-FDD (Hybrid / Halfduplex FDD) –moodissa uplink ja downlink osat eri taajuuksilla siten, ettei päätelaitteelle allokoida sekä lähetys- että vastaanottovuoroa samanaikaisesti.
Media-Access protokolla
päätelaitteet verkossa suorittavat taajuushyppelyä, laajassa spektrissä.
Taajuushyppelyprotokollan ominaisuudet eivät ole relevantteja siirron suorituskykyyn, koska pääasiallinen syy huonoon suorituskykyyn on vuorovaikutus media-access(MAC) protokollan ja TCP:n välillä
Luotettava link-layer protokolla jota käytetään verkossa virhekontrollia varten on yksinkertainen frame-by-frame protokolla,jossa ikkunakoko on1.
kun kehys on vastaanotettu, vastaanotin lähettää link-level ACK:in lähettäjälle.
jos kehys ei ole vastaanotettu onnistuneesti, lähetin lähettää sen timeout jakson jälkeen.
tarve merkittävään turnaround aikaan päätelaitteissa johtaa high-packet overheadiin.
RTS/CTS protokollan vaihtaminen tarvitsee varmistusta kun kohteena oleva päätelaite on muuten kiireinen.
Tämä johtaa laajoihin ja muuttuviin kommunikaatio viiveisiin verkoissa. Lisäksi asymmetriseen työkuormaan useimpien datavirtojen kanssa yhteensuuntaan asiakkaille.
ACK:lla on taipumus ruuhkautua tietyissä laitteissa, kuten asiakkaiden modeemeissa.
Nämä vaihtelevat viiveet ja ACK jonot vaikuttavat pehmeään datavirtaan.
Erityisesti ,TCP ACK liikenne häiritsee datavirtaa ja lisää liikennekuormaa järjestelmässä.
Yleensä,oikea tapa uudelleenlähetysajastimelle on laukaista uudelleenlähetys segmentti tietyn ajan jälkeen joka riippuu sekä round-trip ajasta ja lineaarisesta poikkeamasta.
Linkkikerroksen optimointi, virhekontrolli protokolla joka toimii linkkikerroksen ACK:t datakehyksillä vähentää TCP round-trip vaihtelua jossain määrin.
Liikenne molempiin suuntiin, jopa TCP ACK:ien aiheuttamina, aiheuttaa turnaroundeja. Niinpä jos linkkikerroksen ACK:t toimivat datakehyksillä, muutamia ylimääräisiä päätelaitteiden turnaroundeja voidaan poistaa.
Huolimatta optimoinnista, perusongelma lisäliikenteessä ja taustalla olevissa protokollissa, jotka vaikuttavat round-trip aika arvioihin ja aiheuttavat muuttujia suorituskyvyssä on yhä olemassa.
poikittaiset multiple hops yhteydet langattomissa verkoissa ovat haavoittuvampia tälle vaikutukselle, koska on todennäköisempää että päätelaitteet voivat jo olla sitoutuneina keskusteluun muiden päätelaitteiden kanssa.
10.3 TCP suorituskyvyn parantaminen asymmetrisissä verkoissa
10.3.1 Uplink Bandwidth Management
10.3.2 Handling InfrequentACKs
Uplink kaistanleveyden hallinta voidaan suorittaa valvomalla pakkauksen tasoa, taajuutta ja upstream ACK:iden aikataulutusta.
TCP otsikon pakkaus
TCP otsikkopakkaus kuvaa TCP otsikon pakkausta käytettäessä low-bandwidth linkkejä, jotka käyttävät SLIP tai PPP protokollaa.
Koska se huomattavasti vähentää ACK:iden kokoa uplinkissä kun hävikit ovat epäsäännöllisiä, sen käyttö on suositeltavaa low-bandwidth uplinkeissä jos mahdollista.
TCP otsikkopakkaus ei yksin kata kaikkia ongelmia:
• tietyissä verkoissa on merkittävä per-packet MAC overhead joka on riippumaton paketin koosta.
• ACK:iden koon vähennys ei estä vastakkaista vuorovaikutusta suurien upstream datapakettien kanssa kaksisuuntaisen liikenteen yhteydessä.
• jos halutaan tehokkaasti vaikuttaa suorituskykyongelmiin, joita aiheuttaa asymmetria tarvitaan tekniikkaa over and beyond TCP otsikko pakkauksen.
ACK Filtering(AF)
ACK suodatus(AF) on TCP linkkikerros tekniikka joka vähentää TCP ACK:iden lukumäärää joita lähetetään upstream kanavalla.
Haasteena on varmistaa että lähettäjä ei jää odottamaan ACK:eja, joka voi tapahtua jos ACK:ta poistetaan upstream lähteestä. AF poistaa vain tietyt ACK:t näännyttämättä lähettäjää hyödyntämällä siitä tosiasia että TCP ACK:t ovat kumulatiivisia.
Mitä tulee lähettäjän virhekontrolli mekanismiin se informaatio mikä on ACK:ssa with later sequence number subsumes the tiedon joka on sisältynyt aikaisempiin ACK;hin.
Kun ACK vastaanottimesta on menossa jonoon upstream pullonkaula reitittimessä, reititin or the end-host linkki kerroksessa tarkistaa jononsa vanhat ACK:it jotka kuuluvat samaan yhteyteen. Jos niitä löytyy, se poistaa ne jonosta niin vähentäen ACK:iden määrää jotka menevät takaisin lähettäjälle.
Näiden ACK:iden poistaminen vapauttaa puskuritilaa muulle datalle ja ACK paketeille.
AF ei poista duplikaatti tai selective ACK:ia jonosta että vältetään ongelmat TCP:n hävikistä elpymismekanismissa.
ACK congestion control(ACC)
ACK ruuhkan hallinta on vaihtoehto ACK suodatukselle joka toimii päästä päähän mielummin kuin upstream pullonkaula reitittimessä.
Avainidea ACC:ssa on laajentaa ruuhkan hallintaa TCP ACK:hin, koska ne muodostavat merkittäviä vaatimuksia resursseihin upstream linkkiin.
ACK:it muodostavat osioita upstream kanavapuskuriin, joiden kapasiteetti on usein rajoitettu tiettyyn lukumäärään paketteja.
ACK:s First Scheduling
kaksisuuntaisessa siirrossa data ja ACK paketit kilpailevat resursseista upstream suuntaan.
Tässä tapauksessa yksittäinen FIFO jono sekä datapaketeissa että ACK:issa voi aiheuttaa ongelmia.
esimerkiksi jos upstream kanava on 28.8 Kbps dialup linjalla, 1 –KB-kokoisen paketin siirto voi kestää 280 ms.
Näin ollen jos vain kaksi sellaista datapakettia menevät jonoon ACKien edelle ne sulkevat ACK pois puolen sekunnin ajaksi.
ACK reconstruction
ACK reconstruction(AR) on tekniikka jolla rekonstruoidaan ACK virtaa joka on kulkenut upstream suuntaan pullonkaulalinkissä.
AR on paikallinen tekniikka joka on suunniteltu estämään vähentynyt ACK:iden määrä joka haitallisesti vaikuttaa TCP lähettäjän sovellusten suorituskykyyn.
Tämä mahdollistaa aikataulujen käytön kuten ACK suodatus tai ACK ruuhkan hallinta vaatimatta, että TCP lähettäjät modifoidaan suorittamaan lähettäjän sovitusta.
Tämän ratkaisun voi Internet Service Provider(ISP) helposti ottaa käyttöön saavuttaakseen hyvän suorituskyvyn.
10.4 Suorituskyvyn parantamis- tekniikoiden kokeellinen arviointi
10.4.1 Experiments with Bandwidth Asymmetry
10.4.2 Experiments with Media-Access Asymmetry
Kaistanleveys asymmetrian kokeet
Kokeissa käytetään 10-Mbps downlink ja a 28.8 –Kpps uplink with TCP otsikon pakkauksella..
maksimi ikkunakoko on asetettu 120 pakettiin ja jonokoot asetettiin 10 pakettiin.
AF/AR ja AF/SA suoriutuvat parhaiten saavuttaen troughputit 15 – 21 prosenttia paremmin kuin Reno.
ACC/SA suoriutuu 5 prosenttia paremmin kuin Reno.
Tärkeä asia on että purskeisuuden määrä vähenee merkittävästi, koska upstream reititin jono ei ole enää jatkuvasti täynnä AF tai ACC ansiosta.
Taulukko osoittaa, että ACK:iden toistumisen vähentäminen ei ole riittävä ja myös SA ja AR tekniikoiden käyttämistä tarvitaan.
AR johtaa suurempaan round-trip aikaan kuin muut protokollat, mutta tämä johtaa parhaaseen suorituskykyyn näillä parametreillä koska se vähentää hävikkien lukumäärää
yhteenvetona tulokset, osoittavat että SA tai AR ovat tärkeitä selviydyttäessä purskeista jotka on tuloksena hävikkiä tuottavasta ACK virrasta.
ks. dia 32.
Kokeet Media-Access asymmetrialla
kokeessa käytettiin Ricochet verkon mallia.
työkuorma tässä kokeessa sisältää 100-sekunnin TCP siirron, ilman kilpailevaa liikennettä ja maksimissaan vastaanottimen 32 KB:n ikkunakoolla
ruuhkahävikit ilmenevät tuloksena puskurin ylivuodosta ja johtavat lähettäjän timeoutteihin jos paketteja menetetään siirtoikkunassa.
tutkittuihin protokolliin kuului modifioimaton TCP Reno, Reno with ACC/SA ja Reno with AF/SA
dia 35 osoittaa tulokset kokeesta AF:n ja ACC:n suorituskyky SA:n kanssa on parempi kuin Renon ja AF/SA on parempi kuin ACC/SA
10.6 Yhteenveto
Verkkoasymmetria, liittyen kaistanleveyteen, media-accessiin ja loss rateen voi vaikuttaa vakavasti feed-back siirtoprotokollan suorituskykyyn, kuten TCP:hen.
10.9 Case Study: Improving TCP Performance over ADSL
Vaikka suurin osa WCORP työntekijöistä tekee
töitä toimistossa, jotkut etätyöskentelevät kotonaan yhden
tai kaksi päivää.
Kotona etätyöskentely tarjoaa joustavuutta ja tekee
työnteosta houkuttelevamman.
Aikaisemmin työntekijät käyttivät soittoyhteyttä
Internettiin.
Työntekijät kohtasivat kolme pääasiallista ongelmaa:
pitkät latausajat, epäluotettavat yhteydet,
äänipuhelut eivät toimineet internetyhteydet aikana. Siksi
WCORP siirtyi ADSL:n käyttöön.
WCORP case study
ADSL käytössä todettiin kuitenkin, että sen nopeus oli alhaisempi kuin
ajateltiin ja ruuhkat dataliikenteessä aiheuttivat latausongelmia.
Matalatasoinen throughput johtui ACK ruuhkasta uplinkissä(kotoa
Internettiin) Uplink kapasiteetti todettiin 150 kertaa hitaammaksi kuin
downlink.
TCP lähettäjä ei voinut palvelinpuolella pumpata dataa nopeammin
koska ACK paketit saapuivat hitaasti asiakkaan puolelta.
Ratkaistakseen TCP ongelmat kotikäyttäjillä, WCORP mietti kolmea
tekniikkaa:
TCP otsikko pakkausta, ACK suodatusta ja ACK ruuhkanhallintaa.
TCP otsikkopakkaus valittiin lopulta tekniikaksi.
Kaikki koti TCP/IP.t päivitettiin TCP otsikko pakkauksella, jonka avulla
saatiin merkittävästi vähennettyä ACK pakettien kokoa.
Mittaus osoitti selvää parannusta latausaikoihin.
Latauskapasiteetista voitiin hyödyntää 95 %
Lähteet
Mahbub Hassan, RaJ Jain. High Performance TCP/IP Networking.
www.mit.jyu.fi/arjuvi/opetus/ties422/wimax.ppt 9.5.2008
Langattomien verkkojen suorituskyky-seminaari
Pertti Salo 2008
Asymmetrinen tekniikka
Tekniikka on asymmetrinen, kun tietovirta keskuksesta tilaajalle päin on suurempi kuin päinvastoin
Verkon ominaisuudet yhteen suuntaan ovat erilaiset kuin toiseen suuntaan
Upstream kaistanleveys on usein rajoitettu asiakkaan suunnasta, verrattuna downstream kaistanleveyteen asiakkaan suuntaan
Verkko asymmetria voi vaikuttaa TCP:n suorituskykyyn, vaikka verkkolähde datavirran suunnassa on ilman ruuhkaa, ruuhka toiseen suuntaan voi häiritä feedback virtaa.
Uplink ja Downlink
Kaistanleveys asymmetria
Kahden tyyppisiä tilanteita syntyy yksisuuntaisessa liikenteessä verkoissa: kun vastakkaisessa pullonkaula linkissä on riittävästi jonotusta estämään paketti(ACK) hävikit, tai kun vastakkaisessa pullonkaula linkissä on pieni puskuri.
Jos vastaanotin tunnistaa säännöllisesti enemmän kuin yhden ACK:n jokaista k = 8 data pakettia kohden, vastakkainen pullonkaulalinkki täyttyy ennen kuin asiakkaan suuntainen pullonkaula- linkki, rajoittaen throughputtia asiakkaan suuntaan.
Rajoitettu vastakkainen kaistanleveys ja jonotus vastakkaisessa pullonkaula reitittimessä muuttaa ACK:ien väliä jonka havaitsee lähettäjä. Kun ACK:it saapuvat pullonkaulalinkkiin vastakkaiseen suuntaan nopeammin kuin linkki voi tukea, ne jonoutuvat toistensa taakse.
Erilainen tilanne syntyy kun vastakkaisessa pullonkaulalinkissä on suhteellisen pieni puskuritila ACK:ja varten. Kun siirtoikkuna kasvaa jono täyttyy ja ACK:t putoavat liikenteestä.
Heikentyneelle suorituskyvylle on kolme syytä tässä tapauksessa koska ACK:t ovat epäsäännöllisiä.
1. Ensinnäkin, lähettäjä lähettää dataa suurina purskeina. Jos lähettäjä vastaanottaa vain yhden ACK:n k pakettia kohti, se lähettää dataa k:n suuruisina purskeina (tai enemmän) segmenteissä, koska jokainen ACK siirtää sliding windowta vähintään k (tunnistettua) segmentin verran. Tämä lisää datahävikin todennäköisyyttä, koska reitittimet eivät käsittele suuria pakettipurskeita kovin hyvin.
2. Toiseksi TCP lähetinsovellukset lisäävät niiden ruuhkautumisikkunaa laskemalla ACK:iden lukumäärän, jonka ne vastaanottavat mutta eivät sitä kuinka paljon dataa tunnistetaan ACK:ta kohti. Koska pienepi ACK:iden määrä aiheuttaa hitaamman kasvun ruuhkaikkunassa ja se heikentää suorituskykyä pitkien viiveiden yhteyksissä.
3. Kolmanneksi lähettäjän uudelleenlähetys ja elpymisalgoritmit ovat vähemmän tehokkaita kun ACK:t ovat hävinneet.
10.2 Asymmetrian vaikutus TCP:n suorituskykyyn
Yksisuuntainen datasiirto
Tavallinen esimerkki on käyttäjä, joka lataa dataa palvelimelta. Rajoitetaan tapaus yksinkertaiseen TCP yhteyteen downstream suuntaan.
Jos vastaanotin lähettää enemmän kuin yhden ACK:n jokaista k datapakettia kohden niin upstream pullonkaulalinkki täyttyy ennen kuin downstream. Tämä pakottaa lähettäjän syöttämään dataa hitaammin kuin optimaalia, joka vähentäen troughputtia.
jos upstream pullonkaula jää ruuhkaiseksi pitkäksi aikaa, vastaava puskuri täyttyy, aiheuttaen ACK:ien putoamisen.
keskimäärin vain yksi ACK pääsee läpi jokaista K datapakettia kohti, jotka lähettäjä lähettää, joka voi heikentää suorituskykyä monin tavoin.
Kaistanleveys asymmetrian vaikutus
Ensinnäkin, lähettäjä voi lähettää k määrän paketteja tiettynä aikana, joka lisää datapaketin häviämis-mahdollisuutta, erityisesti kun k on suurempi.
Toiseksi, perinteinen TCP lähettäjän perusruuhkaikkunan kasvu epäsäännöllisessä ACK lähetyksessä johtaa hitaampaan ruuhkaikkunan kasvuun.
lopuksi (the now infrequent) ACKien hävikki muualla verkossa voi aiheuttaa pitkän odotus jakson kun lähettäjä odottaa seuraavan ACK:in saapumista.
Kaksisuuntainen datasiirto
Kirjassa käsitellään tapausta jossa sekä downstream että upstream TCP lähetykset tapahtuvat samanaikaisesti.
Esimerkki tästä on käyttäjä joka lähettää dataa esim sähköposti, kun samalla vastaanottaa toista dataa, esim websivu.
kaksisuuntainen liikenne tehokkaasti lisää kaistanleveys asymmetriaa downstream lähetyksessä.
On myös muita vaikutuksia jotka syntyvät interaktiosta upstream datapakettien ja downstreamin ACK:iden välillä
Erityisesti, edellinen voi nopeasti täyttää upstream puskurin aiheuttaen laajan viiveen ja jälkimmäisen korkean hävikkimäärän
esimerkiksi yksittäinen 1-KB datapaketti upstream siirrossa voi lisätä merkittävän1 sekunnin jonotusviiveen ACK:eille downstream siirrossa
Yhteenveto
yhteenvetona, kaksisuuntainen liikenne pahentaa ongelmia kaistanleveys-symmetrian takia ja vastakkainen vuorovaikutus upstreamliikenteen data- pakettien ja downstream yhteyden ACK:ien välillä.
Media-Access asymmetria
Media-access asymmetria ilmenee monin tavoin: perussyy on kuitenkin sama – epätasainen pääsy jaettuun mediaan, joka muodostuu hajautetuista päätelaitteista.
Hub-and-spokes mallissa, tukiasemalla on täydellinen tieto ja kontrolli downstream liikenteestä; siksi se kärsii alemmasta MAC overheadista kuin hajautetut päätelaiteet jotka ohjaavat uplinkkiä.
toisaalta 3 G verkossa, päätelaitteet ovat samanarvoisia.
turn-around -viiveen aiheuttama MAC overhead tekee työlääksi siirtää paketteja yhteen suuntaan, kun vastakkaiseen suuntaan on käynnissä oleva datasiirto.
Half-Duplex Radios
Koska siirtovoima alentaa tulevaa vastaanottoa samassa taajuuskaistassa, päätelaitteet verkossa ovat half-duplex, Tämä tarkoittaa, etteivät ne voi samanaikaan lähettää ja vastaanottaa dataa.
H-FDD (Hybrid / Halfduplex FDD) –moodissa uplink ja downlink osat eri taajuuksilla siten, ettei päätelaitteelle allokoida sekä lähetys- että vastaanottovuoroa samanaikaisesti.
Media-Access protokolla
päätelaitteet verkossa suorittavat taajuushyppelyä, laajassa spektrissä.
Taajuushyppelyprotokollan ominaisuudet eivät ole relevantteja siirron suorituskykyyn, koska pääasiallinen syy huonoon suorituskykyyn on vuorovaikutus media-access(MAC) protokollan ja TCP:n välillä
Luotettava link-layer protokolla jota käytetään verkossa virhekontrollia varten on yksinkertainen frame-by-frame protokolla,jossa ikkunakoko on1.
kun kehys on vastaanotettu, vastaanotin lähettää link-level ACK:in lähettäjälle.
jos kehys ei ole vastaanotettu onnistuneesti, lähetin lähettää sen timeout jakson jälkeen.
tarve merkittävään turnaround aikaan päätelaitteissa johtaa high-packet overheadiin.
RTS/CTS protokollan vaihtaminen tarvitsee varmistusta kun kohteena oleva päätelaite on muuten kiireinen.
Tämä johtaa laajoihin ja muuttuviin kommunikaatio viiveisiin verkoissa. Lisäksi asymmetriseen työkuormaan useimpien datavirtojen kanssa yhteensuuntaan asiakkaille.
ACK:lla on taipumus ruuhkautua tietyissä laitteissa, kuten asiakkaiden modeemeissa.
Nämä vaihtelevat viiveet ja ACK jonot vaikuttavat pehmeään datavirtaan.
Erityisesti ,TCP ACK liikenne häiritsee datavirtaa ja lisää liikennekuormaa järjestelmässä.
Yleensä,oikea tapa uudelleenlähetysajastimelle on laukaista uudelleenlähetys segmentti tietyn ajan jälkeen joka riippuu sekä round-trip ajasta ja lineaarisesta poikkeamasta.
Linkkikerroksen optimointi, virhekontrolli protokolla joka toimii linkkikerroksen ACK:t datakehyksillä vähentää TCP round-trip vaihtelua jossain määrin.
Liikenne molempiin suuntiin, jopa TCP ACK:ien aiheuttamina, aiheuttaa turnaroundeja. Niinpä jos linkkikerroksen ACK:t toimivat datakehyksillä, muutamia ylimääräisiä päätelaitteiden turnaroundeja voidaan poistaa.
Huolimatta optimoinnista, perusongelma lisäliikenteessä ja taustalla olevissa protokollissa, jotka vaikuttavat round-trip aika arvioihin ja aiheuttavat muuttujia suorituskyvyssä on yhä olemassa.
poikittaiset multiple hops yhteydet langattomissa verkoissa ovat haavoittuvampia tälle vaikutukselle, koska on todennäköisempää että päätelaitteet voivat jo olla sitoutuneina keskusteluun muiden päätelaitteiden kanssa.
10.3 TCP suorituskyvyn parantaminen asymmetrisissä verkoissa
10.3.1 Uplink Bandwidth Management
10.3.2 Handling InfrequentACKs
Uplink kaistanleveyden hallinta voidaan suorittaa valvomalla pakkauksen tasoa, taajuutta ja upstream ACK:iden aikataulutusta.
TCP otsikon pakkaus
TCP otsikkopakkaus kuvaa TCP otsikon pakkausta käytettäessä low-bandwidth linkkejä, jotka käyttävät SLIP tai PPP protokollaa.
Koska se huomattavasti vähentää ACK:iden kokoa uplinkissä kun hävikit ovat epäsäännöllisiä, sen käyttö on suositeltavaa low-bandwidth uplinkeissä jos mahdollista.
TCP otsikkopakkaus ei yksin kata kaikkia ongelmia:
• tietyissä verkoissa on merkittävä per-packet MAC overhead joka on riippumaton paketin koosta.
• ACK:iden koon vähennys ei estä vastakkaista vuorovaikutusta suurien upstream datapakettien kanssa kaksisuuntaisen liikenteen yhteydessä.
• jos halutaan tehokkaasti vaikuttaa suorituskykyongelmiin, joita aiheuttaa asymmetria tarvitaan tekniikkaa over and beyond TCP otsikko pakkauksen.
ACK Filtering(AF)
ACK suodatus(AF) on TCP linkkikerros tekniikka joka vähentää TCP ACK:iden lukumäärää joita lähetetään upstream kanavalla.
Haasteena on varmistaa että lähettäjä ei jää odottamaan ACK:eja, joka voi tapahtua jos ACK:ta poistetaan upstream lähteestä. AF poistaa vain tietyt ACK:t näännyttämättä lähettäjää hyödyntämällä siitä tosiasia että TCP ACK:t ovat kumulatiivisia.
Mitä tulee lähettäjän virhekontrolli mekanismiin se informaatio mikä on ACK:ssa with later sequence number subsumes the tiedon joka on sisältynyt aikaisempiin ACK;hin.
Kun ACK vastaanottimesta on menossa jonoon upstream pullonkaula reitittimessä, reititin or the end-host linkki kerroksessa tarkistaa jononsa vanhat ACK:it jotka kuuluvat samaan yhteyteen. Jos niitä löytyy, se poistaa ne jonosta niin vähentäen ACK:iden määrää jotka menevät takaisin lähettäjälle.
Näiden ACK:iden poistaminen vapauttaa puskuritilaa muulle datalle ja ACK paketeille.
AF ei poista duplikaatti tai selective ACK:ia jonosta että vältetään ongelmat TCP:n hävikistä elpymismekanismissa.
ACK congestion control(ACC)
ACK ruuhkan hallinta on vaihtoehto ACK suodatukselle joka toimii päästä päähän mielummin kuin upstream pullonkaula reitittimessä.
Avainidea ACC:ssa on laajentaa ruuhkan hallintaa TCP ACK:hin, koska ne muodostavat merkittäviä vaatimuksia resursseihin upstream linkkiin.
ACK:it muodostavat osioita upstream kanavapuskuriin, joiden kapasiteetti on usein rajoitettu tiettyyn lukumäärään paketteja.
ACK:s First Scheduling
kaksisuuntaisessa siirrossa data ja ACK paketit kilpailevat resursseista upstream suuntaan.
Tässä tapauksessa yksittäinen FIFO jono sekä datapaketeissa että ACK:issa voi aiheuttaa ongelmia.
esimerkiksi jos upstream kanava on 28.8 Kbps dialup linjalla, 1 –KB-kokoisen paketin siirto voi kestää 280 ms.
Näin ollen jos vain kaksi sellaista datapakettia menevät jonoon ACKien edelle ne sulkevat ACK pois puolen sekunnin ajaksi.
ACK reconstruction
ACK reconstruction(AR) on tekniikka jolla rekonstruoidaan ACK virtaa joka on kulkenut upstream suuntaan pullonkaulalinkissä.
AR on paikallinen tekniikka joka on suunniteltu estämään vähentynyt ACK:iden määrä joka haitallisesti vaikuttaa TCP lähettäjän sovellusten suorituskykyyn.
Tämä mahdollistaa aikataulujen käytön kuten ACK suodatus tai ACK ruuhkan hallinta vaatimatta, että TCP lähettäjät modifoidaan suorittamaan lähettäjän sovitusta.
Tämän ratkaisun voi Internet Service Provider(ISP) helposti ottaa käyttöön saavuttaakseen hyvän suorituskyvyn.
10.4 Suorituskyvyn parantamis- tekniikoiden kokeellinen arviointi
10.4.1 Experiments with Bandwidth Asymmetry
10.4.2 Experiments with Media-Access Asymmetry
Kaistanleveys asymmetrian kokeet
Kokeissa käytetään 10-Mbps downlink ja a 28.8 –Kpps uplink with TCP otsikon pakkauksella..
maksimi ikkunakoko on asetettu 120 pakettiin ja jonokoot asetettiin 10 pakettiin.
AF/AR ja AF/SA suoriutuvat parhaiten saavuttaen troughputit 15 – 21 prosenttia paremmin kuin Reno.
ACC/SA suoriutuu 5 prosenttia paremmin kuin Reno.
Tärkeä asia on että purskeisuuden määrä vähenee merkittävästi, koska upstream reititin jono ei ole enää jatkuvasti täynnä AF tai ACC ansiosta.
Taulukko osoittaa, että ACK:iden toistumisen vähentäminen ei ole riittävä ja myös SA ja AR tekniikoiden käyttämistä tarvitaan.
AR johtaa suurempaan round-trip aikaan kuin muut protokollat, mutta tämä johtaa parhaaseen suorituskykyyn näillä parametreillä koska se vähentää hävikkien lukumäärää
yhteenvetona tulokset, osoittavat että SA tai AR ovat tärkeitä selviydyttäessä purskeista jotka on tuloksena hävikkiä tuottavasta ACK virrasta.
ks. dia 32.
Kokeet Media-Access asymmetrialla
kokeessa käytettiin Ricochet verkon mallia.
työkuorma tässä kokeessa sisältää 100-sekunnin TCP siirron, ilman kilpailevaa liikennettä ja maksimissaan vastaanottimen 32 KB:n ikkunakoolla
ruuhkahävikit ilmenevät tuloksena puskurin ylivuodosta ja johtavat lähettäjän timeoutteihin jos paketteja menetetään siirtoikkunassa.
tutkittuihin protokolliin kuului modifioimaton TCP Reno, Reno with ACC/SA ja Reno with AF/SA
dia 35 osoittaa tulokset kokeesta AF:n ja ACC:n suorituskyky SA:n kanssa on parempi kuin Renon ja AF/SA on parempi kuin ACC/SA
10.6 Yhteenveto
Verkkoasymmetria, liittyen kaistanleveyteen, media-accessiin ja loss rateen voi vaikuttaa vakavasti feed-back siirtoprotokollan suorituskykyyn, kuten TCP:hen.
10.9 Case Study: Improving TCP Performance over ADSL
Vaikka suurin osa WCORP työntekijöistä tekee
töitä toimistossa, jotkut etätyöskentelevät kotonaan yhden
tai kaksi päivää.
Kotona etätyöskentely tarjoaa joustavuutta ja tekee
työnteosta houkuttelevamman.
Aikaisemmin työntekijät käyttivät soittoyhteyttä
Internettiin.
Työntekijät kohtasivat kolme pääasiallista ongelmaa:
pitkät latausajat, epäluotettavat yhteydet,
äänipuhelut eivät toimineet internetyhteydet aikana. Siksi
WCORP siirtyi ADSL:n käyttöön.
WCORP case study
ADSL käytössä todettiin kuitenkin, että sen nopeus oli alhaisempi kuin
ajateltiin ja ruuhkat dataliikenteessä aiheuttivat latausongelmia.
Matalatasoinen throughput johtui ACK ruuhkasta uplinkissä(kotoa
Internettiin) Uplink kapasiteetti todettiin 150 kertaa hitaammaksi kuin
downlink.
TCP lähettäjä ei voinut palvelinpuolella pumpata dataa nopeammin
koska ACK paketit saapuivat hitaasti asiakkaan puolelta.
Ratkaistakseen TCP ongelmat kotikäyttäjillä, WCORP mietti kolmea
tekniikkaa:
TCP otsikko pakkausta, ACK suodatusta ja ACK ruuhkanhallintaa.
TCP otsikkopakkaus valittiin lopulta tekniikaksi.
Kaikki koti TCP/IP.t päivitettiin TCP otsikko pakkauksella, jonka avulla
saatiin merkittävästi vähennettyä ACK pakettien kokoa.
Mittaus osoitti selvää parannusta latausaikoihin.
Latauskapasiteetista voitiin hyödyntää 95 %
Lähteet
Mahbub Hassan, RaJ Jain. High Performance TCP/IP Networking.
www.mit.jyu.fi/arjuvi/opetus/ties422/wimax.ppt 9.5.2008
sunnuntai 13. huhtikuuta 2008
Digiboksi matkailuautoon
Asensin Dantaxin antenniboksin matkailuautoon, televisioon, jossa ei ollut scart-pistoketta.
Auton kattoanteenniss oli jotain vikaa, joten kytkin antennijohdon televisipon omaan antennin. RF-modulaattorikanavaksi piti valita 40. Viritn televisiosta yhdeksän kanavaa digikanavalle. Mark-merkkisestä televisiosta piti viritystä varten valita kanava ja painaa reset-nappulaa ja sitten auto search-nappulaa, jolloin kanavahaku käynnistyi.
Sitten uudestaan reset
Auton kattoanteenniss oli jotain vikaa, joten kytkin antennijohdon televisipon omaan antennin. RF-modulaattorikanavaksi piti valita 40. Viritn televisiosta yhdeksän kanavaa digikanavalle. Mark-merkkisestä televisiosta piti viritystä varten valita kanava ja painaa reset-nappulaa ja sitten auto search-nappulaa, jolloin kanavahaku käynnistyi.
Sitten uudestaan reset
torstai 20. maaliskuuta 2008
Samsung digiTV
torstai 13. maaliskuuta 2008
Humax ja LG

Humax-kaapeliboksi oli kytketty verkkoon, jossa televisioon tuli signaali myös keskusboksista.
Humax digiboksi ja LG digiboksi oli liitetty toisiinsa AV1 kautta. Asetuksissa oli aluksi väärä AV-kanava ja DVD ei tallentanut mitään.
Digiboksi kytektään ensin päälle ja sitten DVD-laite-
Kun DVD-laitteeseen laitettiin ajastus ja valittiin signaalilähteeksi AV1, niin virta piti katkaista DVD-laitteesta, jotta ajastus toimi.
keskiviikko 12. maaliskuuta 2008
Aika paha
maanantai 10. maaliskuuta 2008
Medion
Topfeld
perjantai 1. helmikuuta 2008
Nuoskalunta lautasella
Tilaa:
Blogitekstit (Atom)