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

[globalnoise]

Ακόμα και αν έχουν σκοπό να το θιάξουν σε όλη την Ελλάδα...

Για να γίνει κάτι τέτοιο χρειάζετε μια ουσιώδη οργάνωση-ενημέρωση... Δηλαδή περιμένεις εσύ κάτι τέτοιο από τον ΟΤΕ?

[globalnoise]

Λοιπόν είχατε δίκιο. Δεν έχει σημασία πως περνάει το PPP... Η διαφορά που είδα ήταν επειδή όντως κάτι έφτιαξε ο ΟΤΕ σχετικά με το πρόβλημα. Ακόμη και σε ώρα αιχμής πλέον μπορώ να συνδεθώ σε cs:s server και όταν το αζούρι κατεβάζει δεν έχω lag στο IRC!

[globalnoise]

Μάπα τελικά... Σήμερα πάλι τα ίδια... Μιάμιση μέρα κράτησε το όνειρο...

[psyxakias]

Eγώ αυτό που θα πρότεινα να αρχίσουμε να συγκρίνουμε είναι:
α) Όνομα DSLAM (πχ "DSLAM Πατησίων") όπως αναφέρεται στη λίστα των DSLAMs
β) Τύπος DSLAM (πχ Siemens1) - Δεν γνωρίζω πως τα ξεχωρίζουμε, νομίζω τα 1 είναι που συγχρονίζουν σε 448 και τα 2 σε 384 (χωρίς να είμαι σίγουρος)
γ) ταχύτητα συγχρονισμού (πχ 448/160)

Αρχίζω να πιστεύω ότι το πρόβλημα οφείλεται στο γνωστό θέμα με το packet-based ratelimiting σε peak hours ή κάτι άλλο σχετικό με τα Siemens DSLAMs.

[cassidy]

Εγώ δε βρίσκομαι σε siemens dslam. Το πρόβλημα κρατάει και μέχρι τις 1-2 τη νύχτα.
Μετά πηγαίνει σαφώς καλύτερα μέχρι τις 7-8 το πρωί.
Ακόμα υπάρχει μεγάλη διαφορά σε περιόδους διακοπών (15 Αύγουστο πέταγε)

DSLAM Γαλατσίου - Intracom - 384/128

Το πρόβλημα έχει πολλές πιθανότητες να λυθεί αν αναβαθμίσω τη γραμμή(μόνο) σε 512... θα το σκεφτώ.

[trojy]

