Kysymys

Jyväskylä (Viihde hidastelua)

  • 9 syyskuu 2012
  • 14 kommenttia
  • 1768 katselukerrat

Nyt on ollut kolmisen viikkoa ollut nopeudet luokkaa 0,3Mbps ja ulos 4Mbps parhaimmillaan pääsen 10 pintaan.  Viimekuun alussa toimi vielä mainiosti, naapuri oli ilmeisimmin tehnyt vikarin omasta liittymästään jonka jälkeen (arvio) tämä kyseinen jumitus on ilmestynyt.

Siinä on testiä jyväskylään kun mitään liikennettä verkossani ei tapahdu. Sivut virheilevät myös usein ja jäävät latautumatta.



Modeemi on resetoitu (bewan)

On koitettu suoraa koaksiaalia joka on lyhempi myös ilman filtteriä/jaotinta


Reitittävä/sillattu koitettu


Suoraan modeemiin kone kiinni ethernetillä


 


Kummallisinta myös että hetki resetin jälkeen kerran tarjosi 92Mbps-nopeuksia kunnes bewan hyytyi taas. Modeemi myös päätti tänä aikana vaihtaa itsestään bridged-tilasta routed-tilaan joka ei ole kovin vakuuttavaa mielestäni. Jotenkin vaikuttaa hieman että saattaa olla modeemi tullut tiensä päähän.

Vikailmoitus tehty ja toivotaan että tilanne alkaa selviämään.

14 kommenttia

Itsellä myös ongelmia Jyväskylän erään alueen Elisa Viihde kaapelimodeemyhteydessä, mutta ongelmani on toisenlainen.

Nimittäin yhteyteni latenssi heittelee +30 - +500 ms (arvioitu) välillä jos samaan aikaan lähetän kamaa nettiin yli 3 Mbit/s nopeudella. Tällöin tulee myös ajoittain packet lossia.

Ongelmani alkoi jo elokuun 20pv alkavalla viikolla jossain vaiheesa. Tiedostin että wan-yhteydessäni on jotain mätää kun www-sivut alkoivat lataamaan todella hitaasti. AJAX pohjaiset www-sovellukset kun eivät tykkää isosta latenssista. Tein samalla viikolla vikailmoituksen asiasta (muistaakseni? mulla välillä muisti pettää näissä asioissa).

Tein täysin omasta aloitteestani melko mittavan kartoituksen myös, otin ping-statistiikkaa ja traceroutee. Vaiheessa kun olin jo kolmannen kerran tehnyt vikailmoituksen, sain viimein erään tytön ystävällisesti liittämään verkkoanalyysini vikatikettiin. Viimeisin soitto vikapalveluun (kolmas tai neljäs?) paljasti, että olen _ainut_ joka minun alueelta (ilmeisesti: verkkosegmentistäni) tehnyt tämän ilmoituksen; peruskäyttäjät eivät edes tiedosta ongelmaa koska heillä ei ole jatkuvaa uploadia päällä. Ja koska olen ainut, niin .. no, voipi olla että vika käsitellään suht matalalla prioriteetilla.

Vika ilmaantui aivan yhtäkkiä keskenkaiken. Toimi ennen vallan mainiosti.

Vika on joko Bewan IBox kaapelimodeemissa, CMTS/päätereitittimessä ja sen konffeissa tai molemmissa.

Tässä vielä tarkempi analyysi jonka jo aiemmin lähetin sähköpostilla elisalle:

Current Firmware : C50D01-Elisa5-56172

Bewan iBox on sillattuna, elikkä saan julkisen IP-osoitteen
pöytäkoneelleni. Ajettu pingiä googleen samaan aikaan kun tehty
speedtest.net nopeustesti kaksi kertaa, ja jokaisen upload testin alku
ja loppu merkattu pingien väliin:

C:Usersksym>ping -t 173.194.32.55

