[ Branimir Maksimovic @ 04.04.2020. 21:26 ] @
Moj do 8.8.8.8:
Code:

100 packets transmitted, 99 received, 1% packet loss, time 99394ms
rtt min/avg/max/mdev = 30.570/882.072/1194.030/321.688 ms, pipe 2

I tako veci deo dana...
Ovakav ping nije bio ni kad sam bio na dial up-u ;)
[ calexx @ 04.04.2020. 21:45 ] @
Sad izmerio:
Code:
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=56 time=10.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=10.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=10.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=10.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=11.2 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 10.755/10.934/11.242/0.167 ms
Da merim 100 komata?
[ Branimir Maksimovic @ 04.04.2020. 21:48 ] @
Jok, ti nemas puno usera na cvoristu. Savrsen si.
[ bojan_bozovic @ 04.04.2020. 21:49 ] @
Code:
bojan@debian:~$ ping 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=55 time=16.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=15.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=16.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=16.9 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=15.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=16.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=17.5 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=15.8 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=16.3 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=55 time=16.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=55 time=16.7 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=55 time=17.0 ms
^C
--- 8.8.8.8 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 28ms
rtt min/avg/max/mdev = 15.249/16.389/17.462/0.613 ms
[ Miroslav Cvejić @ 04.04.2020. 21:55 ] @
Sa laptopa (WiFi)


Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=8ms TTL=57
Reply from 8.8.8.8: bytes=32 time=8ms TTL=57
Reply from 8.8.8.8: bytes=32 time=8ms TTL=57
Reply from 8.8.8.8: bytes=32 time=8ms TTL=57

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms



Sa rutera


PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=58 time=7.763 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=7.625 ms
64 bytes from 8.8.8.8: seq=2 ttl=58 time=7.690 ms
64 bytes from 8.8.8.8: seq=3 ttl=58 time=7.639 ms
64 bytes from 8.8.8.8: seq=4 ttl=58 time=7.829 ms
64 bytes from 8.8.8.8: seq=5 ttl=58 time=7.597 ms
64 bytes from 8.8.8.8: seq=6 ttl=58 time=7.643 ms
64 bytes from 8.8.8.8: seq=7 ttl=58 time=7.597 ms
64 bytes from 8.8.8.8: seq=8 ttl=58 time=7.739 ms
64 bytes from 8.8.8.8: seq=9 ttl=58 time=7.591 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 7.591/7.671/7.829 ms
[ calexx @ 04.04.2020. 21:57 ] @
Citat:
Branimir Maksimovic:Savrsen si.
Znam. ;)
[ Branimir Maksimovic @ 04.04.2020. 22:07 ] @
Hm, posle reseta modema, ping se unormalio, sad sam pustio -c 1000, da vidim
kako ce se ponasati. U svakom slucaju resetujem modem u dva dana, ovakvo
ponasanje nisam video ni posle mesec dana kad ne resetujem modem....
[ Branimir Maksimovic @ 04.04.2020. 22:26 ] @
Evo ga sad nakon restarta *modema* ne rutera...
Code:

--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000187ms
rtt min/avg/max/mdev = 9.293/13.363/44.689/4.542 ms

znaci sad moram da restartujem na pola dana...
[ Milan Kragujevic @ 04.04.2020. 22:52 ] @
Da, jer je Cisco. Pisao sam na Bench forumu o tome pa su me banovali i sve postove mi retroaktivno obrisali. Enivej:



Ovo je bio moj problem na Vektoru na Ledinama. EPC3925 je krš i tu nema pomoći, ni Bridge mode ne pomaže.

"Učini mi" (zapravo sebi, ali da proverim nešto prvo) "uslugu" i testiraj ping ka 192.168.100.1*, baš kao i ka 8.8.8.8, posebno kad su takvi problemi koje sada imaš, i okači ovde.

* DOCSIS gateway fiksna IP adresa koju svaki modem ima, bez obzira na LAN IP adresu
[ Milan Kragujevic @ 04.04.2020. 22:58 ] @
Eh, da, ping:

Code:

--- 8.8.8.8 ping statistics ---
45 packets transmitted, 45 received, 0% packet loss, time 115ms
rtt min/avg/max/mdev = 5.433/5.846/6.124/0.252 ms
[ Branimir Maksimovic @ 04.04.2020. 22:58 ] @
"DOCSIS gateway fiksna IP adresa"

Znam, na tu se javlja u bridge modu.

"EPC3925 je krš i tu nema pomoći, ni Bridge mode ne pomaže."

Da, al ranije mu je trebalo mesec dana da se zaglupi, ne znam
sta je ovo?
[ Milan Kragujevic @ 04.04.2020. 23:07 ] @
'Jel se greje? Više nego ranije?

Also, imam neku nedokazanu hipotezu da se modem preoptereti jer ima previše "šuma" tj. RF smetnji i uopšte saobraćaja na kablu, tj. DOCSIS mreži, i da zbog toga mora mnogo više grešaka da koriguje nego inače.

Brzina može da ne padne, može i da padne, ne znam, nije bitno, ali se greške povećaju, i to najčešće one koje se mogu korigovati, tj. bit-flip u data polju. E, sad, moguće da se tu javlja problem da modem izgubi sinhronizaciju
sa timing parametrima CMTS-a, i onda to krene da mu pravi sve veće probleme, jer sve živo mora da retransmituje više puta, nevezano za greške, jer promaši TDMA interval. To se rešava jednostavnom rekonfiguracijom veze,
tj. renegotiation and DOCSIS ranging, a to se može desiti samo ako se modem otkači sa mreže i ponovo počne da skenira dostupne frekvencije i da dogovara sinhronizacioni interval sa CMTS-om.

To možeš da proveriš tako što ćeš modem ostaviti uključenim, i izazvati rekonfiguraciju putem web interfejsa. Ne sećam se da li Cisco to ima, znam da SBB-ov CGA ima mogućnost da ponovo skeniraš frekvencije, i onda on sve to
uradi iznova, a ne restartuje se (SBB inače kaže da je to zabranjeno korisnicima LOL).

Ako ne, rizičnija opcija je da mu, dok je uključen, skineš Coax kabl, i ponovo priključiš, a za to vreme konstantno ping-uješ 192.168.100.1 i 8.8.8.8, da vidiš da li će da se poboljša ping ka 8.8.8.8 a da ne bude restart-a (što ćeš videti
tako što će 192.168.100.1 ping pući, dok se on upali ponovo).

Ako je to problem, onda je verovatno do mreže provajdera tj. do "njih", i to se ne može lako rešiti *. Ako ne bude bolje, a bude bolje restartom, onda je do modema, što se
da vrlo lako rešiti, tako što ti oni besplatno zamene modem. Načuo sam da Supernova daje sada nove modele, ne samo EPC3925, od kako su uveli novi paket Super max.

* - Ne može se rešiti lako jer to znači da je preopterećen CMTS, dakle ili da urade node split, tj. da pola korisnika presele na novi CMTS, ili da ugase uslugu nekom procentu korisnika. Ne može se preopterećenje na kablu rešiti
na drugi način, posebno ne u kratkom roku. Eventualno ako je neko spojio stari TV na mrežu pa probija napon, ili negde oštećen coax ide preblizu strujne instalacije, to bi mogli da reše brzo ranije, sada ne mogu da ljudima ulaze
tek tako da proveravaju da li imaju nesertifikovanu opremu koja pravi smetnje.
[ Branimir Maksimovic @ 04.04.2020. 23:19 ] @
Ne greje se vise, nije se grejao ni ranije.
Imam neki utisak da to ima veze vise sa provajderom nego sa mnom, ali:

gledaj:

Code:

Upstream Channels            
        
        
      Power Level:
Channel 1:     46.5 dBmV
Channel 2:     49.2 dBmV
Channel 3:     0.0 dBmV
Channel 4:     0.0 dBmV


Od kako je pocelo ovo sa koronom imam taj jako visok nivo za upstream,
normalno je bilo od 32-36.
[ Milan Kragujevic @ 04.04.2020. 23:41 ] @
To su užasne vrednosti. Maksimum power level je 53 dBmV, tj. 113 dBuV. *

Ti imaš** 109.2 dBuV, za stari modem od pre 10 godina je to možda i preteško, pa zato imaš probleme.
Svakako, mreža je loša, možda niko pre nije koristio net na tvom CMTS-u pa ti je tako dobro radilo. A možda je crklo nešto a oni ne mogu da poprave, pa ti loše radi.

Svakako, UŽAS, mada se provajderi (i Super-operateri i SBB) "pravdaju" da može od 35 dBmV do 55 dBmV. Može, OK, ali to ne znači da treba tako.

Also, ovde [https://pickmymodem.com/signal-levels-docsis-3-03-1-cable-modem/] piše:

Citat:
*Recommended Upstream signal levels are +35 dBmV to +49 dBmV (DOCSIS 3.0)


... stoga, nije mi jasno da li je 53 dBmV ili 49 dBmV, ako je ovo drugo, onda ti je modem out of spec, pozovi ih da ti resetuju uređaj i rekonfigurišu kanale, samo od sebe se neće rešiti. Ili promeni upstream start frequency na neku drugu vrednost pa probaj ponovo, možda bude bolji signal na novim kanalima. I stvarno treba da aktiviraju svim korisnicima 4 kanala, a ne 2, a na Vektoru lepo 1 kanal i više "ne može".

* izvor: https://www.normann-engineerin...925%208x4%20EuroDOCSIS%203.pdf (strana 8, Maximum Operating Level, SCDMA 64QAM)
** konverzija za 75 Ohm RG6 coax, dBµV = 60 + dBmV
[ Zlatni_bg @ 05.04.2020. 01:35 ] @
Zabada i SBB redovno poslednjih dana. Nekad pukne skroz konekcija, nekad je do rutera, nekad je do njih. Bice da nam baguje FW na ruteru pre toga Bane.

Inace, s obzirom na to da su svi kod kuce i uglavnom drndaju neki smart uredjaj, ocekujte da je ping katastrofa i tako i tako. Pogotovu kako su svi povecali brzine neta, pitanje da li njihovi uredjaji mogu da se nose sa peak-om data transfera.

S obzirom na trenutnu situaciju u svetu nista cudno.

Code:


--- 8.8.8.8 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99174ms
rtt min/avg/max/mdev = 11.879/14.980/26.048/2.920 ms
[root@centos7 ~]#

[ Branimir Maksimovic @ 05.04.2020. 02:46 ] @
Tebi su signali savrseni. Kod mene nije tako sjajno. No gledam da ulovim moment kada pocne da baguje, jer se mislim i ja, radi se o bagu u FW.
[ Zlatni_bg @ 05.04.2020. 06:28 ] @
Signal je po parametrima sjajan, ali posto su svi kod kuce poslednjih dana, cesto kad se probudim cujem "e nesto ne radi internet". Par puta se desavalo da sam morao da resetujem ruter, jednom reset rutera nije pomogao, pomogao je reset modema preko mojsbb portala. Ping sam primetio da je nestabilan, isto tako i protok, ako ti nesto znaci. Kapiram da su svi prezasiceni ovim "optika paketima" koje su dali svima i sad svi bleje kuci i cepaju torrente... nema teoretske sanse MTS/SBB/Bilo-ko da pruzi 1GBPS vise od par hiljada korisnika a da to radi stabilno sa zahtevima ka i od njihove mreze. Dok ne prodje ova situacija necu obracati paznju na ping uopste, isto tako, nemam koenzistentnu brzinu, varira izmedju 70 i 150, imam 150 na papiru.

Sve je u q, tako je i net verovatno, jedino sto ostaje je da se ceka. Kapiram da bar jedna kuca/stan ima nekoga ko strimuje nesto sa yt/netflixa/itd, gotovo 24/7. Nekad i vise ukucana. Opterecen je ceo net.

Ti parametri ti mozda nisu u redu ali imaj u vidu da mi mislimo da znamo kakvi treba da budu. Ko zna sta su ti podesavali pa je tako. Meni su jednom prepolovili snagu signala jer ... pitaj Boga sta su kome u zgradu radili i skapirali da to tako treba kod njega kuci, pa dok sledeci stanar ne pozove.

Ako hoces iscimaj ih, mogu oni te parametre daljinski da iscitaju, ali mislim da mora na terenu da se izmeni. Prati situaciju, vidi da izolujes problem. Meni je samo to pomagalo.
[ Branimir Maksimovic @ 05.04.2020. 07:03 ] @
Evo od sinoc ping stabilan i dobar. Znaci do modema je. Mozda se desi neki bag zbog povecanog opterecenja ko ce ga znati.
Praticu situaciju pa javim.
[ Milan86 @ 05.04.2020. 13:01 ] @
VDSL 100/10:

[ tox master @ 05.04.2020. 13:10 ] @
Lako je vama kad imate "brzine", ja u BIH imam 22mbit paket a navece od 19-23 pada u momentima cak i na 2 mbit
Morao sam klincima da smanjim rezoluciju youtube na 480p da i meni nesto ostane od tog jadnog protoka.
Inace mi je protok i pre padao dosta i zalio sam se i kao nesto su pokrenuli da se kapacitet prosiri posto su nabacali korisnika a mreza stara 10 godina koju nisu poboljsavali.
Sada kada sam nazvao jedva su docekali da me skinu sa dnevnog reda sa izgovorom korone , kao samo se rjesavaju hitne situacije to jest kad ne radi nikako nekome mada se i ovo moze skoro tako okarakterisati.
A ping nesto nisam primetio da je veci osim sto nekad ima poneki izgubljen paket a inace je do googla 40-50ms.
Ne kapiram kako vi svi imate tako male pingove,ja gde god sam testirao kod nas nisam video manje od 40ms, recimo mtel adsl.
[ bojan_bozovic @ 05.04.2020. 13:17 ] @
Ja imam 75Mbit/s SBB kabl. Zato je ping tako nizak internet je dobar, a ljudi sa nizim pingom verovatno imaju jos brzi i bolji internet.
[ Milan Kragujevic @ 05.04.2020. 13:24 ] @


Telekom VDSL2, 20/2 Mbps, 1.3km od centrale, ping 10ms ka 8.8.8.8
(bez interleaving-a je, naravno)
[ Goran Mijailovic @ 05.04.2020. 13:34 ] @
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=76ms TTL=54
Reply from 8.8.8.8: bytes=32 time=48ms TTL=54
Reply from 8.8.8.8: bytes=32 time=100ms TTL=54
Reply from 8.8.8.8: bytes=32 time=51ms TTL=54

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 48ms, Maximum = 100ms, Average = 68ms
[ Branimir Maksimovic @ 05.04.2020. 18:32 ] @
Evo ga pocelo je opet sa losim pingom i naravno nakon restarta opet savrsen ping.
Potrajalo je citavih 5-6 sati pre nego sto se ping pokvario.
[ Milan Kragujevic @ 05.04.2020. 18:43 ] @
Loš ping i ka 192.168.100.1? Ako nisi proveravao, molim te proveri.

I zovi ih već jednom da ti zamene crkotinu EPC3925, bar je to najlakše da se uradi.

VERUJTE MI, Cisco 8x4 modemi ne mogu da se mere sa 24x8 modelima, a Supernova je konačno počela da korisnicima nudi nešto bolje od prevaziđene tehnologije.

Kad sam na SBB-u imao Cisco EPC3208 (8x4 3.0 konfiguracija), stalno su bili problemi i raspadala se veza, itd. Takvih problema nema na CGA2121. Do kanala je!

Ne može 8x4 da radi bolje ili isto kao 24x8, ma šta god neko tvrdio i koliko magle prodao dnevo.
[ Branimir Maksimovic @ 05.04.2020. 18:45 ] @
"Loš ping i ka 192.168.100.1? Ako nisi proveravao, molim te proveri. "

U sledecoj turi, vec sam ga restartovao. Sad je dobar.

"a Supernova je konačno počela da korisnicima nudi nešto bolje od prevaziđene tehnologije."

Heh, zadovoljan sam ovim sada, samo je ranije tako umeo da zaglupi jednom mesecno
a sada izgleda dvaput dnevno...
[ Milan Kragujevic @ 05.04.2020. 19:06 ] @
>U sledecoj turi,
Ajde molim te, znaćemo onda da li je modem ili ne. Možda nije modem nego je mreža zagušena, i mora da se ponovo izvrši sinhronizacija, tj. odredi timing, vremenski slotovi i frekvencije.

>zadovoljan sam ovim sada
Da si zadovoljan ne bi nas pitao kakav nam je ping ;)
[ Branimir Maksimovic @ 05.04.2020. 19:18 ] @
"Da si zadovoljan ne bi nas pitao kakav nam je ping ;) "