Κυριακή 18:40
root@viagrios:/var/log# ping 194.219.252.144
PING 194.219.252.144 (194.219.252.144) 56(84) bytes of data.
64 bytes from 194.219.252.144: icmp_seq=1 ttl=255 time=51.7 ms
64 bytes from 194.219.252.144: icmp_seq=2 ttl=255 time=52.3 ms
64 bytes from 194.219.252.144: icmp_seq=3 ttl=255 time=48.8 ms
64 bytes from 194.219.252.144: icmp_seq=4 ttl=255 time=45.6 ms
64 bytes from 194.219.252.144: icmp_seq=5 ttl=255 time=51.1 ms
64 bytes from 194.219.252.144: icmp_seq=6 ttl=255 time=46.3 ms
64 bytes from 194.219.252.144: icmp_seq=7 ttl=255 time=79.0 ms
64 bytes from 194.219.252.144: icmp_seq=8 ttl=255 time=42.7 ms
64 bytes from 194.219.252.144: icmp_seq=9 ttl=255 time=55.7 ms
64 bytes from 194.219.252.144: icmp_seq=10 ttl=255 time=49.8 ms
64 bytes from 194.219.252.144: icmp_seq=11 ttl=255 time=59.5 ms
64 bytes from 194.219.252.144: icmp_seq=12 ttl=255 time=55.8 ms
64 bytes from 194.219.252.144: icmp_seq=13 ttl=255 time=47.6 ms
64 bytes from 194.219.252.144: icmp_seq=14 ttl=255 time=74.4 ms
64 bytes from 194.219.252.144: icmp_seq=15 ttl=255 time=46.6 ms
64 bytes from 194.219.252.144: icmp_seq=16 ttl=255 time=55.3 ms
64 bytes from 194.219.252.144: icmp_seq=17 ttl=255 time=48.1 ms
64 bytes from 194.219.252.144: icmp_seq=18 ttl=255 time=39.6 ms
64 bytes from 194.219.252.144: icmp_seq=19 ttl=255 time=49.2 ms
64 bytes from 194.219.252.144: icmp_seq=20 ttl=255 time=56.8 ms
64 bytes from 194.219.252.144: icmp_seq=21 ttl=255 time=50.3 ms
64 bytes from 194.219.252.144: icmp_seq=22 ttl=255 time=53.5 ms
64 bytes from 194.219.252.144: icmp_seq=23 ttl=255 time=54.2 ms
64 bytes from 194.219.252.144: icmp_seq=24 ttl=255 time=67.0 ms
64 bytes from 194.219.252.144: icmp_seq=25 ttl=255 time=50.8 ms
64 bytes from 194.219.252.144: icmp_seq=26 ttl=255 time=56.5 ms
64 bytes from 194.219.252.144: icmp_seq=27 ttl=255 time=52.2 ms
64 bytes from 194.219.252.144: icmp_seq=28 ttl=255 time=45.2 ms
64 bytes from 194.219.252.144: icmp_seq=29 ttl=255 time=48.1 ms
64 bytes from 194.219.252.144: icmp_seq=30 ttl=255 time=47.4 ms
64 bytes from 194.219.252.144: icmp_seq=31 ttl=255 time=66.8 ms
64 bytes from 194.219.252.144: icmp_seq=32 ttl=255 time=46.6 ms
64 bytes from 194.219.252.144: icmp_seq=33 ttl=255 time=57.6 ms
64 bytes from 194.219.252.144: icmp_seq=34 ttl=255 time=181 ms
64 bytes from 194.219.252.144: icmp_seq=35 ttl=255 time=564 ms
64 bytes from 194.219.252.144: icmp_seq=36 ttl=255 time=886 ms
64 bytes from 194.219.252.144: icmp_seq=37 ttl=255 time=1118 ms
64 bytes from 194.219.252.144: icmp_seq=38 ttl=255 time=1432 ms
64 bytes from 194.219.252.144: icmp_seq=39 ttl=255 time=1532 ms
64 bytes from 194.219.252.144: icmp_seq=40 ttl=255 time=1696 ms
64 bytes from 194.219.252.144: icmp_seq=41 ttl=255 time=2327 ms
64 bytes from 194.219.252.144: icmp_seq=42 ttl=255 time=2631 ms
64 bytes from 194.219.252.144: icmp_seq=43 ttl=255 time=3044 ms
64 bytes from 194.219.252.144: icmp_seq=44 ttl=255 time=3650 ms
64 bytes from 194.219.252.144: icmp_seq=45 ttl=255 time=3870 ms
64 bytes from 194.219.252.144: icmp_seq=46 ttl=255 time=3995 ms
64 bytes from 194.219.252.144: icmp_seq=47 ttl=255 time=4019 ms
64 bytes from 194.219.252.144: icmp_seq=48 ttl=255 time=4004 ms
64 bytes from 194.219.252.144: icmp_seq=49 ttl=255 time=4142 ms
64 bytes from 194.219.252.144: icmp_seq=50 ttl=255 time=4351 ms
64 bytes from 194.219.252.144: icmp_seq=51 ttl=255 time=4313 ms
64 bytes from 194.219.252.144: icmp_seq=52 ttl=255 time=4331 ms
64 bytes from 194.219.252.144: icmp_seq=53 ttl=255 time=4335 ms
64 bytes from 194.219.252.144: icmp_seq=54 ttl=255 time=4134 ms
64 bytes from 194.219.252.144: icmp_seq=55 ttl=255 time=3852 ms
64 bytes from 194.219.252.144: icmp_seq=56 ttl=255 time=3466 ms
64 bytes from 194.219.252.144: icmp_seq=57 ttl=255 time=2834 ms
64 bytes from 194.219.252.144: icmp_seq=58 ttl=255 time=2365 ms
64 bytes from 194.219.252.144: icmp_seq=59 ttl=255 time=2006 ms
64 bytes from 194.219.252.144: icmp_seq=60 ttl=255 time=1607 ms
64 bytes from 194.219.252.144: icmp_seq=61 ttl=255 time=1572 ms
64 bytes from 194.219.252.144: icmp_seq=62 ttl=255 time=1383 ms
64 bytes from 194.219.252.144: icmp_seq=63 ttl=255 time=1224 ms
64 bytes from 194.219.252.144: icmp_seq=64 ttl=255 time=680 ms
64 bytes from 194.219.252.144: icmp_seq=65 ttl=255 time=98.5 ms
64 bytes from 194.219.252.144: icmp_seq=66 ttl=255 time=57.0 ms
64 bytes from 194.219.252.144: icmp_seq=67 ttl=255 time=46.8 ms
64 bytes from 194.219.252.144: icmp_seq=68 ttl=255 time=30.1 ms
64 bytes from 194.219.252.144: icmp_seq=69 ttl=255 time=40.4 ms
64 bytes from 194.219.252.144: icmp_seq=70 ttl=255 time=32.3 ms
64 bytes from 194.219.252.144: icmp_seq=71 ttl=255 time=29.5 ms
64 bytes from 194.219.252.144: icmp_seq=72 ttl=255 time=33.7 ms

