Πρόβλημα περιορισμού πακέτων απο OTE

[globalnoise]

Δώστε ρε μάγκες δώστε! Από τον Απρίλιο το ήξερα πως παίζετε κάτι τέτοιο και απλά το έριχνα στο οτι είναι πίτα τα dslams!

trojy αδερφέ δώσε αυτά τα στοιχεία στην Forthnet. Θα προσπαθήσω και εγώ με κάτι κονέ που έχω από το τεχνικό τμήμα της HOL (δούλευε η αδερφή μου εκεί παλιότερα) να το μεταφέρω και ο ΟΤΕ βοηθός!

Μπορεί να είναι τεχνικό λάθος του ΟΤΕ δεν λέω... αλλά αν αποδειχθεί πως έχει packet limit ο ΟΤΕ οι providers θα κάνουν καταγγελίες και θα κοπούν κ*λοι

Keep up!

[psyxakias]

psyxakia έχεις σκεφτεί πως τα max packets per second είναι ένα ακόμα σύμπτωμα κι όχι η αιτία;

Πάω πάσο σε αυτό, μπορεί να κάνω λάθος ότι πρόκειται για rate-limiting πάντως μου κάνει εντύπωση ότι είναι 30 καρφωμένο.

Δοκίμασα με OTEnet 384 στην γραμμή μου:

α) Test #1 => 10-bytes packets (38-bytes including overheads):
30 pps / 1380 bytes/sec (minpps: 26, maxpps: 30)

β) Test #2 => 100-bytes packets (128-bytes including overheads):
30 pps / 3455 bytes/sec (minpps: 21, maxpps: 30)

γ) Test #3 => 500-bytes packets (528-bytes including overheads):
29 pps / 14300 bytes/sec (minpps: 27, maxpps: 30)

δ) Test #4 => 1000-bytes packets (1028-bytes including overheads):
29 pps / 28600 bytes/sec (minpps: 26, maxpps: 30)

ε) Test #5 => 1400-bytes packets (1428-bytes including overheads):
30 pps / 39200 bytes/sec (minpps: 27, maxpps: 30)

ΥΣ: Ευχαριστώ θερμά τον EvilHawk που μου έδωσε τη δυνατότητα να κάνω δοκιμή με OTEnet

[psyxakias]

psyxakia, μπράβο για τις δοκιμές. Η παρατήρηση σου είναι πολύ χρήσιμη.
Θα ήθελα αν μπορείς in public ή σε PM, να στείλεις οδηγίες για το πως έκανες τη δοκιμή.
Εγώ προσωπικά, δεν γνωρίζω πως να στείλω UDP πακέτα πλήρως ελεγχόμενα. Για αυτό και χρησιμοποιώ το voip ως γνώμονα.

Χρησιμοποιώ ανορθόδοξο λίγο τρόπο για να στείλω τα πακέτα αλλά μόνο έτσι είμαι σίγουρος ότι pushάρω την γραμμή στο μέγιστο.

Από 100 Mbps freebsd server χρησιμοποιώ ενα udpflood utility, αφού του κάνω modify τον κώδικά του για να αλλάξω το μέγεθος των πακέτων και κάνω ratelimit τα outgoing UDPs σε 500 Kbps από το ipfw+dummynet (γιατί άμα το αφήσω χωρίς όριο θα στέλνει 100 Mbps και θα με κυνηγάνε οι ISPs). Το utility λέγεται vadimI και θα πρότεινα να μην χρησιμοποιηθεί για άλλους σκοπούς (denial-of-service) διότι άμεσα εντοπίζεται και θα βρεις μπελά...

Μέτρηση bandwidth: DUMeter (προσοχή να έχει ρυθμιστεί η σωστή interface για να μην μετράει το bandwidth εις διπλούν)
Μέτρηση πακέτων: Start/Run, %SystemRoot%\system32\perfmon.msc (υπάρχει και σε εικονίδιο στο Administrative Tools, αλλά έχω τη συνήθεια του Start/Run) και διαλέγω από το Network Interface το packets received/sec και bytes received/sec.
Utility: vadimI.c (μπορώ να σου δώσω το κώδικά του μέσω PM)

Δοκίμασα επίσης να κάνω τα ίδια tests στην IP του EvilHawk και του έβγαζε στο Performance επίσης 25-31 pps και μετά ενώ σταματούσα να τα στέλνω γινόντουσαν queue για 1-2 λεπτά.