Mislio sam da je do toga sto sad svi sede kucama :P
Mislim da jeste, ali ovo sa modemom je ispala kao dodatna prica...
[ tox master @ 05.04.2020. 19:34 ] @
Ne znam sta se desava kod mene ali trenutno mi ide citavih 10mbit a to nisam video u ovo doba dana vec dugo vremena.
Moram da proverim da nije neka pobuna na ulicama pa niko ne drnda po youtube
I ja eto imam 3925 ali mi nikad nije bagovao,doduse u bridz modu je ali koliko vidim sta se pise zna i tako da zeza.
Mislim da sam pre par godina imao bas 3208 a on je nakon pustanja torenta nekih 20 minuta restartovao totalno pa kad dodje sebi opet radi 15-20 minuta i tako ukrug.
Tada su mi tehnicari provajdera ponudili bas zanimljivo resenje....da ne koristim torente
[ Milan Kragujevic @ 05.04.2020. 19:47 ] @
Nije 3925 niti 3208 faličan kao model, već konkretan uređaj. Korisnici Supernove su na drugim forumima opisivali svoja iskustva sa menjanjem modema, konkretno posle 5-6 modema promenjenih (svi EPC3925) konačno radi dobro, barem neko vreme.

3925 koji sam ja kod Vektora imao je star 9 godina. Ne kao model, već fizički na uređaju piše Mfg. date: 09/2011, tako nešto. Firmware iz 2012.

Sve modeme su uzimali "na kilo" kod Optiwella, i to su "reparirani" uređaji sa Holandskog kablovskog provajdera Ziggo.
Znam jer je SSID mreže bio Ziggo_ABCD (gde je ABCD poslednje 4 hex cifre MAC adrese CM interfejsa).

Uopšte mi nije jasno zašto kablovski operateri insistiraju na toj praistorijskoj 100 puta recikliranoj opremi, kad su im mreže već krš i kad ne može na 8 kanala da radi brzina po paketu.
Kako Telekom Srbija (ili Orion Telekom) može da daje novim korisnicima nove ADSL/VDSL modeme ili ONT-ove? A Supernova i svi ostali provajderi (do skoro SBB, sada na EON paketima daju CGA ili Ubee) daju te kršine od pre 10 godina?

Terminalna oprema je najbitnija stvar, ako je modem krš i usluga će biti krš.

Ako baš nemaju para da kupe kvalitetne modeme, zašto ne omoguće korisnicima da registruju svoje modeme koje sami kupe? Nego forsiraju svakoga da koristi njihove krševe jer eto "tako mora".

Svi EuroDOCSIS uređaji su sertifikovani i mogu raditi na svim kvalifikovanim CMTS-ovima svih proizvođača, nema tu interoperability problema, i skoro svuda u svetu korisnik može da koristi svoju terminalnu opremu osim u par "velikih" zemalja kao što je Srbija.
[ Zlatni_bg @ 06.04.2020. 07:28 ] @
I ja sam nocas ponovo morao reset i rutera i modema... ping je ubijao, igrao clash royale na telefonu i cekam par sekundi da padne karta... u prevodu, nisam imao zivaca da ga merim ali je bio par stotina ms sigurno. Kad se ponovi pogledacu i ja da li je open asuswrt ili je do modema. Izgleda smo nabavili eksperimentalni ruter kako stvari stoje :)
[ Milan Kragujevic @ 06.04.2020. 07:54 ] @
Evo mene nepozvanog, sa drugim problemom:

Čuveni MikroTik hAP ac2, o kome sam već pisao, ima novi problem: Zakuca se posle par sati rada i mora restart. Ne može se ući preko IP adrese na winbox ili web UI (tj. može, ali pukne konekcija), a preko MAC adrese radi. Ništa čudno nema ni u Log-u niti je status rutera nešto pogrešan. Spustio sam mu transmit power za WiFi sinoć, da se ne greje, međutim isto je, jutros sam ustao i nema "neta". Ne može se ući ni do modema na web UI ni do Tik-a.

Sada kad sam ga restartovao radio OK neko vreme (~10 min), i sad vidim da kad odem na neki sajt, fale neki iframe-ovi, a ping ka modemu bude <1ms, i par puta Timeout.

Ima li MikroTik neku cable diagnostics opciju, da mi ispiše broj RX/TX grešaka na kablu, možda je zbog toga? WinBox udp radi, preko MAC adrese, i to brzo -- sve odmah otvara, ali TCP preko IP adrese koči i puca, i sve ostalo se raspada vrlo brzo.

Počeo je pre 2 dana to da se dešava, jedino šta sam tad uradio je da sam ubacio još uređaja u mreži direktno na Tik, tj. u drugoj kući sam skinuo ruter i stavio AP i switch.
[ ineve74 @ 06.04.2020. 08:24 ] @

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 12ms, Average = 12ms

[ Zlatni_bg @ 06.04.2020. 13:29 ] @
Ljudi, dokle god budete kacili ping test od 4 rezultata sa po sekund razlike, apsolutno nimalo necete doprineti svojim rezultatima :D
[ ineve74 @ 06.04.2020. 13:59 ] @
Eno onom Goran Mijailovic laguje sa 4 pinga.
Ja kad sam bio na telekomu sa iptv-om imo sam za 30 manji ping sa USA.
Ladno west coast 140 ping a east 90
[ Milan Kragujevic @ 06.04.2020. 14:34 ] @
Code:
[admin@MikroTik] > ping 8.8.8.8

Code:
sent=1560 received=1560 packet-loss=0% min-rtt=10ms avg-rtt=10ms max-rtt=41ms
[ bojan_bozovic @ 06.04.2020. 15:05 ] @
bojan@debian:~$ ping -c 1000 8.8.8.8


--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1154ms
rtt min/avg/max/mdev = 13.839/17.087/50.124/2.068 ms
[ Branimir Maksimovic @ 06.04.2020. 16:41 ] @
Citat:
Zlatni_bg:
I ja sam nocas ponovo morao reset i rutera i modema... ping je ubijao, igrao clash royale na telefonu i cekam par sekundi da padne karta... u prevodu, nisam imao zivaca da ga merim ali je bio par stotina ms sigurno. Kad se ponovi pogledacu i ja da li je open asuswrt ili je do modema. Izgleda smo nabavili eksperimentalni ruter kako stvari stoje :)


Asus je odlican, ne zalim se. Od novog firmware-a oce da zabaguje 5Ghz mreza pa mora da se restartuje.
[ calexx @ 06.04.2020. 17:08 ] @
Citat:
Zlatni_bg:Ljudi, dokle god budete kacili ping test od 4 rezultata sa po sekund razlike, apsolutno nimalo necete doprineti svojim rezultatima :D
Pa ako radimo 1000 rezultata, potrošićemo skoro 17 minuta. ;) Kako ti odgovara pa da opet uradim test?
[ Branimir Maksimovic @ 06.04.2020. 17:20 ] @
Pa neces da cekas 17 minuta, danas su OS-ovi multitasking :P
[ calexx @ 06.04.2020. 17:29 ] @
Moram da čekam 17 minuta da bih imao rezultat. ;)
Code:
--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 1000279ms
rtt min/avg/max/mdev = 9.836/10.450/13.372/0.138 ms
Moj rezultat sa 5 merenja, kakva je razlika??
Code:
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 10.755/10.934/11.242/0.167 ms

[ Branimir Maksimovic @ 06.04.2020. 17:30 ] @
A cuj tebi jitter ko sa lokalnim ruterom :P
Tebi nema problema, ali nije kod svih tako. Moze da se desi
da ima spajkova a to ne mozes otkriti samo sa 5 pingova :P
[ Branimir Maksimovic @ 06.04.2020. 17:34 ] @
Nego evo za Milana, upravo je prolupao modem:
Code:

~ >>> ping -c 10 192.168.100.1                                                                                                                                                                           
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=0.690 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.615 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=63 time=0.678 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=63 time=0.647 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=63 time=0.650 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=63 time=0.665 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=63 time=0.686 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=63 time=0.566 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=63 time=0.693 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=63 time=0.698 ms

--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9130ms
rtt min/avg/max/mdev = 0.566/0.658/0.698/0.039 ms
~ >>> ping -c 10 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=57 time=37.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=198 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=20.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=264 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=41.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=62.3 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=118 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=24.4 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=57 time=178 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 19.413/96.164/264.039/83.731 ms


Znaci do modema je dobar ping posle njega sad katastrofa,
necu da restartujem sad mozda Milan ima nekih ideja :P
[ Milan Kragujevic @ 06.04.2020. 18:03 ] @
Milan ima ideja:

Kontra mom dosadašnjem mišljenju i mržnji i predrasudama ka matorim modemima, modem je ispravan.

Problem je opterećenje na mreži i gubitak sinhronizacije što se rešava restartom i resinhronizacijom.
Možeš probati da isključiš coax i onda ponovo uključiš bez restarta modema, moguće da će da proradi net,
u tom slučaju je definitivno do mreže.

To su inače veoma loše vesti, jer to znači da problem izaziva isključivo preopterećenje i da će se rešiti
samo smanjenjem opterećenja ili smanjenjem broja korisnika na CMTS-u (dodavanjem još jednog CMTS-a
i realizacijom node split-a, gde se pola korisnika seli na drugi CMTS). A to neće skoro.

Nažalost, nema ti pomoći. Svakako ih zovi :)
[ SASA M. @ 06.04.2020. 18:08 ] @
http://ping-test.net/
[ Branimir Maksimovic @ 06.04.2020. 18:36 ] @
"To su inače veoma loše vesti, jer to znači da problem izaziva isključivo preopterećenje i da će se rešiti
samo smanjenjem opterećenja ili smanjenjem broja korisnika na CMTS-u (dodavanjem još jednog CMTS-a
i realizacijom node split-a, gde se pola korisnika seli na drugi CMTS). A to neće skoro. "

To su meni dobre vesti jer modem nije crkao :P
A ne bih da prelazim na ruter varijantu koja
mi pravi problem sa detektovanjem zatvaranja konekcija :P
Mislim program ceka i ceka da provali da je konekcija pukla
kad ga stavim da NAT-uje...
[ Milan Kragujevic @ 06.04.2020. 18:48 ] @
Pa da, ali će ti narednih par meseci net loše raditi i niko ti ne može pomoći. Bad news in my book.
[ Branimir Maksimovic @ 06.04.2020. 18:54 ] @
Ma net radi super, nije mi problem da restartujem modem jednom dnevno ;)
[ Branimir Maksimovic @ 06.04.2020. 21:11 ] @
Nego nek mi neko objasni ovo:

a gle :
Code:

~/projects/zfs >>> ping -c 10 yahoo.com                                                                                                                                                         ±[master]
PING yahoo.com (98.138.219.232) 56(84) bytes of data.
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=1 ttl=49 time=175 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=2 ttl=49 time=179 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=3 ttl=49 time=252 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=4 ttl=49 time=132 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=5 ttl=49 time=164 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=6 ttl=49 time=224 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=7 ttl=49 time=386 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=8 ttl=49 time=268 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=9 ttl=49 time=396 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=10 ttl=49 time=159 ms


Code:

~/projects/zfs >>> ping -c 10 rts.rs                                                                                                                                                            ±[master]
PING rts.rs (185.29.102.11) 56(84) bytes of data.
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=1 ttl=248 time=167 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=2 ttl=248 time=37.2 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=3 ttl=248 time=158 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=4 ttl=248 time=47.9 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=5 ttl=248 time=96.0 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=6 ttl=248 time=157 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=7 ttl=248 time=41.1 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=8 ttl=248 time=74.9 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=9 ttl=248 time=11.1 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=10 ttl=248 time=32.3 ms


To ko da moj isp ide ko kisa oko Kragujevca...
[ Branimir Maksimovic @ 07.04.2020. 05:47 ] @
A evo ga ping ka rts-u u 7 ujutro, nisam restartovao modem:

Code:

~/projects/zfs >>> ping -c 10 rts.rs                                                                                                                                                            ±[master]
PING rts.rs (185.29.102.11) 56(84) bytes of data.
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=1 ttl=248 time=4.69 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=2 ttl=248 time=4.87 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=3 ttl=248 time=5.15 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=4 ttl=248 time=6.06 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=5 ttl=248 time=11.1 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=6 ttl=248 time=4.72 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=7 ttl=248 time=5.02 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=8 ttl=248 time=10.8 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=9 ttl=248 time=4.44 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=10 ttl=248 time=5.03 ms

--- rts.rs ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 4.435/6.189/11.136/2.421 ms

[ Milan86 @ 07.04.2020. 08:05 ] @
Moj ping ka RTS-u:

[ bojan_bozovic @ 07.04.2020. 08:14 ] @
bojan@debian:~$ ping -c 10 rts.rs
PING rts.rs (185.29.102.11) 56(84) bytes of data.
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=1 ttl=245 time=10.4 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=2 ttl=245 time=11.2 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=3 ttl=245 time=10.7 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=4 ttl=245 time=11.0 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=5 ttl=245 time=10.1 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=6 ttl=245 time=12.8 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=7 ttl=245 time=11.4 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=8 ttl=245 time=9.44 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=9 ttl=245 time=9.92 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=10 ttl=245 time=10.9 ms

--- rts.rs ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 22ms
rtt min/avg/max/mdev = 9.440/10.771/12.751/0.881 ms
[ Zlatni_bg @ 07.04.2020. 16:43 ] @
Ako bez restarta ujutru kad svi spavaju ne pravi problem, ili imas srece pa se sam opravio, ili su vas naguzili 5x vise nego sto vas treba tu. E sad, da li je problem broj otvorenih konekcija, otvorenih portova, ukupna potrosnja bw-a svih vas na tom cmtsu ili ko zna gde, znas i sam da nikad neces saznati. Mozda pri restartu modema dobijes neki priority, eventualno zatvori neke konekcije, ko ce ga znati. Malo je konfuzno to sto reset modema pomogne. Probaj sledeci put samo ruter da resetujes. Ko zna koliko korisnika deli infrastrukturu i kakvi su im i switchevi.
[ Branimir Maksimovic @ 07.04.2020. 17:20 ] @
Da, izgleda da kada ponovo uradi scan dobije veci prioritet.
[ Milan Kragujevic @ 07.04.2020. 17:34 ] @
Zlatni_bg, problem je uvek što su "naguzili" više korisnika nego što bi smelo po svim "standardima" overselling-a usluge. Jedan CMTS na više ulica nema nigde osim kod nas i u Americi (oni su još gori po tom pitanju). Enivej, nije problem na nivou TCP/IP (broj konekcija, portova, itd.) već na nivou PHY, tj. DOCSIS -- jednostavno ima toliko saobraćaja da ne može proći kroz kabl sve odjednom i onda se čeka.

Svaki modem ima sinhronizaciju pri paljenju koja mu određuje kada se javlja CMTS-u za slanje podataka nazad (iz tog razloga je brzina OK a ping loš, kada "dođe na red" on dobije šta mu sleduje, ali se čeka na to).