Pinging 173.194.32.55 with 32 bytes of data:
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=25ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=26ms TTL=56
Reply from 173.194.32.55: bytes=32 time=23ms TTL=56
Reply from 173.194.32.55: bytes=32 time=24ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=26ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
--- SPEEDTEST.NET UPLOAD TEST ALKOI ---
Reply from 173.194.32.55: bytes=32 time=470ms TTL=56
Reply from 173.194.32.55: bytes=32 time=680ms TTL=56
Reply from 173.194.32.55: bytes=32 time=330ms TTL=56
Reply from 173.194.32.55: bytes=32 time=56ms TTL=56
Reply from 173.194.32.55: bytes=32 time=164ms TTL=56
Reply from 173.194.32.55: bytes=32 time=70ms TTL=56
Reply from 173.194.32.55: bytes=32 time=276ms TTL=56
Reply from 173.194.32.55: bytes=32 time=335ms TTL=56
Reply from 173.194.32.55: bytes=32 time=138ms TTL=56
Reply from 173.194.32.55: bytes=32 time=256ms TTL=56
Reply from 173.194.32.55: bytes=32 time=86ms TTL=56
Reply from 173.194.32.55: bytes=32 time=225ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=276ms TTL=56
Reply from 173.194.32.55: bytes=32 time=290ms TTL=56
Reply from 173.194.32.55: bytes=32 time=213ms TTL=56
Reply from 173.194.32.55: bytes=32 time=239ms TTL=56
--- SPEEDTEST.NET UPLOAD TEST LOPPUI ---
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=24ms TTL=56
Reply from 173.194.32.55: bytes=32 time=23ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=26ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=25ms TTL=56
Reply from 173.194.32.55: bytes=32 time=22ms TTL=56
Reply from 173.194.32.55: bytes=32 time=26ms TTL=56
Reply from 173.194.32.55: bytes=32 time=23ms TTL=56
Reply from 173.194.32.55: bytes=32 time=25ms TTL=56
Reply from 173.194.32.55: bytes=32 time=30ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=23ms TTL=56
Reply from 173.194.32.55: bytes=32 time=27ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
Reply from 173.194.32.55: bytes=32 time=19ms TTL=56
--- SPEEDTEST.NET UPLOAD TEST ALKOI ---
Reply from 173.194.32.55: bytes=32 time=429ms TTL=56
Reply from 173.194.32.55: bytes=32 time=698ms TTL=56
Reply from 173.194.32.55: bytes=32 time=55ms TTL=56
Reply from 173.194.32.55: bytes=32 time=249ms TTL=56
Reply from 173.194.32.55: bytes=32 time=46ms TTL=56
Reply from 173.194.32.55: bytes=32 time=238ms TTL=56
Reply from 173.194.32.55: bytes=32 time=105ms TTL=56
Reply from 173.194.32.55: bytes=32 time=324ms TTL=56
Reply from 173.194.32.55: bytes=32 time=292ms TTL=56
Reply from 173.194.32.55: bytes=32 time=274ms TTL=56
Reply from 173.194.32.55: bytes=32 time=177ms TTL=56
Reply from 173.194.32.55: bytes=32 time=237ms TTL=56
Reply from 173.194.32.55: bytes=32 time=49ms TTL=56
Reply from 173.194.32.55: bytes=32 time=141ms TTL=56
Reply from 173.194.32.55: bytes=32 time=67ms TTL=56
Reply from 173.194.32.55: bytes=32 time=189ms TTL=56
--- SPEEDTEST.NET UPLOAD TEST LOPPUI ---
Reply from 173.194.32.55: bytes=32 time=25ms TTL=56
Reply from 173.194.32.55: bytes=32 time=23ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=20ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56
Reply from 173.194.32.55: bytes=32 time=27ms TTL=56
Reply from 173.194.32.55: bytes=32 time=21ms TTL=56

Ping statistics for 173.194.32.55:
Packets: Sent = 94, Received = 94, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 19ms, Maximum = 698ms, Average = 96ms