ΥΣ: Τον έλεγχο του utility πρέπει να τον έχεις από άλλη ανεξάρτητη σύνδεση (πχ εγώ έμπαινα με ISDN) ειδάλλως όταν αρχίσουν και έρχονται τα 30 pps, νεκρώνει η ADSL.

ΥΣ2: Και 10 kbps udp ratelimit να βάλω, όταν στέλνω πακέτα των 10 bytes (+ headers) η γραμμή νεκρώνει απλώς με 1 kB/sec...

ΥΣ3: Αν θες μπορώ να σου δώσω το τηλέφωνό μου σε PM εάν θέλει οποιοσδήποτε ISP ή ο ΟΤΕ να επικοινωνήσει μαζί μου για περαιτέρω δοκιμές...

[psyxakias]

Εδώ βρίσκονται συγκεντρωμένες οι δοκιμές με OTEnet & FORTHnet που δείχνουν πως ασχέτως αν στέλνω 100άδες (αν όχι 1000άδες) πακέτα από το Internet, μπορώ να λάβω το πολύ 30 πακέτα το δευτερόλεπτο χωρίς να παίζει καθόλου ρόλο το μέγεθός τους, με αποτέλεσμα να νεκρώνει η γραμμή σε περίπτωση που είναι UDP καθώς συνεχίζουν να έρχονται χωρίς έλεγχο:

Ημερομηνία/Ώρα: Κυριακή 25/Σεπ/2005 20:30-21:50

OTE 384 (DSLAM Πατησίων: 448/160) + FORTHnet 384/128 Static
- 10-bytes packets (38-bytes including overheads):
average: 28 pps / 1285-1330 bytes/sec (minpps: 23, maxpps: 30)

- 100-bytes packets (128-bytes including overheads):
average: 29 pps / 3450-3570 bytes/sec (minpps: 22, maxpps: 30)

- 500-bytes packets (528-bytes including overheads):
average: 29 pps / 14882-15140 bytes/sec (minpps: 23, maxpps: 30)

- 1000-bytes packets (1028-bytes including overheads):
average: 29 pps / 26650-28700 bytes/sec (minpps: 22, maxpps: 30)

- 1400-bytes packets (1428-bytes including overheads):
average: 30 pps / 38555-41266 bytes/sec (minpps: 22, maxpps: 30)


OTE 384 (DSLAM Πατησίων: 448/160) + OTEnet 384/128 Dynamic
- 10-bytes UDP packets (38-bytes including overheads):
average: 30 pps / 1380 bytes/sec (minpps: 26, maxpps: 30)

- 100-bytes UDP packets (128-bytes including overheads):
average: 30 pps / 3455 bytes/sec (minpps: 21, maxpps: 30)

- 500-bytes UDP packets (528-bytes including overheads):
average: 29 pps / 14300 bytes/sec (minpps: 27, maxpps: 30)

- 1000-bytes UDP packets (1028-bytes including overheads):
average: 29 pps / 28600 bytes/sec (minpps: 26, maxpps: 30)

- 1400-bytes UDP packets (1428-bytes including overheads):
average: 30 pps / 39200 bytes/sec (minpps: 27, maxpps: 30)

Επίσης, ακόμα και αν σταματήσω να στέλνω τα πακέτα, παραμένουν στο queue και παραδίδονται σταδιακά (με 30 pps) έτσι ώστε να παραδοθούν όλα (ή έστω τα περισσότερα από αυτά).

Πιθανόν το πρόβλημα να εμφανίζεται και με UDP αλλά και με TCP πακέτα, με την διαφορά ότι το UDP πρωτόκολλο δεν έχει ελέγχους για να μειώσει την ποσότητά τους, σε αντίθεση με το TCP έτσι ώστε να παρατηρείται έντονο πρόβλημα κυρίως με τα UDP πακέτα.

ΥΣ: Όταν μου ενεργοποιηθεί η 512 γραμμή, θα δοκιμάσω και από εκεί... θέλω να ελπίζω ότι θα είναι καλύτερα τα πράγματα εκεί.

[cassidy]

psyxakia εμένα δεν είναι κολλημένο στα 30, είναι συνήθως γύρω στα 20-25.