Problem nastaje kada se tajmin interval izduži jer ima mnogo saobraćaja i mnogo modema, CMTS ne može da postigne da sve pošalje i produžava vreme, što degradira uslugu, u određenim slučajima do nivoa da se ne može ni održati veza jer intervali prelaze dužinu čekanja na sinhronizacioni reply.

Tada modem izugbi vezu, i restartuje se i bude OK. Branimiru se to ne dešava, već samo loše radi ping. Restartom se vraća na normalan timing neko vreme, dok ga CMTS ne otera ponovo na "slow" listu, ili jednostavno sama oprema izgubi "pojam o vremenu".

Nažalost, moje iskreno mišljenje je da oni to ne mogu sad odmah rešiti, jer to nije kvar, već posledica dizajna mreže i svesne odluke da se proda 50x-100x više korisnika nego što ima kapaciteta. To mogu da reše samo sa node split-om, a za to će im trebati nedelja-dve, i svakako neće sada to raditi.
[ Ivan Dimkovic @ 07.04.2020. 20:03 ] @
100x oversubscription je sasvim uobicajena stvar.

Ja kod kuce i ne pokusavm uvece vise da koristim zicni net (kablovski operator, bukvalno je SSH neupotrebljiv zbog cestih timeout-ova) vec koristim 4G mobilnu konekciju.

U principu niko nije racunao na ovakvu situaciju i vrlo verovatno nece ulagati u infrastrukturu zbog necega sto ce trajati nekoliko nedelja, mozda par meseci max.
[ Milan Kragujevic @ 07.04.2020. 20:15 ] @
Naravno.

DSL nema ovako dramatične padove brzine i probleme, jer telefonska parica nije deljeni medijum, a brzine su dovoljno male (~100 Mb/s max, često manje) da retko dolazi do zagušenja linka ka core mreži. Jedino šta može da pravi problem je crosstalk, međutim, to se može rešiti sa G.vectoring, koji Telekom Srbija primenuje kod VDSL korisnika u Beogradu koji nisu na reseller-u.

Meni 4G radi vrlo dobro u selu.

[ Ivan Dimkovic @ 07.04.2020. 22:59 ] @
Ma bakar je super, ako je operater ulozio kintu u postenu pristupnu opremu.

Vecina ljudi verovatno pojma nema kolika kolicina racunarskih resursa se potrosi samo na obradu signala kako bi komsija imao svojih 100-200 MBit/s preko parice dizajnirane za prenos glasa i eventualno koju desetinu kilobita podataka :-)
[ Milan Kragujevic @ 08.04.2020. 00:07 ] @
Operater jeste uložio kintu. Koliko god ja kritikovao Telekom Srbija, i koliko god oni stvarno bili nesposobni i nezainteresovani, to je generalno ograničeno na billing, marketing, sales i legal službe. Tehnika im te top notch i ako su [navodno] svi pobegli u inostranstvo...

Problem je što se G.vector ne može realizovati ako se na tom DSLAM-u nalazi makar jedan korisnik koji koristi usluge drugog provajdera sa tuđom terminalnom opremom kroz MPLS tunel. Ja sam u BG imao sreće da je na DSLAM-u od 150 portova bilo aktivno ukupno 5 komada, i svi kod Telekoma, pa su mogli bez problema da aktiviraju Vectoring.

Meni je svakako veliki šok, u pozitivnom smislu, da smo uspeli da dostignemo taj nivo razvoja DSL tehnologije da smo dobili preko 300 Mbps na FTTB odnosno malim dužinama local loop (<50m), i 100 Mbps na dužinama do 100m, uz sav crosstalk koje UTP parice imaju kad su u snopu od 50+ komada i svi imaju xDSL uslugu. Da ne pričam o slabljenju na visokim frekvencijama i samoj problematici visokih frekvencija na 0.4mm paricama...

xDSL je jedina vrsta last mile pristupa koja nudi korisniku neverovatnu stabilnost (u slučaju da je sama parica kvalitetna i da je brzina konzervativno podešena).

Kablovski net je deljeni medijum sa malim kapacitetom, i to je još RF, pa smetnje nekog korisnika katastrofalno utiču na celokupnu mrežu.

Optički net je deljeni medijum, i ima mnogo prijava problema sa Orion infrastrukturom u manjim mestima i ako je FTTH da brzina opada na 10-20 Mbps ka njihovom serveru, jer nemaju dovoljno kapaciteta, o čemu sam ranije pisao (prodaju 1000 Mbps po korisniku, a ukupan "dovod" do sela je ~5 Gbps).
Optika ima prednost u tome što je pasivna mreža, i što nema potencijala za smetnje, već isključivo prekide kabla ili zagušenje usled prevelikog overselling-a, što se ne može reći za kablovsku, koja ima mnogo problema sa RF "šumom" i slabljenjem.

Mene je VDSL u Beogradu oduševio, iskren da budem. Evo parametara, ako nekoga interesuje (kabl je korodirao u zidu, zato su parametri lošiji nego što bi trebalo da budu):

(btw, brzina je 99999 Kbps a ne 102400 Kbps jer su mi u Telekomu rekli da nemaju profil za 100*1024 Kbps, već da oni to "zaokružuju" na 100*1000, a 2 Kbps pojede "neki frame". Ovo važi samo za profil 100/10 Mbps, manji paketi imaju tačan broj)
[ Milan Kragujevic @ 08.04.2020. 08:25 ] @
Od jutros lošije, po ličnom mišljenju katastrofa:

Code:

Ping statistics for 8.8.8.8:
    Packets: Sent = 88, Received = 87, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 209ms, Average = 49ms
[ DUSKEZ @ 08.04.2020. 11:51 ] @
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=36ms TTL=56
Reply from 8.8.8.8: bytes=32 time=28ms TTL=56
Reply from 8.8.8.8: bytes=32 time=37ms TTL=56
Reply from 8.8.8.8: bytes=32 time=27ms TTL=56

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 37ms, Average = 32ms

Pinging rts.rs [185.29.102.11] with 32 bytes of dat
Reply from 185.29.102.11: bytes=32 time=24ms TTL=24
Reply from 185.29.102.11: bytes=32 time=20ms TTL=24
Reply from 185.29.102.11: bytes=32 time=23ms TTL=24
Reply from 185.29.102.11: bytes=32 time=22ms TTL=24

Ping statistics for 185.29.102.11:
Packets: Sent = 4, Received = 4, Lost = 0 (0% l
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 24ms, Average = 22ms

kod moje dvice stvari stoje ovako

[ calexx @ 08.04.2020. 12:01 ] @
Mislim da nema svrhe meriti ping ili brzinu, naročito ne u vreme zabrane kretanja. Ne postoji provajder koji će da ima link za 100% kućnih korisnika i samo je pitanje kakav je komšiluk i koliko je provajder pilićar. Ono prvo više, drugo je relativno.
[ Milan Kragujevic @ 08.04.2020. 12:06 ] @
Ja baš mislim da ima puno svrhe to raditi sada. Da se "razotkrije" overselling kod neupućenih ljudi. Svima bi nam bolje bilo kada bi provajderi prodavali manje brzine koje se mogu održati nekome ko želi stabilnost, a veće a neodržive brzine onima kojima to seldom-treba. To postoji u vidu biznis paketa, ali je to preskupo jer postoje mnoge stavke/usluge koje ja npr. ne bih želeo da imam, ali bih morao. Drugo, biznis kablovski paketi nisu uopšte "biznis-level" usluga, samo je ugovor na pravno lice, sve ostalo isto, što sam video na primeru firme sa SBB netom kojima net radi lošije od mene i ako smo spojeni bili na isti CMTS tj. na istu banderu, jer je njima dodeljeno bilo 8 kanala i imali su loš SNR, donošenjem mog modema kod njih net bi se popravio jer je moj modem imao druge kanale, dakle instalacija im je bila OK. Pravi biznis-level servis je dark fiber i wholesale usluga astronomskih cena. Možda masovni triggering naroda povodom ovog karantina i overselling-a to promeni. A možda ne. Tehnologija za per-user QoS definitivno postoji, samo što to niko ne nudi kao uslugu...
[ Milan86 @ 08.04.2020. 20:31 ] @
Testovi kad je vece opterecenje...

Brzina:



Ping ka Google-ovom DNS-u:



Ping ka RTS-u:



VDSL 100/10
[ Zlatni_bg @ 09.04.2020. 16:01 ] @
Bane, izasao je ponovo novi FW za AC58U. Od pre jedno 10 apdejta su meni krenuli problemi. Nadam se da ce ih uskoro ispraviti. Instaliracu kasnije veceras kad svi legnu novi fw pa da vidimo da li ima promene...
[ Branimir Maksimovic @ 09.04.2020. 16:07 ] @
Da samo sto uopste ne dokumentuju koje izmene prave :P
[ Zlatni_bg @ 09.04.2020. 16:09 ] @
Pa, "System stability increased" vec 20x za redom, znaci da smo 20x stabilniji nego nekad, satro ;) bolje da nisu dirali posle nekog apdejta nista.

Btw, je l' entware mora ispocetka kad se apdejtuje? Samo kratak odgovor, da nas ne sankcionisu zbog offtopica, iako je prica o tvom (nasem) ruteru.
[ Branimir Maksimovic @ 09.04.2020. 16:18 ] @
Brateeee, od zadnjeg firmware-a koji sam stavio su izbacili jos 4 komada :P
Mislim, sad bukvalno svaki drugi mesec novi firmware:P
[ Branimir Maksimovic @ 11.04.2020. 17:14 ] @
Citat:
Zlatni_bg:
Pa, "System stability increased" vec 20x za redom, znaci da smo 20x stabilniji nego nekad, satro ;) bolje da nisu dirali posle nekog apdejta nista.

Btw, je l' entware mora ispocetka kad se apdejtuje? Samo kratak odgovor, da nas ne sankcionisu zbog offtopica, iako je prica o tvom (nasem) ruteru.


Zaboravih da ti odgovorim, apdejti ne diraju nista cak ni nvram varijable. Samo padejtujes i pici. Inace, nisam primetio
nikakvu vidljivu promenu nakon 4 firmware-a ;) Mozda su propravili bag sa 5GHz mrezom da se gubi?
[ Branimir Maksimovic @ 11.04.2020. 19:13 ] @
Hm, supernova se unormalila: gle sad

Code:

~ >>> ping -c 10 rts.rs                                                                                                                                                                                  
PING rts.rs (185.29.102.11) 56(84) bytes of data.
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=1 ttl=248 time=5.41 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=2 ttl=248 time=6.16 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=3 ttl=248 time=4.92 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=4 ttl=248 time=5.33 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=5 ttl=248 time=6.42 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=6 ttl=248 time=4.73 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=7 ttl=248 time=5.39 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=8 ttl=248 time=4.90 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=9 ttl=248 time=6.04 ms
64 bytes from 185.29.102.11 (185.29.102.11): icmp_seq=10 ttl=248 time=6.13 ms

--- rts.rs ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 4.725/5.543/6.419/0.573 ms
~ >>> ping -c 10 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=57 time=11.0 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=11.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=11.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=10.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=23.0 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=9.77 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=27.1 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=25.2 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=57 time=11.7 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 9.765/15.078/27.146/6.668 ms


Nista od onih pingova od sekunde ;)
[ Milan Kragujevic @ 11.04.2020. 19:27 ] @
Pogledaj jel promenjeni parametri signala i verzija modema, možda su poslali update, ili ti re-alocirali kanale za DOCSIS.
[ Branimir Maksimovic @ 11.04.2020. 20:00 ] @
Sve je identicno, isti FW, jacina signala i to.
[ Zlatni_bg @ 13.04.2020. 13:41 ] @
Code:

--- rts.rs ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99161ms
rtt min/avg/max/mdev = 6.813/9.066/13.843/1.418 ms
[root@centos7 ~]#


Ovako je sa SBBa preko kabla. Mada SBB nije poznat po dobrom pingu u SRB :)

Code:

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 11.822/13.116/15.242/0.937 ms
[root@centos7 ~]#


Google je okej, mada iskreno meni je ovo po jurenju svih mogucih problema najvise variralo od doba dana.

Jos nisam stavio novi apdejt, iskreno, ne vidim ni svrhu apdejtovanja vise... za sad mi radi okej mreza vec 5-6 dana.

Mozda da uzmemo u odredjeno doba dana da odradimo -c 1000 sa intervalima od 1s, pa da vidimo kako je kod tebe, kako je kod mene? Cron ili nesto? Da vidimo da li je do doba dana kod oba provajdera.
[ Branimir Maksimovic @ 13.04.2020. 17:15 ] @
"Mozda da uzmemo u odredjeno doba dana da odradimo -c 1000 sa intervalima od 1s, pa da vidimo kako je kod tebe, kako je kod mene?"

Evo sad je najgore vreme, pustam -c 1000.
[ Milan Kragujevic @ 13.04.2020. 17:45 ] @
Eh, da, Branimire, uradi tracert 1.1.1.1 npr., i onda ping next hop-a. Prvi hop nakon tvog rutera/modema (192.168.x.x) je CMTS node, pa ćeš tako proveriti da li je veza ka CMTS-u loša ili je veza CMTS-a sa core mrežom loša. Dalje od prvog hop-a ne možeš, jer modem ima rutu samo ka tom prvom nodu, i drugi nodovi imaju firewall koji ne dozvoljava pristup sa javnih IP adresa, a interna (CM-MTA) adresa ti je samo ka nodu CMTS-a. Proveri i taj ping paralelno.

PRIMER

Code:

C:\Users\Milan>tracert 1.1.1.1

Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  router.lan [192.168.0.1]
  2    <1 ms    <1 ms    <1 ms  mediarouter.home [192.168.10.1]
  3   228 ms   198 ms   211 ms  10.234.21.18
  4    27 ms    14 ms    14 ms  10.234.21.17
  5  ^C
C:\Users\Milan>


Dakle, u ovom slučaju bi radio ping ka 10.234.21.18, jer je to prvi node (doduše kod mene je LTE mreža trenutno).
[ Branimir Maksimovic @ 13.04.2020. 17:48 ] @
Evo traceroute:

Code:

~ >>> traceroute 1.1.1.1                                                                                                                                                                                 
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  router.asus.com (192.168.101.1)  0.357 ms  0.504 ms  0.305 ms
 2  10.175.31.254 (10.175.31.254)  4.890 ms  8.877 ms  4.774 ms
 3  87.250.37.133 (87.250.37.133)  4.930 ms  5.085 ms  5.129 ms
 4  212.200.23.65 (212.200.23.65)  10.366 ms  10.403 ms  10.268 ms
 5  212.200.7.64 (212.200.7.64)  5.544 ms  5.486 ms  10.172 ms
 6  212.200.5.32 (212.200.5.32)  18.766 ms  16.396 ms  16.377 ms
 7  vix.as13335.net (193.203.0.195)  19.654 ms  17.386 ms  17.527 ms
 8  one.one.one.one (1.1.1.1)  14.676 ms  18.266 ms  14.587 ms


Inace ide ping do 8.8.8.8 katastrofa sad, ocekivano.
[ Milan Kragujevic @ 13.04.2020. 17:51 ] @
Sada uradi ping ka 10.175.31.254 npr 100 komada
[ Branimir Maksimovic @ 13.04.2020. 18:06 ] @
Katastrofa:
Code:

--- 10.175.31.254 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99128ms
rtt min/avg/max/mdev = 5.579/103.264/341.066/83.326 ms


a evo i 1000 komada do 8.8.8.8
Code:

--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 999917ms
rtt min/avg/max/mdev = 9.981/105.361/435.625/80.638 ms


