Kysymys

LTE-verkon vasteajat



Näytä ensimmäinen kirjoitus

114 kommenttia

MasaJussin tulokset alkavat näyttämään lupaavilta. Itselläni muutosta ei ole tapahtunut. Ping 8.8.8.8 tuottaa tulokseksi keskiarvon 74ms.

MasaJussi: Olisiko sinulla mahdollisuutta toistaa tuo sama testi kuormattuna? (Esim. Funetista null-tiedosto samaan aikaan latauksessa. Youtube ja muut vastaavat streamit kuormittavat vain harvoin koko kaistan, jos latausnopeus pyörii 50MB/s lukemissa.)
Käyttäjätaso 4
Kuormitettuna, lataus pilveen, dna 4G veppi, huawei E5186, ulkoiset antennit, x-pol,

ping ftp.funet.fi

Vastaus isännältä 193.166.3.2: tavuja=32 aika=26 ms TTL=247
Vastaus isännältä 193.166.3.2: tavuja=32 aika=27 ms TTL=247
Vastaus isännältä 193.166.3.2: tavuja=32 aika=25 ms TTL=247
Vastaus isännältä 193.166.3.2: tavuja=32 aika=23 ms TTL=247
Vastaus isännältä 193.166.3.2: tavuja=32 aika=24 ms TTL=247

Ping-tilastot 193.166.3.2:
    Paketit: Lähetetty = 49, Vastaanotettu = 49, Kadonnut = 0
             (0% hävikki),
Arvioitu kiertoaika millisekunteina:
    Pienin = 19 ms, Suurin = 45 ms, Keskiarvo = 29 ms

Big4_50.png
Käyttäjätaso 5
Kunniamerkki
Harmittavasti loppui puheaika tuosta sauniksen prepaidista, joten ei pääse mittaamaan miten kuormitus vaikuttaa pingiin elisan 1800Mhz & 800Mhz verkoissa. Mites esim. Papparainen sinulla, jolla on hyvä nopeus 1800Mhz verkossa, paraneeko, vai huononeeko pingi kuormitettuna?
Käyttäjätaso 6
Kunniamerkki +3
Pinging 8.8.8.8 (with 32 bytes of data):
Reply from 8.8.8.8: bytes=32 time=114ms TTL=56
Reply from 8.8.8.8: bytes=32 time=70ms TTL=56
Reply from 8.8.8.8: bytes=32 time=109ms TTL=56
Reply from 8.8.8.8: bytes=32 time=102ms TTL=56
Reply from 8.8.8.8: bytes=32 time=110ms TTL=56
Reply from 8.8.8.8: bytes=32 time=103ms TTL=56
Reply from 8.8.8.8: bytes=32 time=114ms TTL=56
Reply from 8.8.8.8: bytes=32 time=99ms TTL=56
Reply from 8.8.8.8: bytes=32 time=256ms TTL=56
Reply from 8.8.8.8: bytes=32 time=118ms TTL=56
Ping statistics for 8.8.8.8:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 256ms, Average = 119ms

1 GB null kuormattuna. Ensimmäistä kertaa tein tuon toivottavasti meni oikein, mittaustuloksen kopioin Asuksen Wla kortin hallinta sivulta. Eilen asensin uuden kortin koneeseen joka on tuollainen PCE-AC56 AC 1300 DUAL-BAND. tosin tuota toista taajuutta en vielä pääse käyttämään kun on vain tuo B593 s-22 käytössä, mutta odotellaan tuota  Huawei E5186 tuloa suomen kielisenä markkinoille.

http://www.jimms.fi/hae/AC1300%20PCI-E%20adapteri
Käyttäjätaso 3
--- 8.8.8.8 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99103ms
rtt min/avg/max/mdev = 30.810/45.048/59.991/6.664 ms

--- ns-secondary.funet.fi ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99858ms
rtt min/avg/max/mdev = 24.841/38.640/52.836/6.205 ms
Käyttäjätaso 6
Kunniamerkki +3
1.PNG
Käyttäjätaso 6
Kunniamerkki +3
  Mikä viive riitää mihinkin?   Nettipelit?   Netin selaaminen?   Millä viiveellä netti oikein tökkii. Mikä viive on liikaa?  Kun nopeutta saadaan kyllä.   Kuka tietää näihin vastauksen vai onko ehdotonta vastausta kellään?    No tulipas nyt monta kysymystä kerralla.   :smileyhuh:
Nettipelit ping-riippuvaiset eli fps, moba jne. alle 50ms = Erinomainen, alle 100ms = hyvä 100-150ms = ok. >150ms = huono. >250ms = pelikelvoton.

Netin selaaminen ei ole niin pingistä riippuvaista ja kaikki alle 500ms riittää sangen sujuvaan netin selaamiseen.

Myös netin tasalaatuisuus on otettava huomioon. Pingin heittelyt ja erityisesti packet loss on myrkkyä pelattavuudelle.
Käyttäjätaso 3
rlame kirjoitti:

Netin selaaminen ei ole niin pingistä riippuvaista ja kaikki alle 500ms riittää sangen sujuvaan netin selaamiseen.

Olen tästä kyllä eri mieltä. Nettisivut koostuvat sadoistakin komponenteista jotka ladataan erikseen ja usein eri palvelimiltakin jos sivustolla on upotettua sisältöä. Vaikka selaimet pystyvät tekemään useampia latauspyyntöjä yhtäaikaa, niitä ei tehdä kovin montaa kerrallaan(omassa Firefoxissa luku on 8 ) joten jonoa syntyy pakostakin ja viiveet rupeaa kertaantumaan. Tämä on yksi syy miksi Operan sivuston pakkaaminen(offroad mode) on niin hyvä heikoilla yhteyksillä ja korkeilla latensseilla.
Käyttäjätaso 2
status_rrd_graph_img.php.png
Käyttäjätaso 6
Tulevana torstaina ajetaan parametri muutoksia verkkoon. LTE-verkon pingit pitäisi tämän jälkeen tippua. Eli jos testailette perjantaina ja raportoitte tarvittaessa tänne jos ei ala näyttämään paremmalta 🙂
Käyttäjätaso 6
No tottakai 🙂
Käyttäjätaso 7
Jaksuu kirjoitti:
Tulevana torstaina ajetaan parametri muutoksia verkkoon. LTE-verkon pingit pitäisi tämän jälkeen tippua. Eli jos testailette perjantaina ja raportoitte tarvittaessa tänne jos ei ala näyttämään paremmalta :)

Tänään näyttää tällaiselta LTE1800-verkossa 50M-liittymällä. Kiitos!

Selvää parannusta näyttäisi tapahtuneen ja nyt 4G yhteyden viiveet näyttävät paremmilta kuin 3G:n. Viiveen vaihtelua näyttäisi edelleen olevan melko paljon, mutta ainakaan itseäni tuo ei haittaa:

~$ ping -c10 ftp.funet.fi
PING ftp.funet.fi (193.166.3.2) 56(84) bytes of data.
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=1 ttl=247 time=28.9 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=2 ttl=247 time=40.1 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=3 ttl=247 time=39.0 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=4 ttl=247 time=37.8 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=5 ttl=247 time=25.0 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=6 ttl=247 time=34.8 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=7 ttl=247 time=26.0 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=8 ttl=247 time=52.0 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=9 ttl=247 time=50.9 ms
64 bytes from ftp.funet.fi (193.166.3.2): icmp_seq=10 ttl=247 time=26.0 ms

--- ftp.funet.fi ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 25.052/36.078/52.009/9.379 ms

Toinen huomionarvoinen seikka on se, että nykyisin Googlen DNS palvelin vastaa pingiin yhtä nopeasti kuin Funetin palvelin. Aikaisemmin näissä oli iso ero Funetin hyväksi. Nyt tilanne on toisin päin:

~$ ping -c10 8.8.8.8
PING 8.8.8.8 (8.8.8.8 ) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=29.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=29.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=29.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=29.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=30.0 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=30.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=54 time=49.2 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=54 time=48.0 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=54 time=30.9 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=54 time=45.8 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
rtt min/avg/max/mdev = 29.725/35.375/49.288/8.129 ms
Pikaisen testauksen perusteella vaikuttaa paljon paremmalta. Ovatko >100ms piikit nyt historiaa?

Saunalahti.fi

Ping statistics for 195.197.95.187:
Packets: Sent = 58, Received = 58, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 42ms, Average = 30ms

Google DNS

Ping statistics for 8.8.8.8:
Packets: Sent = 36, Received = 36, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 35ms, Maximum = 46ms, Average = 36ms
Käyttäjätaso 2
Näyttäisi parannusta tulleen, pingit pyörii lumialla nopeimmillaan siinä 40-50 (välillä edelleen sitkeätä 629 tms ulaani pingiä)haarukassa missä ennen verkkomunausta, samoin dl nopeus noussut entiselle 20-25m tasolle, tippui marraskuussa 7-9megaan.. Uploadhan pysyi ainakin meillä ennallaan myös verkkomunauksen aikana. Toivotaan että pysyisi edes näin jonkin aikaa.
Käyttäjätaso 1
10ms parani täällä ping 800mhz verkossa.
Käyttäjätaso 7
Kunniamerkki +3
Minulla parani 60ms -> 30ms.
Käyttäjätaso 7
Olisikohan Elisa ihan oikeasti tehnyt jotakin , kun tänäänkin viiveet on ihan kunnolliset.

LTE 1800 50M-liittymällä.



Ei paha.  😉
Käyttäjätaso 6
Kunniamerkki +1
Täälläkin usealla laitteella kokeiltuna parin päivän ajan 50ms> 20ms.
Nopeudet ja pingit palanneet entiselleen Kiuruvedenkin suunnilla:

Share Image

Loppu hyvin,mutta...Viasta ei tiedotettu millään tavalla.Tein vikailmoituksen noin kuukauden kuluttua kun yhteys heikkeni,vastaus oli:"Kaikki on kunnossa,hommaa ulkoinen antenni".Sitten selviääkin että kaikki oli johtunut "parametrimuutoksista".
Käyttäjätaso 7
Kunniamerkki
Niinpä.