Και πάλι, για ποιο λόγο να κάνουν rate limiting κάθε μέρα μέχρι τις 1 το βράδυ για παράδειγμα;
Αν ήταν μέχρι το μεσημέρι-απόγευμα (να το δίνουν σε επιχειρησιακούς πελάτες) θα συμφωνούσα.

Για ποιο λόγο να συμβαίνει σε μερικές περιοχές και σε άλλες όχι;

Αν συνδυάσεις περιοχές που έχουν το πρόβλημα σε συνδυασμό με τους πίνακες που δείχνουν τη πληρότητα των dslams θα καταλάβεις.

Κι όλα αυτά γιατί; Είπαμε οι ταχύτητες δεν είναι εγγυημένες αλλά πραγματικά δε νομίζω πουθενά αλλού στο κόσμο να δίνουν συνδέσεις DSL χωρίς να σου δίνουν το καταραμένο το contention ratio...

[psyxakias]

psyxakia εμένα δεν είναι κολλημένο στα 30, είναι συνήθως γύρω στα 20-25.

Η τελευταία φορά που το είχα ελέγξει και εγώ πριν κανά 4-6μηνο άλλαζε αναλόγως την ώρα, άλλωτε 20, άλλωτε 25 αλλά πρόσφατα βλέπω ξεκίνησε τα 30άρια.

Και πάλι, για ποιο λόγο να κάνουν rate limiting κάθε μέρα μέχρι τις 1 το βράδυ για παράδειγμα; Αν ήταν μέχρι το μεσημέρι-απόγευμα (να το δίνουν σε επιχειρησιακούς πελάτες) θα συμφωνούσα.

Δεν έχω παρακολουθήσει στενά και αποδεδειγμένα ποιες ώρες συμβαίνει, ίσως επειδή αρκετοί κάνουν downloading έως τις 12-1 βράδυ (δεν μιλάω για downloaders επί 24ωρου βάσεως)

Για ποιο λόγο να συμβαίνει σε μερικές περιοχές και σε άλλες όχι;

Διαφορετικός εξοπλισμός DSLAMs ίσως; Λιγότερη κίνηση;

Αν συνδυάσεις περιοχές που έχουν το πρόβλημα σε συνδυασμό με τους πίνακες που δείχνουν τη πληρότητα των dslams θα καταλάβεις.

Δεν διαφωνώ καθόλου, ακριβώς αυτό εκεί θέλω να καταλήξω καθώς όλα αυτά ξεκίνησαν από όταν γέμισε το DSLAM μου και ξεκίνησαν οι μειώσεις στις ταχύτητες.

Κι όλα αυτά γιατί; Είπαμε οι ταχύτητες δεν είναι εγγυημένες αλλά πραγματικά δε νομίζω πουθενά αλλού στο κόσμο να δίνουν συνδέσεις DSL χωρίς να σου δίνουν το καταραμένο το contention ratio...

Μια φήμη που είχε ακουστεί παλιότερα και θα μπορούσα να πω ότι έχει κάποια λογική είναι ότι ένα μέρος του εξοπλισμού που χρησιμοποιεί ο ΟΤΕ δεν δέχεται bandwidth-based ratelimiting αλλά packet-based, έτσι ώστε πέρα από το συγχρονισμό (384/128, 448/160, 512/128, 576/160 κλπ) να αναγκάζονται να κάνουν packet-based ratelimiting στις ώρες αιχμής για να ελέγξουν την κατάσταση.

Η λογική λοιπόν είναι ότι για να ελέγξουν τα κατεβάσματα των συνδρομητών από http/ftp που χρησιμοποιούν μεγάλα πακέτα (1492 bytes μαζί με τα overheads στο PPPoE) κάνουν ratelimit σε 20 pps (20 x 1492 = 29.840 bytes/sec) ή 25 pps (25 x 1492 = 37.300 bytes/sec) ή 30 pps (30 x 1492 = 44.760 bytes/sec)