Znaci od 5 po podne pa negde do ponoci katastrofa.
[ Milan Kragujevic @ 13.04.2020. 18:11 ] @
Da, last mile mreza je u katastrofalnom stanju. Nema ti tu pomoci :/ Zovi ih neka ti umanje racun makar, sve to sto vidis ti vide i oni.
[ tox master @ 13.04.2020. 22:59 ] @
Evo kod mene kako izgleda do prvog hopa i to sada u ponoc kada je malo rasterecenije,oko 20h je mnogo losije,ponekad vidim paket i po 500ms.
Gledam ovde pa dosta vas ima bolji ping do Googla nego ja do CMTS
Koliko bi realno trebao da bude ovaj ping kad je mreza ok?

Pinging 172.16.0.1 with 32 bytes of data:
Reply from 172.16.0.1: bytes=32 time=14ms TTL=254
Reply from 172.16.0.1: bytes=32 time=47ms TTL=254
Reply from 172.16.0.1: bytes=32 time=33ms TTL=254
Reply from 172.16.0.1: bytes=32 time=28ms TTL=254
Reply from 172.16.0.1: bytes=32 time=10ms TTL=254
Reply from 172.16.0.1: bytes=32 time=29ms TTL=254
Reply from 172.16.0.1: bytes=32 time=28ms TTL=254
Reply from 172.16.0.1: bytes=32 time=10ms TTL=254
Reply from 172.16.0.1: bytes=32 time=11ms TTL=254
Reply from 172.16.0.1: bytes=32 time=10ms TTL=254
Reply from 172.16.0.1: bytes=32 time=14ms TTL=254

Ping statistics for 172.16.0.1:
Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 47ms, Average = 21ms
[ Branimir Maksimovic @ 13.04.2020. 23:09 ] @
Ko po komandi svi polezu izgleda oko ponoci i do zore ping ok:)
[ Milan Kragujevic @ 15.04.2020. 09:32 ] @
Vip 4G

Ping google.rs:

Code:

Ping statistics for 172.217.4.99:
    Packets: Sent = 46, Received = 46, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 147ms, Maximum = 168ms, Average = 159ms


Traceroute google.rs:

Code:

Tracing route to google.rs [172.217.4.99]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    <1 ms    <1 ms    <1 ms  10.20.0.1
  3   208 ms   219 ms   220 ms  10.234.21.66
  4    28 ms    14 ms    15 ms  10.234.21.65
  5     *        *        *     Request timed out.
  6    21 ms    14 ms    14 ms  77.243.16.161
  7     *        *        *     Request timed out.
  8    51 ms    48 ms    47 ms  195.3.114.37
  9    52 ms    48 ms    49 ms  lg37-9073.as8447.a1.net [195.3.64.149]
 10     *       53 ms    48 ms  195.3.68.6
 11     *        *       53 ms  lg2-9071.as8447.a1.net [195.3.64.10]
 12   248 ms    61 ms    60 ms  72.14.205.220
 13    73 ms    68 ms    68 ms  74.125.242.242
 14    66 ms    65 ms    62 ms  108.170.236.247
 15    73 ms    75 ms    89 ms  108.170.234.10
 16    98 ms    78 ms    78 ms  108.170.234.119
 17   157 ms   150 ms   196 ms  172.253.65.174
 18   171 ms   158 ms   155 ms  216.239.57.136
 19   168 ms   169 ms   168 ms  216.239.59.150
 20   165 ms   158 ms   158 ms  108.170.244.1
 21   163 ms   161 ms   169 ms  108.170.233.109
 22   162 ms   159 ms   169 ms  ord36s04-in-f99.1e100.net [172.217.4.99]

Trace complete.





Modem zeza. Kada ga restartujem radi dobro par dana i krene tako. Štaviše mislim da mi se on i MikroTik ne podnose. Imam drugi modem, naravno, onaj ZTE koji Vip daje, nisam ga ni otvorio, hteo da prodam, a da koristim stari. Starom je uz garanciju očigledno prošao i životni vek :)

Doduše Vip ima mnogo convoluted rute, umesto direktno kroz SOX i da bude 7 hop-ova, oni idu kroz A1 Austria, pa ima 22 hop-a i traje 100 godina...

Evo kako to može da izgleda:
Code:

traceroute to 172.217.4.99 (172.217.4.99), 30 hops max, 60 byte packets
 1  185.119.89.1 (185.119.89.1)  0.514 ms  0.589 ms  0.674 ms
 2  google.sox.rs (185.1.27.60)  6.237 ms  6.804 ms  6.498 ms
 3  108.170.250.168 (108.170.250.168)  6.272 ms 108.170.250.169 (108.170.250.169)  7.269 ms 108.170.250.185 (108.170.250.185)  5.925 ms
 4  108.170.226.126 (108.170.226.126)  29.779 ms 209.85.247.28 (209.85.247.28)  37.861 ms 108.170.226.42 (108.170.226.42)  30.460 ms
 5  209.85.245.30 (209.85.245.30)  53.516 ms  53.175 ms  53.207 ms
 6  108.170.234.10 (108.170.234.10)  52.765 ms  44.012 ms 209.85.244.158 (209.85.244.158)  44.385 ms
 7  209.85.245.231 (209.85.245.231)  50.996 ms 108.170.234.119 (108.170.234.119)  58.638 ms 209.85.245.231 (209.85.245.231)  50.682 ms
 8  172.253.65.164 (172.253.65.164)  118.549 ms 172.253.65.166 (172.253.65.166)  126.330 ms 172.253.65.174 (172.253.65.174)  117.746 ms
 9  216.239.57.136 (216.239.57.136)  125.006 ms  133.130 ms 216.239.59.0 (216.239.59.0)  124.361 ms
10  216.239.63.32 (216.239.63.32)  141.730 ms  141.729 ms 209.85.251.240 (209.85.251.240)  144.769 ms
11  108.170.243.225 (108.170.243.225)  126.059 ms  125.387 ms  126.105 ms
12  108.170.233.109 (108.170.233.109)  125.068 ms  124.766 ms 108.170.233.111 (108.170.233.111)  135.537 ms
13  ord36s04-in-f99.1e100.net (172.217.4.99)  135.414 ms  135.745 ms  124.427 ms





edit Čekaj, jel moguće da Vip DNS resolve-uje google.rs na server u USA?! Telekom DNS resolve-uje google.rs na 172.217.18.67, što je u Budimpešti.. Svejedno na Vip-u i do tamo bude previše hop-ova jer ide preko Austrije, ali ih ima 7 komada manje nego ka USA. Ping je isti iz nekog razloga, moguće da je IP adresa anycast. Ne znam...

Code:

Tracing route to bud02s26-in-f3.1e100.net [172.217.18.67]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    <1 ms    <1 ms    <1 ms  10.20.0.1
  3    26 ms   229 ms   231 ms  10.234.21.66
  4    29 ms    14 ms    14 ms  10.234.21.69
  5     *        *        *     Request timed out.
  6    22 ms    14 ms    16 ms  77.243.16.161
  7     *        *        *     Request timed out.
  8    52 ms    50 ms    57 ms  195.3.114.37
  9    43 ms    58 ms    45 ms  lg37-9073.as8447.a1.net [195.3.64.149]
 10     *       55 ms    50 ms  195.3.68.6
 11     *        *       54 ms  lg2-9071.as8447.a1.net [195.3.64.10]
 12    72 ms    70 ms    66 ms  72.14.205.220
 13    66 ms   110 ms    68 ms  74.125.242.225
 14    72 ms    54 ms    78 ms  64.233.175.99
 15    72 ms    68 ms    69 ms  bud02s26-in-f3.1e100.net [172.217.18.67]

Trace complete.
[ Branimir Maksimovic @ 15.04.2020. 15:20 ] @
Poznanik sa irc-a kuka na SBB, ne moze sad da poslje mail :P
Supernova se drzi!

[ dejanet @ 15.04.2020. 15:28 ] @
SBB zadnjih par sati jedva da radi...
Telenor 4G radi na skrge takodje..
[ SASA M. @ 15.04.2020. 16:14 ] @
Primetio sam takodje trokiranje sbb, malo pre se unormalilo. Prijateljica na mts optika kaze da je i kod njih bilo danas kocenja.
[ optix @ 15.04.2020. 16:39 ] @
Citat:
Milan Kragujevic:
edit Čekaj, jel moguće da Vip DNS resolve-uje google.rs na server u USA?! Telekom DNS resolve-uje google.rs na 172.217.18.67, što je u Budimpešti.. Svejedno na Vip-u i do tamo bude previše hop-ova jer ide preko Austrije, ali ih ima 7 komada manje nego ka USA. Ping je isti iz nekog razloga, moguće da je IP adresa anycast. Ne znam...


Provajderov DNS koji koristis je samo rekurzivni resolver koji prosledjuje, i usput kesira, upit ka autoritativnim DNS serverima za domen/zonu za koju ga pitas. U konkretom slucaju, google DNS je taj koji treba da vrati rekorde sa IP adresama koji su najblizi tebi tj. tvom provajderu. Ukoliko provajder ima cache-ing servere za google/youtube servise, onda ce odgovor biti sa tim adresama, inace dalje zavisi od dogovora i konfiguracije - da li ce odgovor uputiti na neki shared cache-ing cluster (SOX valjda ima jedan.. ), najblizi DC gde se nalazi google, ili bas nazad u Ameriku.. sto moze biti posledica i neke privremene greske u konfiguraciji.



Na temu "ping-a"... od kuce naravno

Code:

root@Pi4:~# traceroute www.google.com
traceroute to www.google.com (2a00:1450:400a:800::2004), 30 hops max, 80 byte packets
 1  cisco (2a02:169:****:1::1)  0.206 ms  0.237 ms  0.219 ms
 2  790wal1.fiber7.init7.net (2a02:168:2000:6b::1)  0.828 ms  0.866 ms  0.804 ms
 3  790klo1.fiber7.init7.net (2001:1620:2::10a)  0.844 ms  0.870 ms  0.831 ms
 4  r1zrh10.core.init7.net (2001:1620:2::15d)  0.365 ms  0.321 ms  0.314 ms
 5  r1glb3.core.init7.net (2001:1620:2::95)  0.453 ms  0.322 ms  0.404 ms
 6  r1glb1.core.init7.net (2001:1620:1000::39e)  0.399 ms  0.449 ms  0.423 ms
 7  pni-google.init7.net (2001:1620:1000::82)  0.578 ms  0.570 ms  0.541 ms
 8  2001:4860:0:7d::1 (2001:4860:0:7d::1)  0.919 ms  0.925 ms  0.872 ms
 9  2001:4860:0:1::633 (2001:4860:0:1::633)  0.905 ms  0.930 ms 0.898 ms
10  zrh11s02-in-x04.1e100.net (2a00:1450:400a:800::2004)  0.907 ms  0.937 ms  0.897 ms
root@Pi4:~#


[ Branimir Maksimovic @ 15.04.2020. 16:56 ] @
optix:"2a02:169:****:1::1"

Super kad imas ipv6 :P
[ optix @ 15.04.2020. 17:12 ] @
Da, nazalost provajderima u Srbiji je to jos uvek nuklearna fizika da puste rezidencijalnim korsnicima...

Znam samo jednog koji to ima implementirano za sve korisnike koji podrzavaju jos od pre 10 godina..
[ Branimir Maksimovic @ 15.04.2020. 17:43 ] @
Inace meni do google-ta:

Code:

~ >>> traceroute google.com                                                                                                                                                                              
traceroute to google.com (173.194.222.100), 30 hops max, 60 byte packets
 1  router.asus.com (192.168.101.1)  0.281 ms  0.348 ms  0.238 ms
 2  10.175.31.254 (10.175.31.254)  5.935 ms  5.471 ms  5.905 ms
 3  87.250.37.133 (87.250.37.133)  6.356 ms  6.042 ms  6.328 ms
 4  google.sox.rs (185.1.27.60)  11.610 ms  11.646 ms  11.528 ms
 5  108.170.250.168 (108.170.250.168)  11.339 ms 108.170.250.185 (108.170.250.185)  11.653 ms 108.170.250.168 (108.170.250.168)  12.757 ms
 6  108.170.226.126 (108.170.226.126)  30.411 ms  29.147 ms  30.399 ms
 7  108.170.228.255 (108.170.228.255)  33.432 ms 209.85.252.77 (209.85.252.77)  30.638 ms 72.14.239.167 (72.14.239.167)  60.123 ms
 8  108.170.230.251 (108.170.230.251)  60.094 ms 209.85.245.133 (209.85.245.133)  71.468 ms  71.433 ms
 9  72.14.238.168 (72.14.238.168)  64.279 ms 108.170.235.204 (108.170.235.204)  70.491 ms  69.941 ms
10  209.85.254.135 (209.85.254.135)  71.036 ms 216.239.58.53 (216.239.58.53)  71.453 ms 172.253.51.189 (172.253.51.189)  71.387 ms
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  lo-in-f100.1e100.net (173.194.222.100)  70.581 ms *  70.380 ms

[ Panta_ @ 16.04.2020. 10:38 ] @
Citat:
Poznanik sa irc-a kuka na SBB, ne moze sad da poslje mail

SBB zadnjih par sati jedva da radi...


http://rs.n1info.com/Vesti/a58...m-posledica-sajber-napada.html
[ Milan Kragujevic @ 16.04.2020. 23:32 ] @
Jel vam radi Telekom VDSL? Kostolac i okolna mesta, kao i deo mrežne grupe 012, ima problem sa xDSL uslugama, a recimo moje selo Klenovnik već 12 sati nema fiksni telefon niti Internet (mrtva linija).

Pošto nas ima koji radimo od kuće, "organizovali" smo "masovno" prijavljivanje* Telekomu, da ne bude da se samo ja žalim jer celo selo nema ništa od usluga. Brine me da li će da poprave sutra ili subota ili utorak..?

* prijavljivanje poteškoće operateru, kontra popularnom verovanju, je jedini način da se ubrza rešavanje - žalbe na forumu nisu. Masovno prijavljivanje samo dodatno ubrzava, jer nema jedna prijava od "najproblematičnije korisnika interneta u istoriji univerzuma i čoveka koga su skoro svi provajderi trajno stavili na blackliste jer ih je prijavljivao za prekršaje MTTT-u i RATEL-u" već vide lepo da se 15+ korisnika žalilo na uslugu Interneta i poneki samo za fiksni, pa će možda brže reagovati, a ne zatvoriti tiket uz "korisnik halucinira probleme" kao što obično bude
[ Milan Kragujevic @ 16.04.2020. 23:55 ] @
Proradilo pre 5 minuta, Kostolac malo ranije. Ping 4ms, brzina puna, margina +1.9dB bolja nego inace...
[ optix @ 17.04.2020. 00:10 ] @
Mozda su te prebacili na "istureni stepen"
[ Milan Kragujevic @ 17.04.2020. 00:24 ] @
Već jesam, samo je istureni stepen udaljem 1.3km. Centrala je 5km udaljena.

Nisu svi istureni stepeni isti :)



Margina sa 7.0 dB na 8.9 dB za downstream. Ništa drugo se nije promenilo. Sumnjam da su skratili local loop za 50 metara :) Posebno što je podzemna mreža, i u zvaničnom dopisu da ovo srede i dodaju MSAN bliže selu su se pravdali da će "uskoro optika" (koja ni u Požarevac nije stigla, kamo li selo sa <1000 stanovnika), pa "nije ekonomično menjati bakarnu mrežu" i "mreža je podzemna, mora da se kopa". Bukvalno "mora da se kopa" napisali.

Margina je bolja jer nisu svi nakačili svoje modeme, mnogi modemi odustali od rekonekcija, pa zato. Sutra će biti 7.0 dB, kao i uvek.

edit: smanjena rezolucija slike zbog scroll-a

[Ovu poruku je menjao Milan Kragujevic dana 17.04.2020. u 14:39 GMT+1]
[ optix @ 17.04.2020. 01:50 ] @
Nemam sta pametno da dodam, sve ti je vec jasno