--- 194.219.252.144 ping statistics ---
72 packets transmitted, 72 received, 0% packet loss, time 71027ms
rtt min/avg/max/mdev = 29.582/1162.286/4351.025/1551.924 ms, pipe 5

Από idled, σε χρήση VOIP και πάλι idled. Συγχρονίζομαι στα 384. Τη Δευτέρα ο τεχνικός της forthnet θα με ενημερώσει.

[trojy]

Eγώ αυτό που θα πρότεινα να αρχίσουμε να συγκρίνουμε είναι:
α) Όνομα DSLAM (πχ "DSLAM Πατησίων") όπως αναφέρεται στη λίστα των DSLAMs
β) Τύπος DSLAM (πχ Siemens1) - Δεν γνωρίζω πως τα ξεχωρίζουμε, νομίζω τα 1 είναι που συγχρονίζουν σε 448 και τα 2 σε 384 (χωρίς να είμαι σίγουρος)
γ) ταχύτητα συγχρονισμού (πχ 448/160)

Αρχίζω να πιστεύω ότι το πρόβλημα οφείλεται στο γνωστό θέμα με το packet-based ratelimiting σε peak hours ή κάτι άλλο σχετικό με τα Siemens DSLAMs.

Psyxakia: Εγώ δεν το γνωρίζω αυτό το QOS. Μήπως μπορείς να γίνεις πιο ακριβής;
1. Από ποιον γίνεται αυτό το QOS;
2. Έχει δημοσιοποιηθεί πουθενά;
3. Εχει ξανασυζητηθεί στο forum αυτό το ζήτημα;

[psyxakias]

Το πρόβλημα έχει πολλές πιθανότητες να λυθεί αν αναβαθμίσω τη γραμμή(μόνο) σε 512... θα το σκεφτώ.

Θα ελέγξω αύριο που λογικά θα γίνει η δική μου μετατροπή

Μόλις έκανα και εγώ ένα test (το τελευταίο μου σε 384 γραμμή ελπίζω!):

DL: 2.2 kB/sec / UL: 0.1 kB/sec

E:\>ping -t -w 5000 194.219.252.147

Pinging 194.219.252.147 with 32 bytes of data:

Reply from 194.219.252.147: bytes=32 time=51ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=62ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=62ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=849ms TTL=254    <--- DL: ~1.0 kB/sec / UL: 1.5 kB/sec
Reply from 194.219.252.147: bytes=32 time=2616ms TTL=254   <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Request timed out.                                         <--- DL: ~1.8-2.2 kB/sec / UL: 0-1 kB/sec
Reply from 194.219.252.147: bytes=32 time=3216ms TTL=254   <--- DL: 1.0 kB/sec / UL: 0-1 kB/sec
Reply from 194.219.252.147: bytes=32 time=61ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=62ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=62ms TTL=254     <--- IDLE
Reply from 194.219.252.147: bytes=32 time=62ms TTL=254     <--- IDLE

[trojy]

Η αναβάθμιση σε 512 είναι μία λύση. Δεν είναι η λύση στο πρόβλημα όμως.
Στην ενημέρωση που έχω δεν υπάρχει κάποιο QOS (Quality Of Service) που να εφαρμόζεται.
Είναι η 1η φορά που διαβάζω κάτι τέτοιο, και θα παρακαλούσα όποιον γνωρίζει κάτι για αυτό, να μου στείλει όσο το δυνατόν περισσότερες πληροφορίες μπορεί.

[psyxakias]

Όταν συμβαίνει το πρόβλημα, τα πακετά που στέλνω και λαμβάνω είναι UDP μεγέθους 44 bytes μαζί με τα headers (ή 16 bytes "καθαρά"), αν και άμα διαιρέσω τα bytes με τα pps δεν βγάζει ακριβώς 44 bytes (ίσως πρέπει να κάνω πιο ακριβείς μετρήσεις):