Μάλιστα αυτός είναι και ο λόγος που νομίζω πως το κάνουν σε ΟΛΑ τα πακέτα, όχι μόνο στα UDP. Απλά τα UDP προκαλούν περισσότερο πρόβλημα γιατί δεν έχουν έλεγχο και έρχονται ανεξέλεγκτα (αυξάνοντας το latency και νεκρώνοντας την γραμμή) μέχρι η πηγή κάποια στιγμή να συνειδητοποιήσει (με κάποιο icmp ping ή άλλο τρόπο) ότι δε τα λαμβάνεις και να σταματήσει εφ'όσον το πρωτόκολλο από μόνο του (από τις ταπεινές μου γνώσεις) δεν υποστηρίζει έλεγχο αποστολής πακέτων αναλόγως με την ταχύτητα/latency σε αντίθεση με το TCP που κάνει ελέγχους με τα ack πακέτα.

[psyxakias]

Έστειλα νωρίτερα e-mail στην FORTHnet (internet-support@forthnet.gr) για να τους ενημερώσω για το thread καθώς και τις συγκεκριμένες δοκιμές που έκανα, μου τηλεφώνησαν εντός 4 λεπτών (γρήγοροι όπως πάντα!) και μου ζήτησαν ότι ζητάνε στους συνδρομητές τους για να συγκεντρώσουν στοιχεία για το συγκεκριμένο πρόβλημα για να συνεχιστεί περαιτέρω έρευνα σε συνεργασία με τον ΟΤΕ για την επίλυσή του.

1) Να κάνουμε ένα tracert να δούμε στα πρώτα 1-2 hops σε ποιον BBRAS της FORTHnet (ή άλλου ISP) ανήκουμε, πχ bbras-ath-02L0.forthnet.gr
2) Ενώ η σύνδεσή μας είναι idle (κλειστά τα πάντα), να τρέξουμε το εξής από το command prompt: "ping -t <bbras>" (πχ: ping -t bbras-ath-02L0.forthnet.gr)
3) Να χρησιμοποιήσουμε κάποιο VoIP λογισμικό έτσι ώστε να καταγραφεί η αύξηση των pings και τα πιθανά requests timeout
4) Να κλείσουμε το VoIP λογισμικό και να κάνουμε copy/paste όλα τα αποτελέσματα και να τους τα στείλουμε μέσω e-mail στο internet-support@forthnet.gr


Σημείωση #1: Επίσης μάλλον ξέχασαν να μου πουν, ότι επειδή η FORTHnet φιλτράρει των είδος/τύπο των πακέτων που χρησιμοποιεί το tracert, για να βρούμε τον BBRAS πρέπει να χρησιμοποιήσουμε άλλο πρόγραμμα. Εγώ χρησιμοποιώ το WinMTR που βρίσκεται εδώ: http://winmtr.sourceforge.net/winmtr_bin.zip - απλώς το κατέβαζετε, τρέχετε το .exe που έχει μέσα το .zip (δεν έχει ιό, fully tested) και κάνετε traceroute κάποιο host/ip για να σας δείξει τον bbras. Μην ξεχάσετε να το κλείσετε μετά πριν ξεκινήσετε τα ping tests.

Σημείωση #2: Επίσης μου είπαν ότι είναι ευπρόσδεκτο εάν διαθέτουμε σύνδεση φίλου/γνωστού σε άλλον ISP έτσι ώστε να επαναλάβουμε τα ίδια βήματα, για να φανεί ότι το πρόβλημα δεν εμφανίζεται μόνο στην FORTHnet (κάτι που επιβεβαιώνω και εγώ καθώς δοκίμασα με OTEnet σήμερα αλλά και ACN που είχα δοκιμάσει παλιότερα).

Σημείωση #3: Αν και δεν μου το ανέφεραν, θα πρότεινα να τους αναφέρουμε δύο επιπλέον πράγματα: α) τηλέφωνο της γραμμής ADSL (για να βρουν περιοχή/τύπο DSLAMs) και β) τύπο modem (για να ελεγχθεί αν ευθύνονται συγκεκριμένα modem, κάτι που προσωπικά θεωρώ απίθανο)

[cassidy]

Καλά ρε ολόκληρος τελικός του ευρωπαϊκού και είχες άμεση απάντηση από τη forthnet;;;
impressed! Θα τα έχεις σύντομα (αύριο το πρωί καλύτερα γιατί τώρα μάλλον κλείσανε όλοι τα πισιά και βγήκαν έξω να πανηγυρίσουν )

[trojy]