Nego.. citam sad malo temu unazad, pa me je zainteresovalo ovo sto si napisao za VDSL vectoring.. Ispada da je Telekom Srbija poceo da da radi LLU (local-loop unbundling)?? Novi momenti za mene ako je tako..

I, samo da znas, nisu sva resenja koja se koriste za FTTH, xGPON based Mada za TS i Orion to sigurno jesu "poslednje reci tehnike" ("prvi u evropi" i slicne gluposti.. )
[ Milan Kragujevic @ 17.04.2020. 13:38 ] @


Ja baš mislim da ne koriste LLU već da smo svi na tom DSLAM-u (nas 20-tak, sudeći po papiru koji su doneli radnici, od mogućih 150) na Telekomu, pa "im se može". I da može LLU, ne bi niko od virtuelnih xDSL provajdera to koristio.

A što se tiče FTTH i tehnologije, da, postoji nekoliko vrsta PON tehnologija, postoje i egzotičnije stvari, kao što znaš, ali nema svrhe tome, kada i Telekom i Orion imaju "zagušenja" na optici gde protok pada na ~100 Mb/s, a poznato je da nisu uspeli da nakupe više od 50 korisnika. Problem je što oni "hand-wavy" objašnjavaju da će "moći" da upgrade-uju mrežu "kad treba" "samo promenom opreme". U tom slučaju zašto nabavljate krš OLT uopšte, ako znate da ćete menjati? Ne dodati, morate sve da skinete i stavite novo za novi standard, i naravno novi ONT CPE svakom korisniku - dakle od toga nema ništa, SBB godinama pokušava da "digitalizuje" neke gradove, a tu se ništa ne uklanja od opreme.

Rade oni tih 2.4/1.2 Gb/s na cele ulice i kao to je OK to će da radi, i kad ne radi prvih godinu-dve će biti fazoni "ma nemoguće je da ne radi na optici", a onda će da krene agonija korisnika, i poneko umanjenje računa, dok na kraju ne krenu da rade node splitove kao i na kablovskoj i da bude "dobro". A to bi lakše sad uradili nego u budućnosti. Džabe što oni i do kuće dovedu 4 vlakna, ako koriste samo 1, i to 1 koriste za celu ulicu.
[ optix @ 17.04.2020. 16:58 ] @
VDSL vectoring u principu nije podrzan tamo gde je pristuan LLU jer onda pojedinacni VDSL DSLAM ne moze ispravno da kontrolise crosstalk i noise ako i jedna parica iz tog snopa kablova zavrsava na drugom DSLAM-u, pogotovu DSLAM-u drugog operatera. Kako u Srbiji mislim da ipak jos uvek nije regulisan LLU, i TS ne nudi iznajmljivanje ni parica ni prostora za xDSL opremu drugim operaterima, to nije razlog zasto se na nekom mestu ne moze koristiti vectoring.

Drugi, tehnicki verovatniji, razlog da se ne moze raditi vectoring, je da parice iz istog snopa kabla ne zavrsavaju na istom VDSL DSLAM-u/ploci, nego je u igri neki mix sa ADSL2, G.SHDSL ili i starijim plocama ili DSLAM-ovima (mada obicne ADSL ploce koliko znam ne bi trebalo da vise drze u produkciji) sto se u principu onda svodi na isti problem kao i prethodni - nemogucnost ispravke i vectoringa signala za sve parice u istom kablu, iako je sva oprema vlasnistvo TS-a.

Treci razlog je prisustvo VDSL CPE uredjaja korisnika koji ne podrzavaju VDSL vectoring - ovo "moze" (pod znacima navoda, jer i ne mora..) da bude donekle problematicno obzirom da TS ipak iznajmljuje VDSL portove i drugim operaterima i onda je znatno teze kontroslisati kakvi se sve CPE uredjaji nalaze sa druge strane parice. To bi mozda moglo da se regulise nekom internom uredbom izmedju operatera, da se korisnicima daje samo oprema koja podrzava npr full vectoring (G.993.5, ili neki od annex-a G.993.2) ili makar downstream vecroing (G.993.2 annex X). Medjutim, pitanje je koliko je to realno potrebno jer TS nije poceo da koristi i komercijalno nudi VDSL2 pre 15 godina, nego relativno skoro (par godina) a da nudi ostalim provajderima jos skorije, tako da su i svi modemi relativno novi, a broj modema koji eventualno ne podrzava neki od pomenutih ITU standarda (makar i kroz firmware update) i annexa, verujem da tezi 0.

U krajnjem slucaju, postoji i nesto sto se zove 'zero-touch vectoring' - bas kao resenje da se operaterima da mogucnost vectoring-a (doduse samo u downstream putanji) na mrezi gde ima legacy VDSL opreme. Teorijski, zero-touch vectoring se moze raditi i u mix okruzenju sa ADSL modemima, pa bi to eventualno moglo da pokrije slucajeve 1 i 2 sa pocetka poruke, ali.. verujem da je to vec SF prica za TS, a i pitanje koliki bi realni dobitci bili (jednostavnije im je da kopaju za novi istureni stepen ), itd..


Medjutim, kazati da vectoring nije podrzan zato sto se VDSL usluga nudi drugim provajderima, pod uslovima pod kojim je Telekom Srbija trenutno nudi, i kao razlog navoditi nekakav MPLS tunnel, nema veze sa mozgom i cist je BS (pa ne radi se vectoring u transportnoj mrezi i MPLS tunnelu..). Razdvajanje korisnika (za druge provajdere) cak nema nikakve veze ni sa bilo kojim DSLAM-om i njegovim transportom, jer se 'razdvajanje' radi u aggregacionoj mrezi - na BRAS uredjaju koji drzi L2TP tunnele ka LNS-ovima razlicitih provajdera koji konacno terminiraju PPPoE over L2TP konekcije korisnika. Taj tunel moze da zavrsi i u Americi ako treba, ili na Mesecu, sto tehnike tice, apsolutno svejedno.. Vectoring je jasno, samo i iskljucivo vezan za RF spektar na parici u access delu - tj. last mile konekciji. Bas me zanima ko ti je preneo tu informaciju iz Telekoma.. ?


Sto se FTTH-a tice, nisam misio na bilo koju *PON mrezu, vec direktno vlanko do svakog korisnika posebno i posveceno. Skuplje mozda malo u pocetku, ali resava problem kasnijeg upgrade-a brzine mnogo lakse i jeftinije Ali, jbg.. znam da nije slucaj u Srbiji.
[ Milan Kragujevic @ 17.04.2020. 17:36 ] @
RE: VDSL Vectoring

Ukratko: znam. Da ne citiram pojedinačno: Telekom ne nudi LLU uopšte, Vectoring ne nudi jer zašto bi se mučili, nude samo gde su uslovi savršeni, a tu Vectoring generalno ne treba. Drugi, to je tačno. ADSL-only ploče nemaju ovde u okolini, pa ne nude Vectoring. Prebacivanje sa VDSL na ADSL2+ i nazad se vrši jednim klikom, i restartuju modem. SHDSL nemaju AFAIK. Parice u dosta manjih mesta koje nemaju išaranu mrežu sa isturenim stepenima imaju situaciju da sve parice idu do jednog DSLAM-a, pa u dosta mesta to nije razlog. Treće, nije ni to razlog, Orion daje TP-Link koji podržava Vectoring, zapravo sve na VDSL-u podržava Vectoring. Telekomovci bi mogli da ljude prebace na VDSL, ko već ima VDSL CPE, pošto ADSL-only CPE više ne daju, međutim mrzi ih.

RE: 'zero-touch vectoring'
Nemam pojma.

>nema veze sa mozgom i cist je BS
Tako je, zato ja DSL reseller-e zovem virtuelnim provajderima, jer su oni kao MVNO u mobilnoj mreži.

>direktno vlanko do svakog korisnika posebno i posveceno
Da, Južnoafrička Republika je to uradila za Kepjtaun, svaki korisnik ima dedicated fiber do OLT-a, kao u xDSL mreži parice. Tu će moći i 100/100 Gbps, ma može sve, ali ovi naši koriste običan GPON i celu ulicu na jedno vlakno.

>Bas me zanima ko ti je preneo tu informaciju iz Telekoma.. ?
[email protected], gomila ljudi iz I.J. Požarevac, Marina S. (da joj ne pišem ime, znaju svi ko je ona), par ljudi iz okolnih poslovnica, terenska ekipa.

Lažu, mažu, odugovlače, itd., jer im se može, i misle da neću primetiti. A i ako primetim, šta im mogu, jer ipak -- MORA DA SE KOPA.

Inače tu podzemnu telefonsku mrežu, za koju oni sada naplaćuju priključnu taksu 6000 din, su kopali moji baba i deda, kao i svi koji su tada u selu želeli fiksni telefon, sredinom 90-ih. Tada je moglo "DA SE KOPA", a sada ne može.

Ovde ni fiksni ne možeš da uvedeš, tj. recimo dva fiksna. Ja probao da uzmem dva VDSL paketa pre 5 godina, nisu hteli ni drugi fiksni da uvedu, "nema teh. mogućnosti".


[ Milan Kragujevic @ 18.04.2020. 21:38 ] @


Margina se vratila na normalnu vrednost, ping ostao 4-5 ms ka Telekomu i 9-11ms ka google.rs.
[ Goran Mijailovic @ 12.05.2020. 17:27 ] @
Ping do mog modema. Wifi je u pitanju VIP 4g a modem je u susednoj prostoriji, signal putuje kroz jedan zid.

Šta da mu radim?

C:\WINDOWS\system32>ping -n 30 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=81ms TTL=64
Reply from 192.168.0.1: bytes=32 time=20ms TTL=64
Reply from 192.168.0.1: bytes=32 time=220ms TTL=64
Reply from 192.168.0.1: bytes=32 time=55ms TTL=64
Reply from 192.168.0.1: bytes=32 time=144ms TTL=64
Reply from 192.168.0.1: bytes=32 time=122ms TTL=64
Reply from 192.168.0.1: bytes=32 time=11ms TTL=64
Reply from 192.168.0.1: bytes=32 time=102ms TTL=64
Reply from 192.168.0.1: bytes=32 time=236ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=11ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=10ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64

Ping statistics for 192.168.0.1:
Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 236ms, Average = 35ms
[ Milan Kragujevic @ 12.05.2020. 17:35 ] @
Standardno: drugi kanal, smanji širinu kanala na 20 MHz ako već nije, i eventualno uzmi nešto na 5GHz.

To nije do slabog signala već do RF smetnji i zauzeća RF spektra od strane drugih WiFi uređaja
(proveriš tako što staneš pored modema i proveriš da li ima varijacija u ping-u, ako ima onda je do zauzeća RF spektra)

Svaki WiFi uređaj mora da čeka dok svi ostali na tom kanalu ne prestanu da "pričaju" da bi poslao nešto.
Ako dođe do sudara mora da čeka random interval pa proba ponovo - u tom trenutku neki drugi uređaj mu može oteti "slot", itd.
To je ugrađeno u 802.11 protokole, i ne može se izbeći.

A pritom WiFi ima kapaciteta za 3 mreže na 20 MHz ili 2 ako je jedna na 40 MHz - 1, 6, 11 kanale.
Razmak između kanala je 5 MHz a jedan uređaj koristi 20 MHz.
[ Goran Mijailovic @ 12.05.2020. 19:14 ] @
Već sam emigrirao na 13. kanal, nemam gde više, sad sam suzio na 20MHz, čini mi se da je bilo 20/40 namešteno.

[att_img]

EDIT

Sad izgleda mnogo bolje, videćemo kako će da se ponaša u budućnosti.

C:\WINDOWS\system32>ping -n 30 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.0.1:
Packets: Sent = 30, Received = 30, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 7ms, Average = 3ms
[ Milan Kragujevic @ 12.05.2020. 19:30 ] @
A, pa tu je dobro, svi se lepo ispomerali gde treba :) Osim ovog MERCUSYS i ZTE-a.

Ako je ZTE MF283V, on često zna da prebaci na 40 MHz čak i u uslovima koji ne dozvoljavaju takvu radnju po pravilima WiFi Alliance i standardu 802.11n. ZTE MF283+ to nije radio, koliko znam.

Pravila su da su približno 40 MHz ispred ili iza trenutnog kanala slobodni, dakle oko 8 kanala. Međutim, ZTE MF283V gleda samo da li je trenutni kanal slobodan, pa ako jeste onda pusti 40 MHz,
što pravi smetnje korisnicima. Odatle i dolazi osnovi Vip-ov troubleshooting kada je brzina loša na WiFi a dobra na kablu: Promenite kanal i stavite na 20 MHz. Ustaljena procedura jer je firmware
modema tako (nepravilno) namešten...
[ Branimir Maksimovic @ 12.05.2020. 23:56 ] @
A da vidis ping do telefona i wireless uredjaja :P
[ Milan Kragujevic @ 13.05.2020. 00:05 ] @
Gde?

Nego, meni nešto nenormalno radi net trenutno, ruta 4G <-> server u datacentru Telenora mi ima oko 20 hop-ova kroz Austriju, Francusku, itd.

Obično bude 4-5 hop-a zavisi od provajdera, svi imaju peering u SOX.

Imao sam prekid od 30 minuta gde je prvi ruter Vip mobile posle bazne stanice (treći hop ne računajući modem, prva dva su firewall za korisnike
pa onda interni ruter u okviru bazne stanice, tj. spojna tačka pristupne na core mrežu -- problem pravi prvi "korak" u core mreži) samo drop-ovao
pakete ka IP adresama provajdera, ceo opseg /24 (možda i više). Onda se "unormalilo" sa tim rutama... Čudno, dosta čudno.

Prijatelj je na Orion optici primetio da ping ka Orion internoj mreži varira mnogo (do čak 13ms), a ka SBB speedtest serveru je konstantno nizak.

Čudni su putevi internetski
[ Branimir Maksimovic @ 13.05.2020. 00:11 ] @
Milan:"Gde?"

Do bilo kog telefona recimo na wifi. Kod mene je katastrofa, bilo 5Ghz bilo 2.4Ghz. (imam kineskog misa koji se gadjao sa ruterom na 2.4Ghz na kanalu 10 pa sam prebacio, ali dzaba*)
[ Milan Kragujevic @ 13.05.2020. 00:30 ] @
Gle' stvarno!



Ne znam, USB C Ethernet adapter za telefon možda?
[ Branimir Maksimovic @ 13.05.2020. 01:11 ] @
Heh, ne smeta to, posto je ping ka spolja ok, to ne mogu nikako da objasnim :P
[ Goran Mijailovic @ 13.05.2020. 20:02 ] @
Citat:
Branimir Maksimovic:
A da vidis ping do telefona i wireless uredjaja :P


Ne kapiram primedbu, ping do rutera bi trebao da bude nula ili što bliže nuli :)
[ Branimir Maksimovic @ 13.05.2020. 23:57 ] @
"Ne kapiram primedbu, ping do rutera bi trebao da bude nula ili što bliže nuli :)"

Zicano da, ali ovde nisam mislio do rutera nego od kompa do telefona recimo...
[ bachi @ 14.05.2020. 07:13 ] @
Možda je uključen neki režim štednje za wifi na mobilnom, pa otuda očajan ping, jer mu je ICMP saobraćaj nizak prioritet i neće da se cima oko njega da diže snagu?
[ Branimir Maksimovic @ 01.09.2020. 19:59 ] @
Supernova trakira drugo vece za redom:

Citat:

-- yahoo.com ping statistics ---
100 packets transmitted, 65 received, 35% packet loss, time 99641ms
rtt min/avg/max/mdev = 164.579/169.257/183.562/5.688 ms