DL: 0.1 kB/sec (8 pps) / UL: 0.7 kB/sec (23 pps)
DL: 1.6 kB/sec (21 pps) / UL: 4.6 kB/sec (80 pps)
DL: 1.0 kB/sec (22 pps) / UL: 4.5 kB/sec (82 pps)
DL: 1.1 kB/sec (19 pps) / UL: 4.6 kB/sec (78 pps)
DL: 1.2 kB/sec (26 pps) / UL: 4.6 kB/sec (88 pps)
DL: 0.9 kB/sec (17 pps) / UL: 4.8 kB/sec (84 pps)
DL: 0.8 kB/sec (22 pps) / UL: 4.6 kB/sec (133 pps)
DL: 1.1 kB/sec (23 pps) / UL: 11.8 kB/sec (267 pps)
DL: 0.2 kB/sec (0 pps) / UL: 4.1 kB/sec (24 pps)
DL: 0.0 kB/sec (0 pps) / UL: 1.9 kB/sec (9 pps)
DL: 1.3 kB/sec (28 pps) / UL: 1.8 kB/sec (29 pps)
DL: 1.5 kB/sec (26 pps) / UL: 1.5 kB/sec (23 pps)
DL: 1.4 kB/sec (29 pps) / UL: 1.8 kB/sec (21 pps)
DL: 1.5 kB/sec (30 pps) / UL: 1.8 kB/sec (23 pps)
DL: 1.3 kB/sec (25 pps) / UL: 1.7 kB/sec (23 pps)
DL: 3.2 kB/sec (26 pps) / UL: 1.8 kB/sec (25 pps)
DL: 5.0 kB/sec (26 pps) / UL: 2.1 kB/sec (25 pps)
DL: 4.9 kB/sec (28 pps) / UL: 1.9 kB/sec (22 pps)
DL: 3.8 kB/sec (25 pps) / UL: 1.8 kB/sec (21 pps)
DL: 3.8 kB/sec (25 pps) / UL: 2.0 kB/sec (25 pps)
DL: 3.8 kB/sec (26 pps) / UL: 1.8 kB/sec (17 pps)

Εμένα γιατί μου φαίνεται σαν κόφτης στα pps;

[psyxakias]

Επειδή ίσως να μην έχω άλλη ευκαιρία για δοκιμή στην 384 γραμμή μου αφού περιμένω την αναβάθμισή σε 512, έκανα μια δοκιμή που κατά την γνώμη μου αποδικνύει την ύπαρξη packet-based ratelimiting:

1) Συνδέθηκα στο Internet από την ADSL αλλά και από ξεχωριστή ISDN σύνδεση για να μπορώ να έχω πρόβαση ακόμα και αν νεκρώσει η ADSL

2) Μπήκα σε έναν 100 Mbps server (από την ISDN) και έκανα ratelimit τα outgoing UDPs στο 1 Mbps

3) Άρχισα μαζική αποστολή UDP πακέτων προς την ADSL μου

4) Παράλληλα άνοιξα το το Performance των Windows και το windump, για να ελέγχο τα πακέτα που έρχονται στην ADSL και ιδού τα αποτελέσματα:

α) Test #1 => 10-bytes packets (38-bytes including overheads):
28 pps / 1285-1330 bytes/sec (minpps: 23, maxpps: 30)

β) Test #2 => 100-bytes packets (128-bytes including overheads):
29 pps / 3450-3570 bytes/sec (minpps: 22, maxpps: 30)

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

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

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

5) Όταν έπιανε τα 30 pps η ADSL, νέκρωνε, σταματούσα τα πακέτα από το server και ενώ η κάρτα δικτύου του server έδειχνε idle (είχαν φύγει ήδη τα πακέτα) χρειαζόταν 1-3 λεπτά για να σταματήσουν να έρχονται στην ADSL μου και να επανέλθει απ'το νέκρωμα, που σημαίνει ότι για να μην γίνονται drop τα πακέτα από το ratelimit, γίνονται queue ώστε να τα λάβω όλα έστω και με καθυστέρηση δευτερολέπτων/λεπτών.

Φαίνεται σαν να πρόκειται για για packet-based ratelimiting, δεν ξέρω που και γιατί αλλά πιστεύω πως ΑΥΤΟ είναι το πρόβλημά μας..

EDIT: διορθώθηκαν κάποια λαθάκια που είχα στις τιμές των bytes, αφού επανέλαβα τα tests και έβγαλα παρόμοια αποτελέσματα
EDIT2: Και φυσικά επειδή κανένα ratelimiting σύστημα δεν είναι τέλειο, υπήρχαν φορές που έκανε κάτι spikes σε 100 pps για 2-3 secs και επέστρεφε στα 28-30.
EDIT3: Τα παραπάνω tests έγιναν με ΟΤΕ 384 γραμμή και 384/128 σύνδεση FORTHnet.
EDIT4: Άλλαξα το bold message λίγο