IPTraf
┌ Packet Distribution by Size ─────────────────────────────────────────────────┐
│ │
│ Packet size brackets for interface ppp0 │
│ │
│ │
│ Packet Size (bytes) Count Packet Size (bytes) Count │
│ 1 to 74: 447 741 to 814: 15 │
│ 75 to 148: 307 815 to 888: 6 │
│ 149 to 222: 4204 889 to 962: 2 │
│ 223 to 296: 4 963 to 1036: 3 │
│ 297 to 370: 19 1037 to 1110: 5 │
│ 371 to 444: 10 1111 to 1184: 0 │
│ 445 to 518: 1 1185 to 1258: 0 │
│ 519 to 592: 0 1259 to 1332: 1 │
│ 593 to 666: 1 1333 to 1406: 0 │
│ 667 to 740: 13 1407 to 1492+: 66 │
│



Η συντριπτική πλειοψηφία των πακέτων UDP είναι ανάμεσα σε 149 και 222 bytes.

[anon]

Η λογική λοιπόν είναι ότι για να ελέγξουν τα κατεβάσματα των συνδρομητών από http/ftp που χρησιμοποιούν μεγάλα πακέτα (1492 bytes μαζί με τα overheads στο PPPoE) κάνουν ratelimit σε 20 pps (20 x 1492 = 29.840 bytes/sec) ή 25 pps (25 x 1492 = 37.300 bytes/sec) ή 30 pps (30 x 1492 = 44.760 bytes/sec)Μάλιστα αυτός είναι και ο λόγος που νομίζω πως το κάνουν σε ΟΛΑ τα πακέτα, όχι μόνο στα UDP. Απλά τα UDP προκαλούν περισσότερο πρόβλημα γιατί δεν έχουν έλεγχο και έρχονται ανεξέλεγκτα (αυξάνοντας το latency και νεκρώνοντας την γραμμή) μέχρι η πηγή κάποια στιγμή να συνειδητοποιήσει (με κάποιο icmp ping ή άλλο τρόπο) ότι δε τα λαμβάνεις και να σταματήσει εφ'όσον το πρωτόκολλο από μόνο του (από τις ταπεινές μου γνώσεις) δεν υποστηρίζει έλεγχο αποστολής πακέτων αναλόγως με την ταχύτητα/latency σε αντίθεση με το TCP που κάνει ελέγχους με τα ack πακέτα.

Αυτο μου φαίνεται ότι είναι το πιο πιθανό, και έτσι φαίνεται ότι υπάρχει πρόβλημα σε UDP με real time applications (πχ VoIP). Πχ με codec g729 θέλεις ένα πακέτο κάθε 10ms, που σημαίνει 100 πακέτα το δευτερόλεπτο. Απλά δεν παιρνάνε (όλα). Εαν χρησιμοποιήσεις G723 με frame rate 30ms τότε έχεις 33 πακέτα το δευτερόλεπτα. Κάπως καλύτερα τα πράγματα αλλά πρέπει να συνυπολογίσουμε και κάποια πακέτα overhead, ώστε και πάλι θα έχει προβλημα. Ισως εδώ εξηγείται και το γεγονός ότι σε pings έχουμε αυξανόμενους χρόνους ανταπόκρισης μέχρι timeout, και μετά επανέρχεται. Φαινεται ότι γίνεται ένα είδος ελέγχου αριθμού πακέτων στο δευτερόλεπτο (ή σε πολλάπλάσιο χρόνο του δευτερολέπτου). Και μάλλον αυτό γίνετα απο ΟΤΕ και όχι απο παρόχους.

[trojy]

Ενώ χρησιμοποιούσα το voip σημέρα το πρωί.

