γενικό πρόβλημα με το internet?

[minas]

Υπάρχει και το winmtr

[GregoirX23]

Άρα αν έχω καταλάβει καλά είναι για θέμα φόρτου/απασχόλησης του ρουτερ (όπως αναφέρθηκε) σχετικά με το να απαντήσει..
Κατά τα άλλα η συγκεκριμένη διασύνδεση θα λειτουργεί κανονικά.. Σωστά;

https://superuser.com/questions/1044...at-tcp-and-udp

[dimangelid]

Υπάρχει και το winmtr

Το winmtr δεν κάνει mtr με TCP.

[minas]

Το winmtr δεν κάνει mtr με TCP.

Σωστός, είχα καιρό να το χρησιμοποιήσω και δεν το θυμόμουν.
Υπάρχει και το tcping βέβαια, αλλά είναι προτιμότερο ένα πιο δυνατό εργαλείο που τα κάνει όλα...

[SfH]

Δηλαδή είναι καθαρά θέμα resources H load για τον ρούτερ Η και θέμα χωρητικότητας μιας διασύνδεσης; Περιορισμού της ταχύτητας αν το λέω και με καταλαβαίνετε καλά...
Έχει να κάνει και με qos H traffic shaping αυτή η τακτική; Η είναι άλλο πράγμα; Είναι δηλαδή καθαρά και μόνο για τον ρούτερ που αναφέρθηκε;

Πολύ γενικά. Οι routers που έχουν οι πάροχοι έχουν διάφορους πόρους, συνήθως σε κάποιο ιεραρχικό configuration. Ένα τυπικό παράδειγμα είναι να έχουμε κάποιες διεργασίες που γίνονται στα chips ( συνήθως ASICS ) που είναι κοντά στα ίδια τα ports ( συνήθως ανά port ή port block, ανάλογα με την αρχιτεκτονική ), κάποιες που γίνονται σε κάποιο πιο κεντρικό chip ανά linecard και κάποιες που γίνονται σε ακόμα πιο κεντρικό chip ( συνήθως ARM ή x86_64 ) που τρέχει διεργασίες που αφορούν όλο το μηχάνημα. Αρμόδιο για τη διαδικασία της δημιουργίας των icmp unreachables ( με τα οποία δουλεύει το traceroute ) είναι το τρίτο, που θα το βαφτίσουμε RP. Συνήθως υπάρχουν 2 bottlenecks. Το ένα είναι το διαθέσιμο bandwidth από τις άλλες linecards προς τον RP - που συνήθως είναι πολύ μικρότερο από αυτό που έχουν οι linecards μεταξύ τους - και αν γεμίσει, ο router είναι πρακτικά άχρηστος. Το δεύτερο είναι η ίδια η ικανότητα του RP να επεξεργάζεται. Παραδοσιακά, ο RP είχε ότι φτηνότερο πρακτικά υπήρχε από διαθέσιμες CPU. Πρόσφατα έχουν αρχίσει και βάζουν λίγο καλύτερα μοντέλα, αλλά μη φανταστείς ότι μιλάμε για τίποτα ιδιαίτερα ισχυρό σε σχέση π.χ. με έναν τυπικό server cpu. Ο RP λοιπόν τρέχει διάφορα πράγματα που αφορούν όλο το μηχάνημα, από ARP/ND resolution, management / telemetry μέχρι routing protocols, και μερικά από αυτά ( π.χ. το BGP ), είναι αρκετά βαριά για αδύναμους RP. Αν λοιπόν κάποιος αναγκάσει τον RP να απασχολείται με κάτι άλλο, πάλι θα δημιουργήσουμε πρόβλημα στη λειτουργία του μηχανήματος. Συνήθως λοιπόν υπάρχουν κάποια όρια recommended από τους κατασκευαστές, για να εξασφαλίσουν την ορθή λειτουργία. Αρκετές φορές αυτά μάλιστα είναι ενεργοποιημένα by default. Για να έχεις μια ιδέα σχετικά με την κλίμακα, τυπικά values για icmp πακέτα είναι 64kbps ή/και 300pps, ακόμα και για μηχανήματα που έχουν forwarding capacity κάμποσα tbps. Αυτό όμως δεν επηρεάζει τα πακέτα που περνάνε μέσα από τον ίδιο τον router, μόνο τα icmp unreachables που πρέπει να φτιάξει ο ίδιος ο router. Για αυτό το λόγο, θεωρείται ανούσιο να εξετάζουμε packet loss σε συγκεκριμένα hops εκτός αν υπάρχει σταθερό packet loss σε όλα τα hops από ένα σημείο μέχρι και τον τελικό προορισμό.