[kaugummi]

Καταρχην αυτο που εχω να πω ειναι NO COMMENT....
Το μονο που θα σχολιασω ειναι οτι καμια εταιρια δεν θελει να εχει προβληματα..καμια εταιρια δεν θελει να την πριζουν καθε μερα οι συνδρομητες της...Επισης αν το προβλημα ηταν τοσο απλο (οσο υποστηριξε καποιος ..ο οποιος θα μπορουσε και να το λυσει ο ιδιος και μαλιστα ΜΟΝΟΣ ΤΟΥ..) θα ειχε ΗΔΗ λυθει..
Το link ειναι το εξης, (δεν το εβαλα τοτε γιατι νομιζα οτι το ειδαν..)

http://www.forthnet.gr/templates/sup...spx?c=10003817

υπενθυμιση:προσπαθω να δειξω another point of view...
και γω απλως ενας συνδρομητης ειμαι..

[trojy]

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

Από την αναβάθμιση του ΟΤΕ, και μετά, ΚΑΠΟΙΟΣ/ΚΑΠΟΥ/ΚΑΠΟΤΕ έβαλε όριο στα UDP πακέτα, στα 30 pps (δηλαδή 30 πακέτα ανά δευτερόλεπτο). Όποιος δηλώνει βλάβη πλέον, θα είναι καλύτερο να ενημερώνει και για αυτή την παράμετρο.

[psyxakias]

Καταρχην αυτο που εχω να πω ειναι NO COMMENT....
Το μονο που θα σχολιασω ειναι οτι καμια εταιρια δεν θελει να εχει προβληματα..καμια εταιρια δεν θελει να την πριζουν καθε μερα οι συνδρομητες της...Επισης αν το προβλημα ηταν τοσο απλο (οσο υποστηριξε καποιος ..ο οποιος θα μπορουσε και να το λυσει ο ιδιος και μαλιστα ΜΟΝΟΣ ΤΟΥ..) θα ειχε ΗΔΗ λυθει..
Το link ειναι το εξης, (δεν το εβαλα τοτε γιατι νομιζα οτι το ειδαν..)

http://www.forthnet.gr/templates/sup...spx?c=10003817

υπενθυμιση:προσπαθω να δειξω another point of view...
και γω απλως ενας συνδρομητης ειμαι..

Eπειδή τα τελευταία 2 μηνύματα είναι δικά μου (και παρεξηγώ έυκολα, χεχε ), θα μπορούσες σε παρακαλώ να μου πεις αν αναφέρεσαι σε εμένα όταν μιλάς για αυτόν τον "κάποιο"; Διότι ούτε είπα ότι το πρόβλημα είναι τόσο απλό, ούτε είπα ότι θα μπορούσα να το λύσω μόνος μου. Εκτός αν παρεξήγησα και δεν αναφέρεσαι σε μένα, οπότε ζητώ συγνώμη.

Επίσης, το URL που έδωσες του έριξα μια ματιά και στο δικό μου modem απλώς δίνει πληροφορίες δημιουργίας σύνδεσης στα XP, τίποτε παραπάνω οπότε δεν νομίζω πως πρόκειται για μία τόσο απλή λύση/ρύθμιση (μακάρι να ήταν). Γενικότερα νομίζω πως το πρόβλημα εστιάζεται καθαρά στον ΟΤΕ, ούτε στην FORTHnet, ούτε στους υπόλοιπους ISPs. Εντός ολίγου θα κάνω δοκιμές με άλλον ISP.

Edit: Τώρα κατάλαβα το λόγο που έδωσες το link, οι ρυθμίσεις που δίνουν είναι άσχετες.. απλά αναφέρουν εκεί το πρόβλημα για να είναι ενήμεροι οι συνδρομητές ότι το ψάχνουν, thanks και sorry αν παρεξήγησα το post σου αρχικά.

[cassidy]

psyxakia έχεις σκεφτεί πως τα max packets per second είναι ένα ακόμα σύμπτωμα κι όχι η αιτία;
Αν ήταν rate limiting (για να δώσουν προτεραιότητα σε κάποιους) γιατί το φαινόμενο εμφανίζεται σε κάποιες περιοχές και σε άλλες όχι;
Αυτά τα είχα αναφέρει και πριν δυο εβδομάδες αλλά δε φάνηκε να δίνει κανείς σημασία. Για όποιον παίζει online παιχνίδια είναι από τα πρώτα πράγματα που μαθαίνει.

http://www.adslgr.com/forum/showpost...91&postcount=6