64 bytes from 194.219.252.144: icmp_seq=25680 ttl=255 time=150 ms
64 bytes from 194.219.252.144: icmp_seq=25681 ttl=255 time=265 ms
64 bytes from 194.219.252.144: icmp_seq=25682 ttl=255 time=432 ms
64 bytes from 194.219.252.144: icmp_seq=25683 ttl=255 time=773 ms
64 bytes from 194.219.252.144: icmp_seq=25684 ttl=255 time=1153 ms
64 bytes from 194.219.252.144: icmp_seq=25685 ttl=255 time=946 ms
64 bytes from 194.219.252.144: icmp_seq=25686 ttl=255 time=544 ms
64 bytes from 194.219.252.144: icmp_seq=25687 ttl=255 time=174 ms
64 bytes from 194.219.252.144: icmp_seq=25688 ttl=255 time=204 ms
64 bytes from 194.219.252.144: icmp_seq=25689 ttl=255 time=44.9 ms
64 bytes from 194.219.252.144: icmp_seq=25690 ttl=255 time=42.2 ms
64 bytes from 194.219.252.144: icmp_seq=25691 ttl=255 time=63.9 ms
64 bytes from 194.219.252.144: icmp_seq=25692 ttl=255 time=53.3 ms
64 bytes from 194.219.252.144: icmp_seq=25693 ttl=255 time=67.4 ms
64 bytes from 194.219.252.144: icmp_seq=25694 ttl=255 time=87.8 ms
64 bytes from 194.219.252.144: icmp_seq=25695 ttl=255 time=71.8 ms
64 bytes from 194.219.252.144: icmp_seq=25696 ttl=255 time=92.3 ms
64 bytes from 194.219.252.144: icmp_seq=25697 ttl=255 time=46.4 ms
64 bytes from 194.219.252.144: icmp_seq=25698 ttl=255 time=45.9 ms
64 bytes from 194.219.252.144: icmp_seq=25699 ttl=255 time=68.6 ms
64 bytes from 194.219.252.144: icmp_seq=25700 ttl=255 time=35.1 ms
64 bytes from 194.219.252.144: icmp_seq=25701 ttl=255 time=37.8 ms
64 bytes from 194.219.252.144: icmp_seq=25702 ttl=255 time=38.3 ms
64 bytes from 194.219.252.144: icmp_seq=25703 ttl=255 time=69.8 ms
64 bytes from 194.219.252.144: icmp_seq=25704 ttl=255 time=49.4 ms
64 bytes from 194.219.252.144: icmp_seq=25705 ttl=255 time=33.6 ms
64 bytes from 194.219.252.144: icmp_seq=25706 ttl=255 time=95.9 ms
64 bytes from 194.219.252.144: icmp_seq=25707 ttl=255 time=129 ms
64 bytes from 194.219.252.144: icmp_seq=25708 ttl=255 time=150 ms
64 bytes from 194.219.252.144: icmp_seq=25709 ttl=255 time=375 ms
64 bytes from 194.219.252.144: icmp_seq=25710 ttl=255 time=826 ms
64 bytes from 194.219.252.144: icmp_seq=25711 ttl=255 time=1113 ms
64 bytes from 194.219.252.144: icmp_seq=25712 ttl=255 time=1289 ms
64 bytes from 194.219.252.144: icmp_seq=25713 ttl=255 time=1719 ms
64 bytes from 194.219.252.144: icmp_seq=25714 ttl=255 time=2076 ms
64 bytes from 194.219.252.144: icmp_seq=25715 ttl=255 time=2349 ms
64 bytes from 194.219.252.144: icmp_seq=25716 ttl=255 time=2672 ms
64 bytes from 194.219.252.144: icmp_seq=25717 ttl=255 time=3137 ms
64 bytes from 194.219.252.144: icmp_seq=25718 ttl=255 time=3640 ms
64 bytes from 194.219.252.144: icmp_seq=25719 ttl=255 time=3881 ms
64 bytes from 194.219.252.144: icmp_seq=25720 ttl=255 time=4214 ms
64 bytes from 194.219.252.144: icmp_seq=25721 ttl=255 time=4688 ms
64 bytes from 194.219.252.144: icmp_seq=25722 ttl=255 time=4681 ms
64 bytes from 194.219.252.144: icmp_seq=25723 ttl=255 time=4782 ms
64 bytes from 194.219.252.144: icmp_seq=25724 ttl=255 time=4915 ms
64 bytes from 194.219.252.144: icmp_seq=25725 ttl=255 time=5020 ms
64 bytes from 194.219.252.144: icmp_seq=25726 ttl=255 time=5072 ms
64 bytes from 194.219.252.144: icmp_seq=25727 ttl=255 time=4873 ms
64 bytes from 194.219.252.144: icmp_seq=25728 ttl=255 time=5229 ms
64 bytes from 194.219.252.144: icmp_seq=25729 ttl=255 time=5461 ms
64 bytes from 194.219.252.144: icmp_seq=25730 ttl=255 time=5469 ms
64 bytes from 194.219.252.144: icmp_seq=25731 ttl=255 time=5246 ms
64 bytes from 194.219.252.144: icmp_seq=25732 ttl=255 time=5167 ms
64 bytes from 194.219.252.144: icmp_seq=25733 ttl=255 time=4929 ms
64 bytes from 194.219.252.144: icmp_seq=25734 ttl=255 time=5100 ms
64 bytes from 194.219.252.144: icmp_seq=25735 ttl=255 time=5047 ms
64 bytes from 194.219.252.144: icmp_seq=25736 ttl=255 time=4784 ms
64 bytes from 194.219.252.144: icmp_seq=25737 ttl=255 time=4419 ms
64 bytes from 194.219.252.144: icmp_seq=25738 ttl=255 time=4202 ms
64 bytes from 194.219.252.144: icmp_seq=25739 ttl=255 time=3661 ms
64 bytes from 194.219.252.144: icmp_seq=25740 ttl=255 time=3008 ms
64 bytes from 194.219.252.144: icmp_seq=25741 ttl=255 time=2656 ms
64 bytes from 194.219.252.144: icmp_seq=25742 ttl=255 time=2081 ms
64 bytes from 194.219.252.144: icmp_seq=25743 ttl=255 time=1821 ms
64 bytes from 194.219.252.144: icmp_seq=25744 ttl=255 time=1382 ms
64 bytes from 194.219.252.144: icmp_seq=25745 ttl=255 time=702 ms
64 bytes from 194.219.252.144: icmp_seq=25746 ttl=255 time=34.6 ms
64 bytes from 194.219.252.144: icmp_seq=25747 ttl=255 time=37.4 ms
64 bytes from 194.219.252.144: icmp_seq=25748 ttl=255 time=30.4 ms
64 bytes from 194.219.252.144: icmp_seq=25749 ttl=255 time=73.0 ms