Pingin uploadin aikaisen vaihtelun lisäksi teidän verkkotopologiassa on
jotain tosi outoa mitä maallikon vaikea käsittää. Kattokaas tätä tracert
tulosta tästä:

C:Usersksym>tracert elisa.fi

Tracing route to elisa.fi [193.229.2.137]
over a maximum of 30 hops:

1 6 ms 6 ms 9 ms 10.15.64.1
2 10 ms 8 ms 10 ms 172.29.249.217
3 8 ms 7 ms 9 ms ge0-2-0.jyvyo-p2.fi.elisa.net
[139.97.16.205]
4 16 ms 15 ms 15 ms Te4-1.helka-dc2.fi.elisa.net [139.97.19.141]
5 Te4-1.helka-dc2.fi.elisa.net [139.97.19.141] reports: Destination
net unre
achable.

Trace complete.

Mitä noi RFC private ip -alueella olevat nodet tuossa tekee? Eikös
noissa 2 ekassa hypyssä pitäs olla ihan elisan subnetin mukaset julkiset
IP-osoitteet reitittimillä? Vai onko tässä joku ihmeen full-cone nat
viritys, tunnelointi tai muu peeringiin liittyvä omituisuus?

Kuten voi huomata, niin joku on pahasti vialla. Vika on todennäköisesti
joko CMTS:än konffeissa, Elisan reitittimissä TAI (todennäköisimmin)
tässä modeemin uudessa firmispäivityksessä.

Aikaisemmin mulla oli Saunalahden kaapelimodeemiliittymä, ja modeemissa
vanhempi firmis. Se toimi ihan hyvin. Alunperin mulla oli Elisa
viihteessä ongelmana ettei siltaus toiminut, ja siksi mulle tähän Elisa
viihteen bewaniinkin ladattiin teidän kautta se vanhempi firmis ...
mutta nyt taas sen yli on ajettu tää uusi firmis jonka pätevyyttä
suuresti epäilen.

Mulla on jatkuvasti uploadia mun verkosta. Ja siksi peruskäytössä mun
pingi huitelee 30 - 300ms välillä, mikä on erittäin tuskallista koska
mun normaalit nettiä käyttävät softatkin valittaa timeouteista ja muista
kun ne TCP:n keep-alive paketit ei pääse perille ajoissa.

Myös packet lossia esiintyy JOS mä pidän uploadin käytössä pitempään. Laitoin copypasten koska olen laiska. Mutta tästä pitäisi nyt tulla joo aika selville että jotain ihmehommia siellä on.

En enää pysty keksimään että mitä testejä voisi vielä ajaa, ja Elisan käsissä tuo vian tutkiminen on.

Ostin Cisco EPC-3000 modeemin ja aion ens viikolla testata sillä. Olen sitä mieltä että noi Elisan tekemät firmispäivitykset rikkoo Bewanit TAI sitten noi Bewanit on vaan itsestäänhajoavaa kakkendaalia; kummassakin tapauksessa naamapalmutan itseäni kun en hankkinut omaa modeemia jo aikoja sitten -,-
Käyttäjätaso 7
Kunniamerkki +2
Aina Elisan verkossa on olluit noita sisäisiä 10. ja 172. -sarjan osoitteita tuossa välissä. 

Kuten täältäkin katsottuna nyt:

C:UsersKooMikko>tracert elisa.net

seurataan reitti isäntään elisa.net [193.229.3.143]
enintään 30 siirräntävälillä:

1 2 ms 1 ms <1 ms 192.168.1.1
2 29 ms 30 ms 11 ms 10.6.64.1
3 25 ms 25 ms 11 ms 172.29.249.201
4 11 ms 12 ms 40 ms xe1-0-0.helpa-p2.fi.elisa.net [139.97.29.74]
5 11 ms 12 ms 13 ms Te4-1.helka-dc2.fi.elisa.net [139.97.19.141]
6 14 ms 12 ms 9 ms port11a.elisa.net [193.229.3.143]