Vasteajat näyttävät palautuneen entiselle tasolleen 25-30 ms väliin, ja hyvä niin.

Jää tästä koko hommelista pari hämmentävää seikkaa päällimmäiseksi mieleen. 

Koska ongelma ilmeisesti alkoi jostakin verkon päivityksestä, niin eikö todellakaan operaattorilla/laitetoimittajalla/whoever ollut selvillä, mitä verkolle ko. päivityksessä oikein tapahtuu? Ja missä vaiheessa operaattori itse huomasi ongelman? Kommentteja ei ainakaan Palstalla näkynyt, ja muutamille valittajille "besserwisserit" tarjosivat heti auliisti ongelmanratkaisuksi laitteiden/asetusten yms. tutkimista.

Toinen hämmennys liittyy "omaan" LTE1800-tukiasemaan ja sen vasteaikoihin. Ko. tukari tuli käyttöön reilut kaksi vuotta sitten, ja koko tänä aikana sen vasteajat ovat olleet lähes samaa luokkaa kuin nyt vikatilanteen aikana tai jopa huonommat. Moden ansiokkaalla avustuksella tehty vikailmoitus korjasi jossakin vaiheessa vasteet 80 ms -> 40 ms, mutta toimivuus ei siitä juuri kummennut. Hämmentävintä tässä on se, että tuokin tukiasema korjautui nyt sille tasolle, jolla samassa käyttöpaikassa saatavilla oleva toinen LTE1800-tukari ja pari LTE800-tukaria toimivat ennen tätä sekoilua eli jo em. n. 25 ms kieppeille. Tästä jää leijumaan kysymys, voiko jokin yksittäinen tukiasema toimia sillä tavalla virheellisesti, että tuollainen ilmeisesti aika laaja-alainen verkon fiksaus korjaa senkin?
Käyttäjätaso 6
KoTe60 kirjoitti:

Niinpä.

Vasteajat näyttävät palautuneen entiselle tasolleen 25-30 ms väliin, ja hyvä niin.

Jää tästä koko hommelista pari hämmentävää seikkaa päällimmäiseksi mieleen. 

Koska ongelma ilmeisesti alkoi jostakin verkon päivityksestä, niin eikö todellakaan operaattorilla/laitetoimittajalla/whoever ollut selvillä, mitä verkolle ko. päivityksessä oikein tapahtuu? Ja missä vaiheessa operaattori itse huomasi ongelman? Kommentteja ei ainakaan Palstalla näkynyt, ja muutamille valittajille "besserwisserit" tarjosivat heti auliisti ongelmanratkaisuksi laitteiden/asetusten yms. tutkimista.

Toinen hämmennys liittyy "omaan" LTE1800-tukiasemaan ja sen vasteaikoihin. Ko. tukari tuli käyttöön reilut kaksi vuotta sitten, ja koko tänä aikana sen vasteajat ovat olleet lähes samaa luokkaa kuin nyt vikatilanteen aikana tai jopa huonommat. Moden ansiokkaalla avustuksella tehty vikailmoitus korjasi jossakin vaiheessa vasteet 80 ms -> 40 ms, mutta toimivuus ei siitä juuri kummennut. Hämmentävintä tässä on se, että tuokin tukiasema korjautui nyt sille tasolle, jolla samassa käyttöpaikassa saatavilla oleva toinen LTE1800-tukari ja pari LTE800-tukaria toimivat ennen tätä sekoilua eli jo em. n. 25 ms kieppeille. Tästä jää leijumaan kysymys, voiko jokin yksittäinen tukiasema toimia sillä tavalla virheellisesti, että tuollainen ilmeisesti aika laaja-alainen verkon fiksaus korjaa senkin?


Olen varmasti väärä ihminen vastaamaan tähän, mutta tukiasemissa pyörivät eri softat ja laitteistot. On Nokialaista, Ericssonia jne. Varmasti jokin tukiasema saattaa käyttyätyä erilailla tietyn päivityksen jälkeen, kuin sitten toinen toimii taas paljon paremmin. Tässä kohtaa jos sellainen huomataan, niin pitäisi tietenkin tehdä jonkinlaista rollbackia. En tiedä onko tämä kuinka hankala sitten toteuttaa, saatikka sitten paikantaa.

Mukava kuitenkin kuulla, että pingit ovat kaikilla laskeneet tähän mennessä 🙂
Käyttäjätaso 4
Liikennevaloissa, 2 pykälää signaaleja

iphone6

D8EFD789-7795-40BB-ACD0-996EBA362B26.PNG
Pidempään pingailtuna näkyy vieläkin olevan noita isompia piikkejä (>100ms). Taitaa tähän aikaan joutua linjat lujille....

Saunalahti.fi pingattuna.

Ping statistics for 195.197.95.187:
Packets: Sent = 155, Received = 155, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 185ms, Average = 35ms

Osallistu keskusteluun