[minovg]

Ρε παιδιά για εμάς τους άσχετους τι σημαίνουν όλα αυτά τα νούμερα; Δεν είμαστε όλοι εξπέρ για να καταλαβαίνουμε... Πρακτικά, με απλά λόγια μπορεί να μας πει κάποιος τι συμβαίνει και σε ποιο στάδιο βρισκόμαστε; Υπάρχει επίγνωση του θέματος/προβλήματος από τον ΟΤΕ; Πρέπει ο καθένας να ειδοποιήσει χωριστά τον ΟΤΕ και να δηλώσει βλάβη; Λύνεται γενικώς το θέμα/πρόβλημα;

[anon]

Ενώ χρησιμοποιούσα το voip σημέρα το πρωί.

64 bytes from 194.219.252.144: icmp_seq=25680 ttl=255 time=150 ms
64 bytes from 194.219.252.144: icmp_seq=25681 ttl=255 time=265 ms
64 bytes from 194.219.252.144: icmp_seq=25682 ttl=255 time=432 ms
64 bytes from 194.219.252.144: icmp_seq=25683 ttl=255 time=773 ms
64 bytes from 194.219.252.144: icmp_seq=25684 ttl=255 time=1153 ms

Αυτο που με παραξενεύει είναι ότι αν έχουν κάποιας μορφής "κόφτη" σύμφωνα με τον αριθμό των πακέτων ανα δευτερόλεπτο, τότε εαν κάνεις μόνο Ping χωρίς τίποτα άλλο στην γραμμή, δεν θα έπρεπε να έχεις το παραμικρό πρόβλημα. Γιατί σίγουρα θα στέλνεις (και θα λαμβάνεις) πολύ λιγότερα απο 30 πακέτα το δευτερόλεπτο.

[cassidy]

Μα πράγματι, όταν κάνεις ping χωρίς να κάνεις τίποτα άλλο, τα ping είναι φυσιολογικά και πεπερασμένα

[anon]

Μα πράγματι, όταν κάνεις ping χωρίς να κάνεις τίποτα άλλο, τα ping είναι φυσιολογικά και πεπερασμένα

Μπα όχι, τουλάχιστον αυτά που υπέβαλε ο trojy. Εχει απο 30ms μέχρι 5300 ms!!!!!!
Καθόλου φυσιολογικό δεν το βρίσκω εγώ. Ακόμη και 100ms δεν είναι φυσιολογικό (σε κοντινή ip).