jlaakso, en käytä tota 10M lankalinjaa mihinkään muuhun kuin striimaukseen, joskus aniharvoin saatan sitä kuormittaa mutta pääosin se saa olla rauhassa kun siitä voi heikoimpana hetkenä irrota ainoastaan pari megaa mutta musalle sekin riittää kunhan yhteys ei vaan missään kohtaa katkea eikä se olekkaan sen jälkeen kun pyhitin sille oman linjansa, sen antenneja saatan vielä modata jos niille edes mitään voi tehdä tai vaihtaa tilalle herkemmät. Nämä kaikki ongelmat siirtyi muun liikenteen rienaksi, se kun menee nyt ton mokkulatukiaseman kautta.
Kanavat jotka skannasin tämän vuoden alussa on nykypäivänä juuri ne väärät kanavat eikä noita molempia parane laittaa samalla, takkuaa melkosesti jos puhelimen ja tukiaseman välissä on toista tukiasemaa käyttävä laite, pahimmillaan putoo molemmat linjalta.
Oli se sittenkin tuon MTU:uun syytä, liikennettä simuloiva ja mittaava Tamosoft throughput client-serveri softa kertoi todella karua kieltä yhteyden toiminnasta, 100% download UDP paketeista rikki, TCP download ja upload sekä UDP upload toimi kohtuu hyvin. Ronkkisin sitä MTU asetusta rekisteriin adapteri kohtaiseksi ja sama homma com promptilla, yli 1423 bittiä suuremmat paketit fragmentoitui aina ja koitin 1422 arvoa jolla parani hetkeksi mutta kun se ei ollut 8:lla jaollinen niin oli pakko pudottaa tasolle 1416 asti.
Ihmettelin miksi pingaus-paketit hajoaa aina askeleen (24bit) pienempänä joka testaus kerran välissä ja totesin että sama ongelma oli viimeksi kun ronkkisin MTU-arvoa mutta nyt hiffasin mikä sitä pakettin kokoa uudelleenkäynnistyksen jälkeen aina laskee, ne omat 1500:sta poikkeavat asetukset koska siinä on mukana tietty osa varrattuna header:ille joka nyky päivänä voi olla aika erikokoisen kokoinen ja siirtoväylältä sen alkuperäisen päälle ynnäytyvä lisätty, menee helposti siis jumbo-paketin 1500+ puolelle.
Normistihan vastaanottaja yrittää fragmentoituneen paketin saadessaan lähettää pyynnön lähettäjälle että "pienennä paketin kokoa xxxx" ja lähettäjä sen tekee. Joka tapauksessa paketin osittaminen hidastaa siirtoa aina koska lähettäjän pitää se "ositus" tehdä joka vie aina aikaa ja laskenta tehoa. En tiedä joutuuko vastaanottaja tekemään pyynnön paketin pienennyksestä aina siirron alkaessa vai jopa siirron aikanakin, anyway jos arvoa muuttaa vastaanottajan päästä niin se ei auta kuin hetkeksi, muutos on siis tehtävä lähettäjän päähän jotta se pysyy ja tulee automaattisesti aina oikein pyyntöjä lähettämättä.
Sain myös N-yhteyden toimimaan tasaisesti välillä 70-300Mb mutta se edellytti aika montaa asetuksen muutosta ja kokeilua verkkokortin osalta mukaanlukien LAN:i puolen receive/tranfer buffer johon se alennettu MTU vaikuttaa suoraan, niiden on täsmättävä.
Ero paremmin toimivan yhteyden ja aiemman jatkuvan takkuamisen välillä oli hyvin selkeä ja säännönmukainen ero lähetys ja vastaanottonopeudessa. Se oli aina vähintään 5megaa ja pahimmillaan jopa 15 kun putki oli operaattorin puolesta niin vapaa ja auki kun vaan voi, normaalisti siis 15MB sisään / 25MB ulos ja se ero tuli täysin saapuvien pakettien fragmentoitumisesta, tukiasema ei siis tee muuta pyynnöille kun lähettää saman paketin uudestaan kahdessa osassa ja ilmeisesti toistaa saman tempauksen seuraavan paketin kohdalla.
tei elämä olis liian helppoa niin koneen LAN:sovitin meni conffatessa siinä määrin poikittain ettei sille saa määrättyä toimivaa ip-osotetta mitenkään, se saattaa toimia jos antaa DHCP:een hoitaa arpomisen mutta eipä sillä piuhalla nyt mitään taas tee kun langaton kerrankin toimii kunnolla eikä rajoita kaistaa, sisäisten FTP-siirtojen kanssa sen sitten näkee liikkuuko 50MB tai enempi yhtä notkeasti, se on vielä testaamatta.
Tossa aika hyvät ohjeet MTU testaukseen ja ronkkimiseen win7 osalta, aiheesta löytyy melkosesti sivuja
https://www.sevenforums.com/tutorials/94721-mtu-limit-test-change-your-connections-mtu-limit.html