Sa ovolikim gubitkom ne moze da se slusa radio stream :(
Interesantno je da je ping stabilan, ali je packet loss veliki...
[ Zlatni_bg @ 02.09.2020. 13:36 ] @
Probaj nesto blize da pingujes?
[ Branimir Maksimovic @ 02.09.2020. 14:34 ] @
Katastrofa je i u Sr. Recimo ne moze da izvuce speedtest kako treba ni do telenora,..
Videcu veceras kako ce biti, ali negde 19-20 pa do oko 2 ujutro je lose, i onda ok.
[ Milan Kragujevic @ 02.09.2020. 14:43 ] @
Ja sam bio rekao nešto. Jel pao CGNAT?
[ Living Light @ 02.09.2020. 14:49 ] @
Ping je ok, par milisekundi,
Ali Brate, dok ucita stranicu, da mecku rodis!

Porbao sa BG, Sa DE, Sa Londonom,
sa Amerima, sa Rusima, sa Kinezima, Japancima.

... nešto Štekuje, i glavi.

(SBB-Konekcija)
[ Branimir Maksimovic @ 02.09.2020. 14:50 ] @
Milane, nije, jos je isti ip iz 2018 iz vremena AVComa.
[ Zlatni_bg @ 02.09.2020. 15:43 ] @
Imadoh ranije, davno jednu slicnu situaciju. Da vam nije neko pametan postavio video nadzor i zakacio modulator na postojecu kablovsku mrezu?
[ Branimir Maksimovic @ 02.09.2020. 15:54 ] @
Nije, to bi pravilo smetnje 24/7, a ne samo u vecernjim satima.
[ Zlatni_bg @ 02.09.2020. 16:14 ] @
Onda je overload, nema sta drugo... meni je jitter par milisekundi izmedju 16h i 1h uglavnom, izmedju 1h i 12h bude ispod milisekunde. Ali packet loss je ozbiljna stvar.

Ako ti ruter prima ping zahteve, ili sta god da imas forwardovano/dmzovano, zovi ih, trazi tier 3 podrsku ako mozes da je dobijes, neka te pinguju i bice im jasno. Ja sam samo tako uspevao da se izborim sa slicnim problemima, bez tier 3 nema nista.
[ Milan Kragujevic @ 02.09.2020. 16:34 ] @
Ako Branimir dođe do Tier 3 podrške Supernove, častim pivo ko dođe.
[ Living Light @ 02.09.2020. 16:58 ] @
Evo moje muke,
ako Vama ublazava situaciju:
[ Zlatni_bg @ 03.09.2020. 02:13 ] @
Meni iskreno vise stvara ljubomoru sto sam na D3 paketu i dalje i imam 2.5x manji upload od tog. Download imam 150, izvlacim ga svuda, ali iskreno sem kad svlacim igrice od 100GB, bas, bas, bas nemam potrebu za njime. To sto si ti Robi opisao meni vise deluje ili kao da su uredjaji stariji (browseri rade losije a danas su web sajtovi ultra teski) ili kao da nemas dobro DNS kesiranje kod provajdera. Bane ima drugi problem, da napravim paralelu sa elektronikom, otprilike posaljes signal i ne dobijes nikakav odgovor. U idealnom slucaju kad dobijes info (time-out) da povratni podatak nije stigao, automatski uredjaj ponovo salje zahtev, ali to pogotovu u kablovskoj mrezi gde se zahtevi i tako i tako salju 2x jer se prvo proverava "da li moze da se salje paket" pa onda kad se dobije info da moze salje bude mnogo vise od 4x... Da ne pricam da je i 1% packet loss katastrofalan po nekim mojim standardima.

To njegovo mi bas deluje da su ih stavili ihaha na jedan CMTS, i da bukvalno od kolicine zahteva CMTS vise ni ne stize da obradi podatke o "izgubljenim" paketima vec jednostavno ima kapacitet samo da prosledi ono sto je uspesno poslato i vraceno. Zato ima "okej" ping a uzasan loss. Opet nisam siguran kako takvi uredjaji rade, ali ovo mi deluje kao prica "aj da stignem da odradim kol'ko mogu, ono sto nisam uradio, jbga, ako je bitno stici ce opet zahtev pa ako budem imao vremena..."
[ Branimir Maksimovic @ 03.09.2020. 05:55 ] @
Sinoc nije bilo problema, ovo je izgleda bilo nesto privremeno. Videcu kako ce biti veceras...
[ Branimir Maksimovic @ 03.09.2020. 09:32 ] @
Inace ponovo isti problem sa kasnjenjem paketa:
Code:

--- yahoo.com ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 104302ms
rtt min/avg/max/mdev = 197.908/3795.836/10158.691/2221.165 ms, pipe 11


I nakon restarta modema:
Code:

--- yahoo.com ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99124ms
rtt min/avg/max/mdev = 113.501/116.345/129.375/3.180 ms


[ Milan Kragujevic @ 03.09.2020. 09:44 ] @
Jel beše EPC3925?

Pinguj njega, i naravno pogledaj manufactured date na nalepnici modema. Verovatno je 2009.

Ako ti i ping ka modemu ne valja, zovi SuperZlo da ti zamene, i kad dođu terenci traži onaj što daju korisnicima sa Super max paketom na coax-u što ima 16/4 kanala.
[ Branimir Maksimovic @ 03.09.2020. 10:28 ] @
Milan:"Jel beše EPC3925?"

Taj.

"Pinguj njega, i naravno pogledaj manufactured date na nalepnici modema. Verovatno je 2009."

U bridge modu je. Firmware je iz 2012...

Modem radi dobro, samo je onaj isti problem kada je cvor opterecen kao sto je bilo u martu/aprilu.

[ Milan Kragujevic @ 03.09.2020. 10:32 ] @
Pinguj ga na 192.168.100.1, tu se javlja k.kad je u bridge modu. Proveri parametre, pošalji skrinšot. Firmver se može ažurirati, neprimećeno, "Mfg. date" na nalepnici istinu govori.
[ Branimir Maksimovic @ 03.09.2020. 11:16 ] @
Code:

--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9112ms
rtt min/avg/max/mdev = 0.627/0.677/0.903/0.076 ms


Parametri su ok, potpuno normalni:

Code:

Downstream Channels            
        
        
      Power Level:     Signal to Noise Ratio:
Channel 1:     -2.9 dBmV     40.8 dB
Channel 2:     -0.7 dBmV     41.9 dB
Channel 3:     -0.8 dBmV     42.5 dB
Channel 4:     -1.6 dBmV     42.1 dB
Channel 5:     -2.5 dBmV     40.0 dB
Channel 6:     -2.4 dBmV     40.8 dB
Channel 7:     -1.0 dBmV     42.6 dB
Channel 8:     -3.2 dBmV     41.0 dB

          
Upstream Channels            
        
        
      Power Level:
Channel 1:     40.7 dBmV
Channel 2:     40.9 dBmV
Channel 3:     0.0 dBmV
Channel 4:     0.0 dBmV


Code:

Bootloader Revision:     2.3.0_R1
Current Software Revision:     epc3925-E15-13-v302r125561-120727c
Firmware Name:     epc3925-E15-13-v302r125561-120727c.bin
Firmware Build Time:     Jul 27 21:42:38 2012


Ne vidim kod njega nista sporno. To usporenje inace ide oko 7 uvece, mada je nakjuce prvi put bio i packet loss.
[ Milan Kragujevic @ 03.09.2020. 11:25 ] @
Pinguj u 20h i to samo ako tad krene da pravi probleme. Imao sam slučaj da je to bio problem ne do CMTS-a nego do modema. Količina saobraćaja na DOCSIS mreži mu napravi problem, sa kojim bi se možda izborio neki modem sa 16/4 ili 24/8 kanala. Ako SuperAVCom uopšte ima 16 kanala da ti alocira...
[ Zlatni_bg @ 03.09.2020. 19:49 ] @
Tesko da imaju kad ima i samo 2 upstreama.

Ako se nastavi, bez zezanja, juri tier 3 ili novi modem.

U medjuvremenu, kad imas te probleme, utakni direkt kabl iz modema u PC, cisto da vidis kako ce to da se ponasa. Da ne bude posle "tvoja infrastruktura je problem".
[ Living Light @ 04.09.2020. 00:16 ] @
Citat:
Zlatni_bg: To sto si ti Robi opisao meni vise deluje ili kao da su uredjaji stariji (browseri rade losije a danas su web sajtovi ultra teski) ili kao da nemas dobro DNS kesiranje kod provajdera.

Zlatni, hvala ti za ovo.
2 laptopa, jedan oko 6-7 god, drugi oko 3-4 god star.

I ni jedan ne moze preko 100 da prima, preko kabla.
Ne mogu da verujem, da ni ovaj manje star dell, to ne moze,
ali tako je, osim ako me ovi iz "kablovske" ne lage.

Ali dok otvore sranicu, mecku da rodis.
Kasnije radi do 100-ke.




[ Branimir Maksimovic @ 04.09.2020. 05:14 ] @
Living koji ti je setup? Tvoj ruter vezan na njihov? Najverovatnije imas cat5 kablove koji ne mogu preko 100mb/s.

edit:
moguce i da taj ruter ne moze brze od 100mb uz kablove.
[ Milan Kragujevic @ 04.09.2020. 15:52 ] @
Pa moguće je i da laptop nema GigE port, ima ih dosta u jeftinijoj klasi, stave 802.11ac WiFi i 100 Mbps ethernet jer eto... ušteda od manje od dinar. Ja npr. imam neki Lenovo IdeaPad i imao sam još 2 prethodnih godina, koji ima 100 Mbps Ethernet, kupljen pre 2 godine, i znam za HP laptopove koji već 7-8 godina dolaze samo sa 100 Mbps ethernet-om, od skoro imaju AC WiFi. Lako je testirati sa fabričkim kablićem sa 8 žica od metar i po, i laptop pravo u modem. Modem će upaliti narandžasto lampicu ako je 100 Mbps veza, a zeleno ako je 1 Gbps veza. Manje su šanse da je kabl, jedino ako je oštećen, ili ako ima samo 4 žice. Smatram da je do laptopa, da jednostavno nema gigabit ethernet.
[ Branimir Maksimovic @ 04.09.2020. 17:05 ] @
Meni je bio upravo kabl :)
Imao sam cat5 koji nije mogao da izvuce vise od 100, pa sam kupio dva kabla cat5e sve zbog tih 20mbps kojih imam viska iznad 100 ;)
[ calexx @ 05.09.2020. 17:16 ] @
Ja koristim kabl koji mi padne pod ruku a dužina odgovara, nikad ispod očekivane brzine. Jedino mi je ping očajan, uvek oko 1, retko pređe na dvojku.
[ Branimir Maksimovic @ 05.09.2020. 17:23 ] @
Nemas stare kablove onda. Ovi moji sigurno su stariji od 15 godina :P
[ Living Light @ 05.09.2020. 17:43 ] @
Citat:
Branimir Maksimovic: koji ti je setup? Tvoj ruter vezan na njihov? Najverovatnije imas cat5 kablove koji ne mogu preko 100mb/s.
edit:
moguce i da taj ruter ne moze brze od 100mb uz kablove.

Imam Hama kabl CAT-7, 8-metara.
A ono sto "blinka kao modem ili ruter" je ubee,
od SBB dobijen.

Imam placeno 150 brzinu, kod SBB (takav je paket).
Ali ne mogu da verujem da ako oba DELL laptopa ne mogu to,
(jel su tobože zastareli)
preko LAN kabla, )ajd ako su zastareli)
da ne moze ni Nokia-9 mob telefon na Wi-Fi?
(Jos nisam nasao kao da kacim MOB sa kablom na modem/ruter)

Placam bez veze, a ne ide iznad 100-ke.

Nemam pojma vise kome da se zalim, svi izbegavaju odgovor,
i resenje. (SBB-Konekcija)

Ranije dok sam imao "CISCO" modem/ruter,
ubijao je od signala na WI-Fi.
Onda dosli "pametni" iz SBB i promenili opremu na "napredniju".
Od tada ima prijem 3-4 (od 5) na Dell laptopu, na 3 metra od SBB uredjaja.
Ovo je da izludis sa SBB.
[ Branimir Maksimovic @ 05.09.2020. 17:53 ] @
Proveri kvalitet linije onda? Na tom ubee sve treba da gori zeleno. Bar kod mene tako, ako gori zuto/narandasto to znaci da je ogranicen
na 100mb.

disclaimer: nemam ubee
[ calexx @ 05.09.2020. 17:55 ] @
Citat:
Living Light: Imam placeno 150 brzinu, kod SBB (takav je paket).
Ali ne mogu da verujem da ako oba DELL laptopa ne mogu to,
(jel su tobože zastareli)
Da li sam propustio deo u kome si napisao koji su tačno modeli laptopova koje imaš? Ja imam jedan HP iz 2009. godine i ladno ima gigabitnu mrežu i mislim i 5G wireless.
[ Living Light @ 05.09.2020. 18:30 ] @
calexx, Branimir,

Niste nista propustili, jer ponavljam:
1) Laptop DELL 15", I3, Inspiron 5521-4085

2) Laptop DELL 17", I7,
Inspiron 17, series 5000
Evo i slike etikete:
[ calexx @ 05.09.2020. 19:24 ] @
Sa drugim bi i mogao da imaš neki pristojan wireless, na oba koliko vidim preko kabla do 100. Nije ti provajder kriv što imaš loš hardver. ;)
[ ademare @ 05.09.2020. 20:04 ] @
Jeste , evo sada sam i ja proverio , nijedan od ta dva modela preko kabla ne moze preko 100 .
[ Branimir Maksimovic @ 05.09.2020. 20:14 ] @
Ovaj drugi bar moze 5Ghz wireless :P
[ Living Light @ 05.09.2020. 20:14 ] @
E, da im ehhh___em 100 Maderborda :)
Pa sta da im radim?

Ne bi da ih pobacam, ipak su oba sa 16G RAM-a,
a mislim da nisu bas za kontejner.
[ Milan Kragujevic @ 05.09.2020. 21:21 ] @
Told ya.

Citat:
Milan Kragujevic:
Pa moguće je i da laptop nema GigE port, ima ih dosta u jeftinijoj klasi, stave 802.11ac WiFi i 100 Mbps ethernet jer eto... ušteda od manje od dinar.


Citat:
Living Light:
Pa sta da im radim?


Pređi na manji paket npr. EON LIGHT DUO :P
[ Branimir Maksimovic @ 07.09.2020. 02:15 ] @
Večeras je packet loss katastrofa na super novi počevši od pola 8 uveče u nedelju pa evo do sada. Sve živo se rekonektuje, pa do potpunog gubitka internet veze...

edit:
ping do modema je bez gubitka ispod 1ms, parametri idealni, ovo je nesto upstream.

[Ovu poruku je menjao Branimir Maksimovic dana 07.09.2020. u 03:30 GMT+1]

problem nastaje ovde:
~ >>> traceroute yahoo.com
traceroute to yahoo.com (98.137.11.163), 30 hops max, 60 byte packets
1 router.asus.com (192.168.101.1) 0.340 ms 0.299 ms *
2 10.175.31.254 (10.175.31.254) 5.089 ms 5.113 ms 5.148 ms ===> tu je packet loss