[globalnoise]

Off Topic

Το adslgr έχει τεράστια ανάγκη από reactions / like system

[BlueChris]

Off Topic

Το adslgr έχει τεράστια ανάγκη από reactions / like system

Off Topic

Συμφωνώ.

[leasedline]

respect

[alexisnik199111]

εχει παρατηρησει κανεις αλλος προβλημε με vodafone γυρω απο την περιοχη της πατρας? απο καμπινα μιλαω

παραπολλα λαθη μαζευονται και κανεις αποσυγχρονθσμους και πολλες φορες κοβεται η ip μονο isp timeout χωρις να επανερχεται χωρις restart.

[kmpatra]

Σε ποια περιοχή αναφέρεσαι? Εγώ Σκαγιοπούλειο από τότε που έκανα την 100αρα εχω πολλά λάθη (crc & fec) και κατά διαστήματα μαζεμενες αποσυνδέσεις ενώ η καμπίνα ειναι λιγοτερο από 100μ. (Attenuation 0/3,5). Ο συγχρονισμός ανεβοκατεβαίνει απο 65-105 χωρίς αποσυνδεση συνήθως. Οταν ξεμπλεξω με κάτι θέματα που εχω θα μιλησω μαζί τους. Χτες μου εκανε πρωτη φορα αυτο που λες μαλλον: ενω φαινονταν ολα τα λαμπακια αναμμένα και συγχρονισμένο,δεν είχε ip. Ξεκόλλησε με restart μόνο. Και μέχρι τώρα είναι σταθερό(μέχρι να ξαναχαλάσει)
Στο μεταξύ αν τυχον παρεις 13840 κανει ελεγχο το bot επι τόπου και τα βλέπει όλα καλά εστω και αν πεις οτι εχεις συχνες αποσυνδέσεις. Οτι να'ναι.

[globalnoise]

εχει παρατηρησει κανεις αλλος προβλημε με vodafone γυρω απο την περιοχη της πατρας? απο καμπινα μιλαω

παραπολλα λαθη μαζευονται και κανεις αποσυγχρονθσμους και πολλες φορες κοβεται η ip μονο isp timeout χωρις να επανερχεται χωρις restart.

Σε ποια περιοχή αναφέρεσαι? Εγώ Σκαγιοπούλειο από τότε που έκανα την 100αρα εχω πολλά λάθη (crc & fec) και κατά διαστήματα μαζεμενες αποσυνδέσεις ενώ η καμπίνα ειναι λιγοτερο από 100μ. (Attenuation 0/3,5). Ο συγχρονισμός ανεβοκατεβαίνει απο 65-105 χωρίς αποσυνδεση συνήθως. Οταν ξεμπλεξω με κάτι θέματα που εχω θα μιλησω μαζί τους. Χτες μου εκανε πρωτη φορα αυτο που λες μαλλον: ενω φαινονταν ολα τα λαμπακια αναμέννα και συγχρονισμένο,δεν είχε ip. Ξεκόλλησε με restart μόνο. Και μέχρι τώρα είναι σταθερό(μέχρι να ξαναχαλάσει)
Στο μεταξύ αν τυχον παρεις 13840 κανει ελεγχο το bot επι τόπου και τα βλέπει όλα καλά εστω και αν πεις οτι εχεις συχνες αποσυνδέσεις. Οτι να'ναι.