Seuranta suoritettu.

Suurin osa käyttäjistä huomaa vain täysin katkeavan yhteyden, ei mitään siitä välistä. Onko sinulla piuhalla vai wlanilla kiinni tietsikat? Olethan tehnyt modeemille (ja muillekin värkeille) resetit ja tehdasasetusten palautukset? Varmuudeksi eri antennijohdollakin vielä testannut, jos hieman heilunut kaaplei/modeemi ja jotain sen vuoksi tullut ongelmaa.
Jännää topologiaa kyllä noi private rangen nodet.

On resetoitu laitteet kyllä, antenninjohto on se joka tän liittymän mukana tullut tuossa vähän yli vuosi sitten eikä ne vuodessa tuppaa hajoamaan eikä mulla ole toista kaapelia millä testata.

Sensijaan ostin Cisco EPC-3000 modeemin jolla testaan. Sen mukana tulee myös koksikaapeli ja vieläpä T-liitin.

Olen aika varma että toi uus firmispäivitys nämä ongelmat aiheuttanee, tai sitten se että Bewan on hieman väsähtänyt. Paras ratkaisu on hommata vaan toinen modeemi, joka toivonmukaan toimii paremmin.

Jos modeemin vaihtaminen ei auta, niin onpahan ainakin enemmän laitteistoa millä testailla. Sitten pitää vaan toivoa että teknikot siellä tekee asialle jottain.

PS. meinasin valtuuttaa mun vanha saunalahdenaikaisen Bewanin missä se vanhempi taatusti toimiva firmis, mutta en sitten jaksanut. Se ois kuitenkin ottanut uuden firmiksen sisäänsä heti kun seuraava päivitysajo ajetaan jne. Parempi ottaa semmonen modeemi tohon mikä ei ota Elisan tarjoamaa firmistä laisinkaan. Saadaan tästä yksi epävarmuustekijä pois.
JA vika oli kuin olikin Bewan Iboxin firmiksessä C50D01-Elisa5-56172. Kyseisellä firmiksellä jos lähettää nettiin tavaraa, niin latenssi nousee sietämättömäksi!

Noniin, ja viittiskö Elisa nyt nopeasti vaan pistää asiakkailleen uudet firmikset? Minuahan tämä ei haittaa, mutta veikkaan että suurin osa Elisan asiakkaista pelaa ihan heille toimitetuilla vehkeillä eivätkä ole toista tilalle hankkimassa.
Käyttäjätaso 3
Tarkistin juuri modeemini version ja se on tuo yllämainittu. Yhteydessä ei kuitenkaan ole häikkää. Mistä sait tiedon, että tuo firmis olisi jotenkin epäkelpo?
Elisalta ilmoittivat että verkossa Elisan päässä ei ole vikaa. Siellä oli kuulemma joku tehnyt tarkistukset, ja epäilen että rutiininomaisesti näitä tarkistuksia tekevät ammattilaiset siellä jossain organisaation nurkkauksilla tekee virheitä.

Toisekseen, ongelmani korjaantui kun vaihdoin Cisco EPC-3000 modeemiin.

Kolmannekseen, DOCSIS 3.0 standardin mukainen kaapelimodeemiväylä on jaettu väylä. Tämä tarkoittaa että samalla väylällä menee digiTV:n data ja kaikkien tietyssä segmentissä (saman koksin varrella) olevien modeemien data. Jos kaapelimodeemin firmis on halpatyöllä tuotettu fiasko, tämä mielestäni selittää sen että jos samalla väylällä on enemmän tilaajia kuin muutama niin tulee ongelmia.

Lueskelin netistä sitten wikipediasta vähän terminologiaa, sitten jostain tekniikkaihmisten foorumeilta lisää tietoa ja tein hieman päätelmiä.

http://volpefirm.com/blog/docsis-3-0/upstream-channel-bonding/