[Ovu poruku je menjao Branimir Maksimovic dana 07.09.2020. u 03:36 GMT+1]
[ Milan Kragujevic @ 07.09.2020. 03:11 ] @
Hvala ti što si uradio ping do modema. Mislim da u ovoj situaciji ne možeš ništa da uradiš, sem da zapišeš datum j vreme, sacuvaš screenshots, i da pošalješ mejl na [email protected] i prijaviš putem call centra paralelno. Međutim, upitno je da li oni išta mogu da urade da ti pomognu, tj. ako je preopterećenje CMTS-a (što verovatno jeste), jedino šta može da reši to je node split, tj. drastično smanjenje broja korisnika na CMTS-u dodavanjem još jednog, a to je velika investicija za malog politički-motivisanog provajdera. Barem ti ne Cisco kršina ispravna
[ Branimir Maksimovic @ 07.09.2020. 03:21 ] @
Problemi sa packet lossom su poceli skoro pre nedelju dana, tako da su ga bas preopteretili tada najverovatnije. Zalice se ljudi sigurno, posto ne verujem da sam ja jedini sa tim problemom.
Mislim ono ne mozes ni da streamujes ni da surfujes ko covek u vecerenjim satima....
[ Milan Kragujevic @ 07.09.2020. 03:33 ] @
E, tu ti je greška, kao što čuveni bakara kaže na čuvenom čmark forumu - ljudi misle da će se neko drugi žaliti ili da "oni vide da ne radi" - u realnosti, niko se ne žali, a "oni" to ne gledaju proaktivno jer ih mrzi. Mogu ali neće. Dakle, žali se ili će ti tako i ostati
[ Branimir Maksimovic @ 07.09.2020. 04:13 ] @
Sve u svemu, na supernovi imam više problema u godinu dana nego što sam imao na AVcomu u zadnjih 10 godina...
[ Branimir Maksimovic @ 07.09.2020. 04:18 ] @
A sad ne radi ni DHCP server...
[ Branimir Maksimovic @ 07.09.2020. 05:42 ] @
Tek se u pola 7 ujutro stabilizovalo, verovatno je neko dosao na posao i iskljucio tog lika sto torentuje :P
[ Living Light @ 07.09.2020. 12:16 ] @
Citat:
Branimir Maksimovic: Večeras je packet loss katastrofa ping do modema je bez gubitka ispod 1ms, parametri idealni, ovo je nesto upstream.

Nikada do sada nisam video ping od 1ms.

Pitanje je:
Ako odaberem grad, i usluzioca provere brzine i pinga,
kako da znam dokle to moze da ide, do koje brzine?
Verovatno su svi oni vezani na optiku.

Evo primera:


[ Milan Kragujevic @ 07.09.2020. 12:24 ] @
Ping je od računara do modema 1ms, dakle u okviru stana.
[ Living Light @ 07.09.2020. 12:36 ] @
A zar nije "PING" od mog laptopa do
Londona, New Yorka, Moskve ili nekog drugog grada?
[ Branimir Maksimovic @ 07.09.2020. 12:39 ] @
Ping je od racunara do racunara. Posalje se nesto do nekog racunara i taj racunar posalje odgovor u nekom vremenu. round trip vreme je ono sto zovemo ping.
[ Living Light @ 07.09.2020. 13:24 ] @
Da li to znaci da @Milan Kragujevic
nije u pravu?
Ili nesto gresim?
[ Branimir Maksimovic @ 07.09.2020. 13:29 ] @
U pravu je to je ping od mog racunara, do modema, u stanu. Prvi sledeci uredjaj mog ISP-a je vec 5 ms.
[ Living Light @ 07.09.2020. 13:40 ] @
Branimire,
Jasno!
Hvala na dodatnom komentaru.
pOz
[ calexx @ 07.09.2020. 17:01 ] @
Citat:
Living Light:
A zar nije "PING" od mog laptopa do
Londona, New Yorka, Moskve ili nekog drugog grada?
Ono što mnogi neće da shvate, ping ne može da bude isti (u idealnom slučaju, naravno) do ISP-a, do Londona, do Moskve ili bilo gde. Pa se pitaju kako im je ping do eleja 180 a hteli bi da bude do deset.
Citat:
Living Light:Nikada do sada nisam video ping od 1ms.
For Your Eyes Only:



Hm, zakidaju me na brzini, trebalo bi da bude 320/100 a vidi njih šta rade. :)
[ Milan Kragujevic @ 07.09.2020. 17:13 ] @
@Living Light: protip - Milan Kragujević je uvek u pravu, barem kad su provajderi i modemi u pitanju

Moj odgovor se odnosio na Branimirov rezultat, a njegov rezultat je bio odgovor na moj zahtev da pinguje modem kad se desi problem da vidimo da li je problem do modema / kućne mreže ili izvan granica korisnikove odgovornosti.
[ Branimir Maksimovic @ 07.09.2020. 17:17 ] @
Citat:
calexx:
Citat:
Living Light:
A zar nije "PING" od mog laptopa do
Londona, New Yorka, Moskve ili nekog drugog grada?
Ono što mnogi neće da shvate, ping ne može da bude isti (u idealnom slučaju, naravno) do ISP-a, do Londona, do Moskve ili bilo gde. Pa se pitaju kako im je ping do eleja 180 a hteli bi da bude do deset.
Citat:
Living Light:Nikada do sada nisam video ping od 1ms.
For Your Eyes Only:



Hm, zakidaju me na brzini, trebalo bi da bude 320/100 a vidi njih šta rade. :)


Ma pusti ti te fore do Niša, kolki ti je ping do yahoo. com :)?
[ DynDNS @ 07.09.2020. 17:24 ] @
Pa proveri ping od provajdera do tog hosta na internetu ako prvajdera ima tu opciju.

SBB i telekom je imaju
[ calexx @ 07.09.2020. 18:09 ] @
Citat:
Branimir Maksimovic:Ma pusti ti te fore do Niša, kolki ti je ping do yahoo. com :)?
Kakve fore? Ako je sedište Yahoo u Kaliforniji, evo koliko je do SF.



Ipak, ping do yahoo.com je malo manji, deluje mi da je negde na istočnoj obali.
Citat:
ping yahoo.com
PING yahoo.com (74.6.143.26) 56(84) bytes of data.
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=1 ttl=48 time=115 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=2 ttl=48 time=116 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=3 ttl=48 time=115 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=4 ttl=48 time=116 ms
64 bytes from media-router-fp74.prod.media.vip.bf1.yahoo.com (74.6.143.26): icmp_seq=5 ttl=48 time=116 ms

--- yahoo.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 115.318/115.530/115.735/0.133 ms

Ako probam britansku varijantu, tu bi možda moglo da bude malo manje ali više pokušaja daje šarene rezultate.
Citat:
ping yahoo.co.uk
PING yahoo.co.uk (87.248.100.208) 56(84) bytes of data.
64 bytes from media-router-ui71.prod.media.vip.ir2.yahoo.com (87.248.100.208): icmp_seq=1 ttl=48 time=47.8 ms
64 bytes from media-router-ui71.prod.media.vip.ir2.yahoo.com (87.248.100.208): icmp_seq=2 ttl=48 time=48.1 ms
64 bytes from media-router-ui71.prod.media.vip.ir2.yahoo.com (87.248.100.208): icmp_seq=3 ttl=48 time=47.9 ms
64 bytes from media-router-ui71.prod.media.vip.ir2.yahoo.com (87.248.100.208): icmp_seq=4 ttl=48 time=48.2 ms
64 bytes from media-router-ui71.prod.media.vip.ir2.yahoo.com (87.248.100.208): icmp_seq=5 ttl=48 time=48.2 ms

--- yahoo.co.uk ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 47.849/48.062/48.214/0.144 ms


Ili misliš da bi do yahoo mogao da imam ping 1, 2 ili 10ms??
[ DynDNS @ 07.09.2020. 18:15 ] @
Serbia BroadBand

Router: Beograd
Command: ping Yahoo.com


PING yahoo.com (74.6.143.26) 56(84) bytes of data.

--- yahoo.com ping statistics ---
25 packets transmitted, 25 received, 0% packet loss, time 2868ms
rtt min/avg/max/mdev = 117.473/117.559/117.713/0.365 ms, ipg/ewma 119.520/117.562 ms
bg-du-r-lg#
[ calexx @ 07.09.2020. 18:28 ] @
Ili prostije rečeno, to je ping od provajdera do neke adrese i onda dodaš svoj ping do provajdera. Zato ja gledam samo ovaj od mene do provajdera a dalje je njihov problem.
[ Branimir Maksimovic @ 07.09.2020. 18:39 ] @
calexx, poenta je da je isti i kod tebe i kod mene jer koristimo istu infrastrukturu. Međutim nekad bude problema na nekom čvorištu, pa ping bude veći...
[ Branimir Maksimovic @ 07.09.2020. 19:10 ] @
Ahem kao po komandi kao i juče supernova internet je prestala da radi u pola 8. E sad, ako se budem žalio doneće
mi drugi ruter koji neću moći u bridge
mod, pa ću osim ovih problema imati
i problem sa duplim natom. Šta ću ako
ovo potraje moraću da pređem na sbb, kojeg
takođe imam u zgradi...
[ calexx @ 07.09.2020. 19:35 ] @
Citat:
Branimir Maksimovic:calexx, poenta je da je isti i kod tebe i kod mene jer koristimo istu infrastrukturu. Međutim nekad bude problema na nekom čvorištu, pa ping bude veći...
Pa da, onda skače ping od tebe do provajdera ili je od početka veliki i tu je problem. Zato i merim od mene do provajdera i tako vidim da li negde koči a kako je od provajdera do belog sveta je za drugu priču. Ako je u prvom delu, onda pogledam ovde a onda tražim da provajder pogleda dalje. Koliko je od njega do yahu servera mi ne znači mnogo.
[ Milan Kragujevic @ 07.09.2020. 19:49 ] @
Branimire, Supernova stavlja DOCSIS Voice Gateway u bridge mode korisnicima na zahtev. Meni su, kad sam na Ledinama najdražim imao divno zadovoljstvo da koristim raspalu analognu Vektor mrežu sa 8/1 kanala na paketu 120/15 Mbps.
[ Branimir Maksimovic @ 07.09.2020. 19:51 ] @
Citat:
calexx:
Citat:
Branimir Maksimovic:calexx, poenta je da je isti i kod tebe i kod mene jer koristimo istu infrastrukturu. Međutim nekad bude problema na nekom čvorištu, pa ping bude veći...
Pa da, onda skače ping od tebe do provajdera ili je od početka veliki i tu je problem. Zato i merim od mene do provajdera i tako vidim da li negde koči a kako je od provajdera do belog sveta je za drugu priču. Ako je u prvom delu, onda pogledam ovde a onda tražim da provajder pogleda dalje. Koliko je od njega do yahu servera mi ne znači mnogo.


Nekad nije problem provajder...
[ Branimir Maksimovic @ 07.09.2020. 19:52 ] @
Citat:
Milan Kragujevic:
Branimire, Supernova stavlja DOCSIS Voice Gateway u bridge mode korisnicima na zahtev. Meni su, kad sam na Ledinama najdražim imao divno zadovoljstvo da koristim raspalu analognu Vektor mrežu sa 8/1 kanala na paketu 120/15 Mbps.


Hvala na info. Trenutno je packet loss samo 25% ;)
[ Milan Kragujevic @ 07.09.2020. 20:04 ] @
Divim se tvom strpljenju. Iskreno.
[ Branimir Maksimovic @ 07.09.2020. 20:07 ] @
A sta da radim nikada ali nikada AVcom nije priznao da je kvar sa njihove strane. De ce onda ovi? Znaci dokle god u pola 8 nesto
prckaju sa netom moram da trpim, jer ovo nije prvi put :P
Kazem jednom u 2 meseca ima slicnih problema, kad god nesto zezaju na infrastrukturi....
[ Milan Kragujevic @ 07.09.2020. 20:20 ] @
Možda spremaju node split i čuveno unapređenje ponude Internet paketa na DOCSIS mreži, nakon integracije u Kopernikus Technology DOO Novi Beograd, a pre preimenovanja u Moja Supernova d.o.o. ?
[ Milan Kragujevic @ 08.09.2020. 09:16 ] @
Ako ti je lakše, Supernova niti priznaje niti ne-priznaje, ili će popraviti ili ne, dakle nemaš baš puno da izugbiš ako pošalješ mejl. Možda će ti dati čuveni Technicolor TC7210 On ima duplo veći downstream kapacitet, pa može izbeći te probleme ako ti dodele nove DOCSIS kanale koji imaju manje smetnji i zauzeća.

Generalno radove na mreži obavljaju posle ponoći, ovo mi liči na obično zauzeće mreže, gde će više kanala pomoći, pošto tih 53 Mb/s po kanalu deliš sa svim korisnicima, pa onda ide "što više kanala to stabilniji net", i ako u "teoriji" bi mogao da "guraš" 120 Mbps sa 3 kanala, a u praksi nema šanse ni u ludilu.

Sada mogu prvo da ti promene dodeljene DOCSIS kanale, daljinski, što može da reši ili da znatno ublaži probleme, ako imaju dostupno npr. 20 kanala, i dodele ti poslednjih 8 sa spiska koje dobijaju korisnici sa tim "naprednijim" modemima, a kojih možda ima jako malo na tvom CMTS-u. Ako ni to ne pomogne, onda mogu da ti daju novi modem sa više kanala, što će skoro sigurno rešiti problem.

Mada, opet, negde ni to ne može, viđao sam po manjim gradovima u Srbiji kod SBB-a, gde imaju analognu TV još, da ni 100 Mbps neće da radi sa 16 ili 20 Downstream kanala, a 20 DS kanala daje 1000 Mbps teoretskog protoka, dakle 10x više od "tražene brzine".

Tu su problem RF smetnje, dešava se da se modem restartuje predveče jer izgubi sinhronizaciju sa CMTS-om od "šuma", i kod tih korisnika oni čak iz call centra vide da se dešavaju smetnje i da se modem restartuje više puta dnevno.

Onda ja kažem korisniku da traži novi modem, dobije novi modem, bilo EVW32c ili CGA2121, i bude isto. I onda još jednom novi modem - isto. I onda dignem ruke i kažem "to nam je što nam je, preseli se u BG - biće bolje "

Svakako, sam ništa ne možeš da rešiš, niti imaš uvid u statistike i logove sa CMTS-a, a oni to mogu.

Piši @djricky DM, možda može da pomogne da tvoj tiket dođe do pravog nivoa. Ako mu pišeš, ponuda piva za L3 podršku više ne važi, to se računa kao "preko veze".
[ Branimir Maksimovic @ 08.09.2020. 09:27 ] @
Milan:"Generalno radove na mreži obavljaju posle ponoći, ovo mi liči na obično zauzeće mreže,"

Ne lici na zauzece. Zauzece je i pocelo ovaj thread, a ispoljavalo se povecanim pingom ne i packet lossom.
Ovde je upravo suprotno normalan ping a veliki packet loss. Ne deluje uopste da je zauzece veliko kao u martu recimo.
I to sto pocinje tacno u pola 8, sto sam juce i prekjuce primetio. Zauzece nema tako fiksan timing.
I to sto nista ne diram samo ujutro sve nastavi normalno da radi niti moram da resetujem modem.
[ Milan Kragujevic @ 08.09.2020. 09:42 ] @
Ne verujem da bi baš u pola 8 radili održavanje, pa to je glupost.

Može da bude zauzeće i kod packet loss-a, video sam takav slučaj u Kostolcu na SBB-u, "napredna" terenska podrška inače toleriše do 30% packet loss(!!), što je suludo - to sam im i rekao. Isto je nastupalo uveče, nije se ni rešilo.

Ping i packet loss određuju smetnje, kada dođe do grešaka koje se mogu korigovati, ping se poveća jer dolazi do više retransmisija data paketa (na DOCSIS sloju), ali, ako DOCSIS data paket ne uspe da bude retransmitovan dovoljno brzo, dolazi do gubitka TCP paketa. Te smetnje može da izaziva "šum" - RF ili električne smetnje, ali može da izazove i prevelika upotreba koja "zagušuje" CMTS sa saobraćajem ili dolazi do gubitka sinhronizacije TDMA slotova većeg broja modema usled većeg saobraćaja na lokalnoj grani, pa onda CMTS ne može da stigne da priča sa svima njima + da im koriguje multiplex slotove za upstream.