Αν η καμπίνα είναι Vodafone, δείτε εδώ

[kmpatra]

εγω πιθανότατα είμαι σε οτε

- - - Updated - - -

Ας πούμε οτι αυτή είναι η "φυσιολογική" κατάσταση της γραμμής. Το max του attainable εδω και αρκετούς μήνες (απο την εποχή που ειχα 50 ακόμα) δεν πέρναει το 130/50

οταν προτοέκανα το καλοκαίρι του 21 την συνδεση ήταν καρφωτο 150/50.
Τα περίεργα που δεν καταλαβαίνω: κατά τον συγχρονισμό της γραμμής το path ειναι fast/interleaved. Κάποιες φορές παραμένει έτσι και δεν μαζεύει πολλά fec ενώ τα crc ειναι σχεδόν μηδέν. Συνήθως όμως μετά από κάποια ώρα (όχι πολύ) το path γυρνάει σε fast/fast (λόγω κάποιας διακύμανσης,λόγω κάποιας δικής τους ρύθμισης; ) και αρχίζει το πανηγύρι με fec και crc. Σημειώστε ότι δεν ζήτησα εγω fast path, στην 50αρα ήταν πάντα fast/interleaved.
Μια με δυο φορες την ημέρα,συνηθως 11-2 ή κατά τις 8 (τις περισσότερες φορές, στο σκριν ας πουμε φαινεται να επεσε κατα τις 5 το πρωι που φυσικά δεν το πήρα χαμπάρι) εχω διακυμάνσεις σε snr, συγχρονισμό και attainable που οδηγουν σε αποσυνδεσεις, 2 και 3 φορες μεσα σε μια-δυο ωρες μεχρι να στρωσει κάπως...οπως ειπα και πριν ο συγχρονισμος χωρις διακοπες ανεβοκατεβαινει, με το snr να μη μενει σταθερο, μπορει π.χ. να δω snr 24/12 με αντιστοιχη πτωση συγχρονισμού. Το δυστύχημα είναι οτι εχουν βαλει στο συμβολαιο ελάχιστη ταχυτητα 65, με συνηθη και μέγιστη τα 110...δυστυχως δεν εδωσα πολύ σημασία τότε και προχώρησα...εχω την εντύπωση βέβαια ότι όταν επικοινωνήσω, το πρώτο που θα αλλάξει είναι το ρούτερ...

- - - Updated - - -

κι επειδη πριν λίγο επαιξε αποσύνδεση, ιδου μετά τον συγχρονισμό το fast/interleaved

υ.γ. υπήρχε κάποιο excel που κυκλοφορούσε εδω μέσα και έδειχνε τους παρόχους και τις καμπίνες ανά περιοχή.Υπάρχει ακόμα κάπου?

[cbarbas]

Το ειδατε,

YouTube στην ποιοτητα streaming εχει καινουργια ρυθμιση "1080p Premium HD"!

Για αυτο μας εσπαζε τα νευρα μερικες φορες, λες να κοβουν bandwidth!???

[zeronero]

Είχε ανακοινωθεί και αφορά σε συνδρομητές.

[GregoirX23]

εγω πιθανότατα είμαι σε οτε

- - - Updated - - -

Ας πούμε οτι αυτή είναι η "φυσιολογική" κατάσταση της γραμμής. Το max του attainable εδω και αρκετούς μήνες (απο την εποχή που ειχα 50 ακόμα) δεν πέρναει το 130/50