At a very basic level, the CMTS assigns each upstream channel with a service flow. The Best Effort service flow is a just one of many “SID Clusters” that assigns this type of service flow to each channel in the bonding group. Queuing in the cable modem buffers data and then bandwidth REQs on any upstream from the CM allow the CMTS to load balance the CM by sending back MAP Grants to any upstream channel. Why would load balancing be necessary? For one the CMTS is managing many cable modems, some of which could be legacy DOCSIS 1.x/2.0 modems using only one of the available channels in the bonding group. Further, there could be impairments on some upstream channels seen by some modems. Higher levels of service flows will be established for QoS by the CMTS, this will be another SID Cluster and spread across the bonding group so that load balancing can also occur for that particular QoS service flow to achieve the best possible performance in the case of traffic or impairments.

A channel in a bonding group may become unusable due to say upstream impairments. In this case, if the CMTS becomes aware of the outage, it will stop providing opportunities for CMs to transmit on that channel (i.e. MAP grants). If the CM becomes aware, it will stop sending REQs for data. Both the CM and CMTS will continue to do Initial Ranging (i.e. the cable modem will continue to establish communication with the CMTS) until the channel become available.Ja siis edellisestä lainauksesta korostan nimenomaan tuota ehdollista kohtaa:

IF the CM becomes aware, it will stop sending REQs for data.

Eli voisikohan olla näin, että kun samalle kanavalle sattuu liian monta pyyntöä lähettää dataa (joka taasen aiheuttaa sitä että modeemit joutuvat odottamaan vuoroaan liian pitkään), CMTS käskee modeemin pitää naamansa ummessa ja ettiä toinen kanava. Mutta jos modeemin firmis on tyhmä, niin se ei tätä tajua vaan jääräpäisesti jatkaa entisellä kanavalla ihan kuin mitään ei olisi tapahtunut, kärkkyen vuoroaan letku ojossa että pääsis vähän bittiä suhauttaan. Sitten on kaikilla upstream tukossa, mutta vain ne asiakkaat jotka sitä bittiä sylkee huomaa ongelmat (itsellä on jatkuvasti liikennettä).

Lyhyesti: DOCSIS 3.0:ssa samassa koksissa tanssivien motujen pitää tehdä yhteistyötä (CMTS:än arbitroimana tietenkin) koska useampi modeemi jakaa upstream (taajuus) kanavat (datan lähetykseen). Mitäs jos firmis on huono? Voitas olettaa että osa modeemeista, eritoten ne jotka olisivat jatkuvasti lähettämässä, joutuvat odottamaan linjalla vuoroaan jos muut on huutaa kanavalle bitti ojossa. Tai jos firmis on huono, niin ehkä se ei osaa jutella tietyn CMTS:än kanssa. Tai jotain vastaavaa.

Ehkä sinun tapauksessasi on niin, että joko 1) muut samassa koksissa huutavat modeemit eivät juurikaan käytä lähetyskaistaa (ja minun tapauksessani uppaavat niin himona) tai 2) sun CMTS:än takana on vähemmän tilaajia eli modeemeita (kun taas mulla on samassa koksissa koko kylä)

En ole sertifioitu teknikko, mutta kokemusta on myös vanhoista 10 Mbit ethernet hubeista joissa latenssit lähetyksessä nousivat kaakkoon jos oli liian monta konetta kiinni ... logiikan puolesta sama juttu, erilaiset käytännöt vaan.

Hieman kärjistettyjä esimerkkejä, mutta toimivat varmaan että saan oman logiikkani selitettyä?
Ja teeppä tosiaan semmoinen testi, että pistät komentokehotteen jossa ping -t google.fi, sitten aloitat vaikka Soneran nopeustestin.

Katso nouseeko sun pingi sinä aikana kun nopeustestissä on Upload Test käynnissä.
Käyttäjätaso 3
Hmm, vaikuttaa vakuuttavalta. Kone on nyt hyrskyttänyt toista vuorokautta varmuuskopiota Sonera Nettiarkistoon, jonka otin 30 vrk kokeiluun. Speedtest antoi tällaiset tuloksen:

(Jostain syystä ei toiminut forum link)

http://www.speedtest.net/result/2181137048.png  

Normaalisti ping on reilusti alle sadan ja nopeudet n80/5. Kyllä tuossa jotain häikkää hennoo olla.

Lisäys: Laitoin 3g-läppäriini (sama läppäri edelleen) sim-kortin ja kopasin nopeustestin saman varmuuskopioinnin aikana. Nopeudet putosivat huomattavasti edellisistä ja HSDPA-kentässä mentiin. Mitenkähän tuohon nyt pitäisi suhtautua? 
Lisäys: Laitoin 3g-läppäriini (sama läppäri edelleen) sim-kortin ja kopasin nopeustestin saman varmuuskopioinnin aikana. Nopeudet putosivat huomattavasti edellisistä ja HSDPA-kentässä mentiin. Mitenkähän tuohon nyt pitäisi suhtautua? Noh, 3G-verkon ongelmat on otaksuttavasti erillään kaapelimodeemin ongelmista. 3G-verkot tuppaa olemaan epäluotettavia. Suosittelisin tuosta 3G:n hidastelusta soittelemaan Elisan vikapalveluun jos jatkuu.

Ja soitappa toki vikailmoitus tuosta kaapelimodeemiongelmastakin. Elisalla se byrokratia estää tuon kaapelimodeemien vian korjaamisen, kunnes tarpeeksi monta asiakasta tekee vikailmoituksen. Ainoastaan sosiaalisella massapaineella tästä johonkin päästään.

Mun piti laittaa tästä raportaasia Blogiin ja linkittää sitä pitkin sosiaalisia medioita mutta olin laiska. Ehkä tossa joskus voisin aloittaa sosiaalisen kampanjan tilanteen korjaamiseksi, mutta pitää miettii että miten sen toteuttaa.
 
Käyttäjätaso 3
Tuntuu vähän siltä, ettei tuossa modeemissa välttämättä ole ongelmaa vaan läppärin suorituskyvyssä kuormitettuna. Samaan aikaan kuitenkin muut modeemin wlanin perässä olevat laitteet toimivat wlanin nopeuden puitteissa (n 20/4).

3-g verkon normitulos:

http://www.speedtest.net/result/2184288707.png

Joten siitäkään ei saa vikailmoituksen tynkää aikaiseksi.

Ja kaapelimodeemin kautta normitulos:

http://www.speedtest.net/result/2184296328.png

Kuulostellaan mistä on kyse.
Hienosti hijackattu thread sinänsä :smileyazn:



Tämänpäiväisiä nopeuksia Bewanilla (minua koskeva ongelma korjattu?) rollattu uusi firmis? info kulkee ja sitä rataa... noh cisco on tulossa postissa ja tuleepahan se vaihdettua ihan siitä syystä että siihen en kyllä voi enää luottaa että bewan jaksaa bridged-modessa pysyä.
Postaa pliis että mikä firmisversio sulla bewanissa.

C50D01-Elisa5-56172 <--- tuo on se, mitä epäilen vialliseksi.

Elikkäs jos sulla on joku muu firmis, niin sitten Elisalla herättiin ja tehtiin asialle jotain :D

Jos taasen sama firmis ja silti toimii niin hyvin, niin ... sitten vika on melkoisen ufo ja pitää spekuloida vähän lisää 😉 Päivittelen uutta hyödyllistä tietoa mun omaan threadiini missä tällä hetkellä väitän firmistä vialliseksi.
Niinjoo, ja tee ping -t google.fi samaan aikaan kun speedtest tekee upload testiä, että saat selville varmasti että nouseeko pingi sen uploadin aikana vai ei. Tämä myös olennainen ehkä.
Käyttäjätaso 3
Tuli tämä todennettua.

Bewanin firmisversio C50D01-Elisa5-56172

Ping -t www.sonera.fi

Osallistu keskusteluun