Svejedno, neverovatno mi je da uveče rade održavanje. Prvo, valjda niko ne želi da ima posla uveče, kad je najveće zauzeće, drugo - valjda rade od 9 do 17h ili eventualno 7 do 15h, pa im je lakše da to rade kad su na poslu, a ako baš hoće da rade posle podne, onda neka rade posle ponoći - manje smetanja korisnicima, jer spavaju. Nikako mi se ne uklapa da uveče rade bilo šta...
[ Branimir Maksimovic @ 08.09.2020. 09:47 ] @
Pazi, ko po komandi ujutro znaci od 2- prekjuce tacno u pola 7,prestaje packet loss, ping savrsen, internet savrsen i tako sve do pola 8 uvece.
[ Zlatni_bg @ 08.09.2020. 13:48 ] @
Tamo 2008, sam presao na SBB. Iste godine nisam imao puno vremena da provodim pored racunara pa mi nije bilo bitno, ali malo ljudi zna, da ta poslednja 3-4 meseca koja sam bio na AVComu, internet nisam imao u 90% vremena. Ne znam tacno sta je bio problem ali maltene nijednu stranicu nisam mogao da otvorim. Prijavio sam 2 puta kvarove, nikad nista nisu uradili.

Moj savet, kao sto sam ja radio sa SBB-om u slicnom slucaju, imam otvorenu temu na ESu o tome... skupljao sam dokumentaciju o problemu jedno mesec dana. Koristio PingPlotter ili kako se vec zove, radio traceroutove u svako doba dana, sve belezio, screenshotovao... e onda sam se javio SBBu, rekao podrsci da cu da im posaljem sve to na mail, posle 5-6 dana me zove tier 3 tehnicka podrska da radimo neke testove ako sam kod kuce. Tad su i oni skapirali da se nesto desava, 2-3x su izlazili na teren da rade na infrastrukturi zgrade zbog toga, ja sam insistirao da hocu modem a ne ruter, dobio sam sve sto sam hteo, uzeo AC58U, i resili smo probleme.

Nisam siguran da znas sta sve mozes da uradis, ali po ugovoru, ovako nesto nije dopustivo jer tebi usluga nije isporucena na bilo kakvom kvalitetnom nivou i imas svako pravo da se zalis.

Skupljaj polako dokumentaciju oko tih problema, i onda ih zvekni sa mesec dana materijala ako se ne resi problem i pritiskaj na sve moguce nacine bez kompromisa. Nije vise 2000. godina, imamo svi drugih opcija. Mozda sad kako-tako tolerises problem ali jednom ima da ti prekipi, uzmi da igras bilo koju online igricu i videces kakve muke ti pravi to. VOIP takodje, bukvalno nista sem browsinga ne mozes da koristis, sve sto trazi handshake ima da vristi takodje...
[ Milan86 @ 08.09.2020. 19:33 ] @
SBB, EON FULL DUO (150/15), Technicolor CGA2121:



Mreza uradjena kompletno od nule. Pre toga katastrofa (packet loss, prekidi), zato sam jedno vreme koristio VDSL.
[ Milan Kragujevic @ 08.09.2020. 19:43 ] @
Meni je ping na VDSL 5ms ma serverima u Srbiji.
[ Milan86 @ 08.09.2020. 19:56 ] @
I meni je bio 4-5ms ka serverima u Srbiji. Imao sam VDSL 100/10, fast profil.
[ Branimir Maksimovic @ 08.09.2020. 19:56 ] @
Zlatni:"Mozda sad kako-tako tolerises problem ali jednom ima da ti prekipi, uzmi da igras bilo koju online igricu i videces kakve muke ti pravi to"

Tolerisacu jos neko vreme a onda cu se zaliti, posto mislim da ovo moze da potraje jos samo par dana. Mislim nije problem 0-24 nego od 19:30-pa najdalje do 6:30
[ Milan Kragujevic @ 08.09.2020. 20:02 ] @
@Milan86 ma može i na 20/2 Mbps (linija suviše krš za 20/4 Mbps), bitno je da se bira brzina u skladu sa mogućnostima a ne željama, i naravno Fast profil, TX power 14 dBm, i BBTF fiksni da ne pravi smetnje.

@Branimir
Citat:
Milan Kragujevic:
Divim se tvom strpljenju. Iskreno.

[ Milan86 @ 08.09.2020. 20:17 ] @
@Milan Kragujevic

Upravo sam odradio jedan tracert ka Facebook-u i uocio sam da je prvi hop posle mog rutera 10.10.0.1. To je adresa iz privatnog opsega. Ruter inace dobija IP adresu iz javnog opsega (178.148.x.y).



Sta bi to moglo biti? :) Malo me buni 10.10.0.1.
[ Milan Kragujevic @ 08.09.2020. 20:24 ] @
@Milan86 to im je CMTS, može biti na bilo kojoj IP adresi. Generalno 100.x.x.x je CGNAT za korisnika, 10.x.x.x je interna mreža operatera, 192.168.x.x je interna mreža korisnika, pa se ovde sve uklapa.



Meni je sledeći hop 10.255.255.1 jer je to terminal server u mojoj kućnoj mreži, dalje od toga ide ruter provajdera i onda prelazi u Facebook preko SOX-a.
[ Branimir Maksimovic @ 09.09.2020. 04:05 ] @
Citat:
Milan Kragujevic:
@Branimir
Citat:
Milan Kragujevic:
Divim se tvom strpljenju. Iskreno.



Pa ono imam net, ali kljakav uvece, nije bas da sam na ivici zivaca...
[ Branimir Maksimovic @ 09.09.2020. 04:22 ] @
Do CMTS-a gde je problem:
Code:

--- 10.175.31.254 ping statistics ---
100 packets transmitted, 55 received, 45% packet loss, time 99773ms
rtt min/avg/max/mdev = 3.863/9.247/58.979/8.699 ms


Nesto opasno prckaju, pretpostavljam da ce volsebno problemi da prestanu oko pola 7.
Mislim ono meni internet znaci u toku dana, jer tad radim, uvece ovo i ne smeta toliko.
No ako se ovo produzi, do petka razmisljam da predjem na SBB. Sa njima da se
ubedjujem ne pada mi napamet.
[ Branimir Maksimovic @ 09.09.2020. 04:34 ] @
Zlatni:"Tamo 2008, sam presao na SBB. Iste godine nisam imao puno vremena da provodim pored racunara pa mi nije bilo bitno, ali malo ljudi zna, da ta poslednja 3-4 meseca koja sam bio na AVComu, internet nisam imao u 90% vremena. Ne znam tacno sta je bio problem ali maltene nijednu stranicu nisam mogao da otvorim. Prijavio sam 2 puta kvarove, nikad nista nisu uradili."

Ovo je interesantno, sa AVcomom uopste nisam imao problema, jedino sam se iznervirao kad mi je crkao modem, pa sam cekao 3 dana da posalju decka da donese novi. Inace problema sa njihove strane sam imao jedino kada su povecavali brzine, i to
odmah nakon sto se sredi ide veca brzina i ja zadovoljan ;)

[ Branimir Maksimovic @ 09.09.2020. 05:16 ] @
Evo ga tacno u 6:15 je proradio normalno. U prilog tome da su u pitanju radovi je i to da upload *uoste ne radi* ne mogu da posaljem megabajt workload-a za WCG!!!

edit:
i evo ga do CMTS-a nakon 6:15
Code:

--- 10.175.31.254 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99118ms
rtt min/avg/max/mdev = 3.980/5.287/18.322/1.840 ms



[Ovu poruku je menjao Branimir Maksimovic dana 09.09.2020. u 06:51 GMT+1]
[ Milan Kragujevic @ 09.09.2020. 08:41 ] @
Citat:
Branimir Maksimovic:
Citat:
Milan Kragujevic:
@Branimir
Citat:
Milan Kragujevic:
Divim se tvom strpljenju. Iskreno.



Pa ono imam net, ali kljakav uvece, nije bas da sam na ivici zivaca...


Pa dobro, ja uveče imam razgovore i tad mi najviše smetaju problemi. Obično se mrcvarim sa Skajpovima do ponoći i onda posle ponoći bude OK.

Iskreno,

Pre podne mi stabilan net treba samo od 09 do 10h za sastanke i četvrtkom dodatno od 13h do 16h. Ovo ostalo se da preživeti.

Inače sada nemam problema, od kako hibridiram DSL+LTE, pošto je DSL jel'te dedicated link koji sebično ne delim sa drugim korisnicima, a sama DSL centrala (mislim na zgradetinu gde ima živih ljudi, ne ormarić pored puta) je na 550 metara od moje zgrade.



E, sad, da sam 80 metara bliže, i da nije parica totalni raspad, moglo bi i 100 Mbps da se pusti direktno, ovako ništa. U sistemu im piše da može, ali kad se pusti onda shvate da ne može, tako da sam na 50/8 Mbps i hibridiram još toliko (naravno DIY hibrid, Telekom neće da da modem - kažu "ne treba vam, možete običan VDSL").




@Branimir jel si dobio CGNAT, promenila ti se IP adresa na 87.250.59.0/24, pre je bilo 109.72.51.0/24.

Inače, prebaciće sve korisnike na *Super pakete, počeli su sa Radijus Vektor / Masko+Citadela korisnicima, ali verujem da će uskoro i ostali doći na red.

Ako slučajno budu korisnike "upgrade"-ovali na veće brzine nego što imaju (tipa ako se ne uklapaju u 60 Mbps pa ih prebace na 120 Mbps, ili nedajbože 350 Mbps) očekujem raspad mreže, mada ne znam koje pakete je AVCom imao pre i koliko procentualno korisnika sada ima manju brzinu od 120 Mbps a veću od 60 Mbps.

Inače, skok potrošnje neta sa tipa 60 Mbps na 120 Mbps je mnogo veći nego sa 300 Mbps na 500 Mbps kao SBB kad je GIGA-izovao Beograd u martu ove godine. Korisnici generalno "troše isto", neće neko magično trošiti 200 Mbps više non-stop. Ali, ako je net dovoljno spor, da dolazi do zagušenja kućne mreže, npr. neko download-uje nešto a nekome drugom ne radi YouTube, itd., pa taj neko drugi čeka prvog, itd. U tim situacijama, kada brzina skoči, korisnici u domaćinstvu će paralelizovati pristup, i istovremeno će se koristiti više online servisa, što će povećati "osnovnu" upotrebu Interneta.




Iskreno ne bih kablovski net koristio nikad kao primarni internet, to je toliko loša stvar, toliko lag-uje za VoIP, užas prosto. Modemi su krš po pravilu, pa mi treba i moj ruter, a onda provajder neće u bridge nego DMZ, pa onda imam problem ako se modem zaglupi jer DMZ ne radi, itd.

Strašno mi je to da net crkava svako veče i da niko ne može ništa da uradi da pomogne - a realno u 90% slučajeva ne mogu, to zahteva velike investicije, i provajderi to ne žele da urade. Ako ih pritisneš, samo ti odobre raskid bez naknade štete, jer oni znaju za problem ali neće ništa da menjaju.

Mislim, koliko je realno očekivati da npr. SBB promeni kabl od CMTS-a udaljenog 5 ulica dalje, preko krovova svih zgrada, do tvoje zgrade, i onda kroz tvoju zgradu do tebe? I to u kratkom roku od npr. mesec dana, a ne godinu-dve tj. "nemamo rok, kolege konstantno rade na unapređenju mreže".

Ovo nije kritika jednog provajdera, generalno je tako. Nakon što sam ih sve probao kroz moje brojne selidbe, zaključio sam da je DOCSIS zlo i da to meni ne treba u životu. Previše bespotrebne nervoze.

DSL+LTE mi je najbolje rešenje iskreno, DSL daje stabilnu brzinu, nizak ping i kvalitetnu vezu, a LTE daje boost kada ruter primeti da je potražnja neta veća od DSL-a. Ako dođe do prekida DSL-a, LTE preuzima kapacitet linka do maksimalne moguće brzine, a kada se DSL vrati, re-aktivira se bondovan interfejs. Nema prekida, mogu npr. da pričam na Skype, ugasim DSL modem i ne dođe do prekida ni na sekundu (ono Reconnecting...), niti se audio/video stream zamrzne, niti se jedan frame izgubi. Samo bude kašnjenje delić sekunde dok se rerutiraju paketi, pa sagovornik to vidi kao ubrzan audio i video.

Koga zanima hibridna tehnologija, evo tutoriala na mom blogu (na engleskom)
[ Branimir Maksimovic @ 09.09.2020. 08:54 ] @
Milan:"@Branimir jel si dobio CGNAT, promenila ti se IP adresa na 87.250.59.0/24, pre je bilo 109.72.51.0/24."

Ma jok, promenio mac adresu na ruteru ;)
Dosadila mi jedna ista adresa 2 godine :P
Mislim ono mogu da promenim adresu kad god promenim adresu rutera...

"
Iskreno,

Pre podne mi stabilan net treba samo od 09 do 10h za sastanke i četvrtkom dodatno od 13h do 16h. Ovo ostalo se da preživeti.
"

Meni treba u toku dana kada radim od kuce, a radim od kuce 2 dana u nedelji.
[ Branimir Maksimovic @ 09.09.2020. 20:41 ] @
Danas su poceli nesto ranije ali je izgleda zavrseno. Do 9 se stabilizovalo nakon sto je nekoliko puta nestajao net i tv ujedno.
[ Branimir Maksimovic @ 10.09.2020. 03:49 ] @
Oh kako je lepo kad mozes da surfujes ko covek u nocnim satima :P

Code:

--- 10.175.31.254 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99138ms
rtt min/avg/max/mdev = 3.921/6.816/27.326/3.919 ms


ping do CMTS-a je porpilican, i devijacija je veca, a to je verovatno vazdusnom par stotina metara odavde,
ali sam ipak zadovoljan :P

modem:
Code:

~ >>> ping -c 10 192.168.100.1                                                                                                                                                                                               
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=0.930 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.732 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=63 time=0.625 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=63 time=0.687 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=63 time=0.722 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=63 time=0.686 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=63 time=0.666 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=63 time=0.631 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=63 time=0.681 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=63 time=0.642 ms

--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9119ms
rtt min/avg/max/mdev = 0.625/0.700/0.930/0.083 ms


Znaci ima kise u kablovima :P
[ Branimir Maksimovic @ 12.09.2020. 19:01 ] @
Evo zagusenja:
Code:

--- 10.175.31.254 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99077ms
rtt min/avg/max/mdev = 7.627/117.616/291.985/79.557 ms


Znaci nakon sto su skoro dve nedelje nesto prckali pa skoro da nisam imao net, evo je stara boljka sa zagusenjem CMTS-a ;)

Do modema je savrseno:
Code:

~/projects/mf-install >>> ping -c 10 192.168.100.1                                                                                                                                                            ±[master]
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=63 time=0.809 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=63 time=0.765 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=63 time=0.708 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=63 time=0.638 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=63 time=0.651 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=63 time=0.709 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=63 time=0.629 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=63 time=0.648 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=63 time=0.665 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=63 time=0.646 ms

--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9117ms
rtt min/avg/max/mdev = 0.629/0.686/0.809/0.057 ms


[ Milan Kragujevic @ 12.09.2020. 19:32 ] @
I, ćeš na SjBB ili?
[ Branimir Maksimovic @ 12.09.2020. 19:36 ] @
Milan: "I, ćeš na SjBB ili?"

Rekao sam ako do petka ne srede situaciju, sredili su do srede, dva dana premasili rok :P

Ovo sa pingom ni ne primecujem da nesto smeta :P
Mislim ono sve dok mogu da surfujem i slusam radio te povremeno skidam apdejte meni ne smeta ;)