οταν προτοέκανα το καλοκαίρι του 21 την συνδεση ήταν καρφωτο 150/50.
Τα περίεργα που δεν καταλαβαίνω: κατά τον συγχρονισμό της γραμμής το path ειναι fast/interleaved. Κάποιες φορές παραμένει έτσι και δεν μαζεύει πολλά fec ενώ τα crc ειναι σχεδόν μηδέν. Συνήθως όμως μετά από κάποια ώρα (όχι πολύ) το path γυρνάει σε fast/fast (λόγω κάποιας διακύμανσης,λόγω κάποιας δικής τους ρύθμισης; ) και αρχίζει το πανηγύρι με fec και crc. Σημειώστε ότι δεν ζήτησα εγω fast path, στην 50αρα ήταν πάντα fast/interleaved.
Μια με δυο φορες την ημέρα,συνηθως 11-2 ή κατά τις 8 (τις περισσότερες φορές, στο σκριν ας πουμε φαινεται να επεσε κατα τις 5 το πρωι που φυσικά δεν το πήρα χαμπάρι) εχω διακυμάνσεις σε snr, συγχρονισμό και attainable που οδηγουν σε αποσυνδεσεις, 2 και 3 φορες μεσα σε μια-δυο ωρες μεχρι να στρωσει κάπως...οπως ειπα και πριν ο συγχρονισμος χωρις διακοπες ανεβοκατεβαινει, με το snr να μη μενει σταθερο, μπορει π.χ. να δω snr 24/12 με αντιστοιχη πτωση συγχρονισμού. Το δυστύχημα είναι οτι εχουν βαλει στο συμβολαιο ελάχιστη ταχυτητα 65, με συνηθη και μέγιστη τα 110...δυστυχως δεν εδωσα πολύ σημασία τότε και προχώρησα...εχω την εντύπωση βέβαια ότι όταν επικοινωνήσω, το πρώτο που θα αλλάξει είναι το ρούτερ...

- - - Updated - - -

κι επειδη πριν λίγο επαιξε αποσύνδεση, ιδου μετά τον συγχρονισμό το fast/interleaved

υ.γ. υπήρχε κάποιο excel που κυκλοφορούσε εδω μέσα και έδειχνε τους παρόχους και τις καμπίνες ανά περιοχή.Υπάρχει ακόμα κάπου?

Και στις 2 περιπτώσεις το g.inp φαίνεται να είναι ενεργό...
Εξ΄ου και το 0 delay...
Το interleaving δεν φαίνεται να κλείνει τελείως ούτε με το fast/fast αφού μετράει fec...
Το ότι πέφτει όμως λίγο ο συγχρονισμός θα μπορούσε κανείς να υποθέσει ότι είναι από το fastpath..
Αλλά μπορεί και να είναι λόγω των error...
Με συνεχή refresh κάνει διακυμάνσεις το noise margin Η και το attainable; Ναι ε;
Λογικά κάπου υπάρχει θόρυβος... Και είναι παράξενο που γυρνάει σε fast αντί να ανεβάσει interleaving..
Ίσως παίζει κάτι με το ρουτερ Η το g.inp εδώ..
Θα μπορούσες να το αναφέρεις στη τεχνική υποστήριξη δεδομένου ότι δεν έχεις ζητήσει fastpath αν και δεν φαίνεται για καθαρό fastpath, να τσεκάρουν από τη πλευρά του dslam πιο προφίλ είναι επιλεγμένο...
Αν όντως είναι δλδ κάποιο interleaved και το ρουτερ το παρουσιάζει ως fast...
Μπορεί να είναι και θέμα ερμηνείας του ρουτερ... Ίσως μια αλλαγή σε νεότερο να βοηθούσε... Αν και είναι θέμα τύχης και αυτό... Το αν θα παίξει πιο καλά η όχι..
Αν όμως η καμπίνα είναι άλλου παρόχου ίσως δεν υπάρχουν αυτές οι διαθέσιμες πληροφορίες...
Το ότι ρίχνει τη γραμμή πάντως δεν είναι καλό σημάδι...
Το sra είναι ενεργό;
Το attainable μπορεί να έπεσε από την αρχή λόγω θέματος του χαλκού Η λόγω περισσοτέρων συνδρομητών..
Αν κάνεις ένα ping emp.gr από cmd με καλώδιο και με τα 2 προφίλ, τι απάντηση παίρνεις;