Αυξηση ταχυτητας downloading απο remote servers κατα 60+%

[christos_swc]

Πριν απο λιγο καιρο ειχα εκφρασει μια απορια στο φορουμ γιατι οταν κατεβαζω ενα αρχειο συνηθως κατεβαινει στα 60-70KB/sec ενω λιγοι servers μου δινουν τη μεγιστη ταχυτητα στα 110KB/sec.
Εχω συνδεση στο 1 Mbit.
Απαντηση δεν πηρα περα απο το οτι καποιοι χρηστες ανεφεραν οτι το ιδιο συνεβαινε και σε αυτους.
Παρατηρησα επισης οτι κατεβαζα ενα αρχειο και επερνα ας πουμε 70 ταχυτητα ενω αν κατεβαζα 2 αρχεια ταυτοχρονα απο τον ιδιο server επερνα 55KB/sec στο καθενα και 110 στο συνολο.
Λοιπον τελικα ψαχνοντας στο internet και κανοντας μια απλη ρυθμιση στο tcp recieve window η ταχυτητα downloading πηγε στο 110 ασχετως απο που κατεβαζω.
Το προβλημα αφορουσε servers εκτος Ευρωπης οπου ο χρονος επικοινωνιας για τη συνεχιση και διατηρηση της συνδεσης ειναι πολυ μεγαλος λογω αποστασης.
H default ρυθμιση των windows xp για το tcp recieve window ειναι 17520 που σημαινει συνεχη διακοπη της συνδεσης για επικοινωνια με το μακρινο server.
Αυξανοντας την τιμη αυτη η ροη δεδομενων διακοπτεται πιο σπανια και η ταχητητα αυξανεται δραματικα.
Δεν ειχα πολυ χρονο να πειραματιστω αλλα βαζοντας τιμη 27000 ολα ειναι πια ρολοι και καθε αρχειο που κατεβαζω πια κατεβαινει σφαιρα απο οπου και αν ειναι με εξαιρεση βεβαια τους κορεσμενους servers.
Το πως ρυθμιζεται το TCP recieve window ειναι απλο και θα το γραψω αν υπαρχει ενδιαφερον εκτος αν κομιζω γλαυκας εις αθηνας και ολοι το ηξεραν εκτος απο εμενα.

[k_koulos]

εμένα θα με ενδιάφερε να δω τι ρυθμίσεις έκανες, και μάλιστα όχι εδώ αλλα στο κομάτι που αφορά τα windows tips !

[christos_swc]

Μπορεις να το κανεις χειροκινητα η αυτοματα.
Εγω επελεξα τον αυτοματο τροπο γιατι ειναι ο πιο απλος και ειναι αποτελεσματικος.
Χειροκινητα με ρυθμιση στη registry:
http://cable-dsl.home.att.net/#IncreasingWindow

Αυτοματα:
http://www.dslreports.com/tweakr/blo...inXP&via=pppoA
Επιλεξε download DRTCP, κατεβασε και τρεξε το.
Στην επιλογη tcp recieve window πρεπει να βαλεις τιμη μεγαλυτερη απο το 17520 που ειναι η αρχικη των windows xp.
Στα windows 98 ειναι ακομα χαμηλοτερη.
Εγω πειραματιστικα με λιγες μονο τιμες και το εχω βαλει 27000.
Κανε reboot τα windows και δοκιμασε το.

[janus700]

Κι εμένα θα με ενδιέφερε πως ακριβώς ρύθμισες αυτό που λες -δεν θα με πείραζε να απαντήσεις ακόμη κι εδώ.
(Απ' ότι υποθέτω ή πειράζεις manually την registry, ή έχεις έτοιμο κάποιο script γι' αυτό)

-Thanks in advance

[janus700]

Sorry, μόλις είδα ότι απάντησες ήδη
(υπάρχει και η συγχρονικότητα βλέπεις!!)
Thanks again

[christos_swc]

Εμενα αυτες οι ρυθμισεις ειχαν τοσο δραστικα αποτελεσματα που χτυπαω το κεφαλι μου στον τοιχο πως ειναι δυνατον να μην ειναι ευρεως γνωστες και σερνομουνα τοσο καιρο.
Ειναι νωρις ακομα αλλα αν αποδειχτει το ιδιο χρησιμο και για τους υπολοιπους οι mods μπορουν να το μεταφερουν οπου κρινουν σκοπιμο.
Εχουν δει πολλα τα ματια μου και εκει που ολα δειχνουν οτι βρηκα χρυσο αποδυκνειεται ανθρακες ο θυσαυρος αλλα so far so good.

[christos_swc]

Αποτελεσματα απο το http://www.speedtest.net/
με διαδοχικες μετρησεις σε τρεις κοντινους και τρεις μακρινους servers.
Τα αποτελεσματα σε kbit/sec download μονο:
Pvodiv (βουλγαρια)
763-881-884

Rome
883-885-885

Munich
883-880-873

Portland USA
626-620-623

Vancouver (canada)
793-793-797

Los Angeles(usa)
826-832-821

[agent]

Το να αυξήσει κανείς το TCP receive window κατά το δοκούν δεν είναι πανάκεια και μπορεί να δημιουργήσει περισσότερα προβλήματα από όσα ίσως λύσει σε κάποια μεμονωμένη περίπτωση. Το TCP όντας connection oriented protocol έχει μηχανισμούς που εξασφαλίζουν ότι τα δεδομένα που μεταφέρει μεταφέρονται σωστά (χωρίς αλλοιώσεις, χωρίς χαμένα πακέτα κλπ). Αυτή είναι και η μεγάλη διαφορά του από το άλλο ευρέως διαδεδομένο transport protocol, το UDP, το οποίο είναι connectionless protocol (δε δημιουργεί συνδέσεις για τη μεταφορά δεδομένων, απλά τα στέλνει).

Ένα από τους μηχανισμούς που χρησιμοποιεί το TCP για να εξασφαλίσει την επιτυχή αποστολή δεδομένων είναι το aknowledgment (ACK). Σύμφωνα με αυτό το μηχανισμό, τα δύο μέρη που συμμετέχουν σε ένα TCP session πρέπει να ενημερώνει το ένα το άλλο πως έλαβε σωστά το/τα πακέτα που στάλθηκαν. Εάν το ένα σύστημα στείλει ένα πακέτο και δε λάβει μέσα σε εύλογο χρονικό διάστημα το αντίστοιχο ACK πρέπει να το ξαναστείλει με το σκεπτικό πως για κάποιο λόγο δε παραδόθηκε σωστά.

Το πιο απλό που μπορεί να υλοποιηθεί είναι το κάθε σύστημα να κάνει aknowledge κάθε πακέτο που λαμβάνει. Αυτό φυσικά καταναλώνει υπερβολικά μεγάλο ποσοστό από το διαθέσιμο bandwidth - και αυτός είναι ο λόγος δημιουργίας της παραμέτρου receive window size. Αυτή η παράμετρος ορίζεται κατά τη δημιουργία της TCP σύνδεσης και δηλώνει το μέγιστο αριθμό bytes που μπορεί να λάβει ένα σύστημα πριν στείλει μήνυμα aknowledgment. Τα Window$ (μια και αναφερόμαστε συγκεκριμένα σε αυτά) υπολογίζουν το TCP receive window size βάσει του MSS (maximum segment size) το οποίο με τη σειρά του αναφέρεται στο μέγιστο αριθμό bytes πραγματικών δεδομένων που μπορεί να μεταφέρει ένα πακέτο TCP. Αυτός ο αριθμός εξαρτάται από το MTU (maximum transfer unit) το οποίο δηλώνει το μέγιστο μέγεθος ενός IP frame που μπορεί να αποσταλεί στο δίκτυο και εξαρτάται από το ίδιο το δίκτυο (ethernet, token ring κλπ). Ενδεικτικά το MTU για το ethernet είναι 1500 bytes. Ουσιαστικά το MSS ισούται με το MTU μείον τον αριθμό των bytes που απαιτούνται για τους headers του IP και του TCP, τα οποία συνήθως είναι γύρω στα 40 bytes συνολικά. Άρα μια μέση τιμή του MSS σε δίκτυο ethernet είναι 1460 bytes. Αυτή η τιμή πολλαπλασιασμένη επί 12 ισούται με 17520. Αυτό πρακτικά σημαίνει ότι ένα σύστημα Window$ είναι ρυθμισμένο by default να στέλνει ένα ACK για κάθε 12 πακέτα που λαμβάνει (το λέω πολύ απλουστευμένα, ισχύουν και άλλοι κανόνες).

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

Τι γίνεται τώρα αν υπάρχουν προβλήματα (όπως στιγμιαίες καθυστερήσεις στη διακίνηση των πακέτων, περιστασιακή αλλοίωση των περιεχομένων τους κλπ). Στη default τιμή, αν κάποιος χρησιμοποιεί Window$ και κατεβάζει ένα μεγάλο αρχείο από ένα server, το σύστημα του στέλνει ένα ACK για κάθε 12 πακέτα που λαμβάνει (υποθέτωντας ότι και τα δύο συστήματα χρησιμοποιούν ethernet). Επειδή το TCP receive window size είναι τιμή που έχει συμφωνηθεί μεταξύ των δύο συστημάτων κατά τη δημιουργία της σύνδεσης, ο server γνωρίζει ότι μπορεί να στείλει 12 πακέτα πριν σταματήσει για να περιμένει να λάβει ένα ACK. Εάν ο server δε λάβει ένα ACK μετά το 12ο πακέτο θεωρεί πως κάτι δε παραδώθηκε σωστά. Δεν έχει σημασία εάν υπήρξε πρόβλημα στη παράδοση κάποιου πακέτου με δεδομένα ή του ίδιου του ACK, ο server είναι υποχρεωμένος να ξαναστείλει τα δεδομένα. Επειδή δεν είναι δυνατόν να γνωρίζει σε ποιο πακέτο υπήρξε πρόβλημα, στέλνει ολόκληρη τη 12άδα. Άρα, όσο μεγαλύτερο είναι το TCP receive window size τόσο μεγαλύτερος είναι και ο όγκος των δεδομένων που θα ξανασταλούν στη περίπτωση προβλήματος.

Το να βρει κανείς τη βέλτιστη τιμή είναι πολύ δύσκολο ακόμη και για ένα κλειστό δίκτυο ethernet το οποίο δεν έχει links χαμηλού bandwidth με άλλα δίκτυα. Οι default τιμές που χρησιμοποιούνται από τα διάφορα λειτουργικά είναι κατά κανόνα ένας καλός συμβιβασμός για περιβάλλοντα 10/100Mbps (χωρίς ADSL, χωρίς WAN links με χαμηλότερο bandwidth κλπ). Αν σκεφθεί κανείς πως υπάρχουν και άλλοι παράμετροι (delayed aknowledgments, PMTU discovery κά) μπορεί να καταλάβει πόσο δύσκολο είναι να ορίσει κανείς τιμές σε σύγχρονα δίκτυα των 1Gbps/10Gbps, πόσο μάλλον σε ένα περιβάλλον από λογής-λογής δίκτυα όπως είναι το Internet.

[christos_swc]

Ειναι γνωστο οτι ολα εχουν τα ορια τους αλλοιως θα εδινα μια τιμη στο tcp recieve window κανα εκατομμυριο και θα τελειωναμε.
Ισως πραγματι μιλαμε για αυξηση κατα το δοκουν ομως αρκετα συντηρητικη εν τελει.
Ο τροπος υπολογισμου της θεωρητικα τελειας τιμης για το tcp recieve window ειναι εξαιρετικα πολυπλοκος και αναξιοπιστος μιας και δεν ειναι ακριβης επιστημη (μια απο τις αρκετες παραμετρους υπολογισμου για παραδειγμα ειναι η μεση τιμη του πινγκ σου)και σε καθε περιπτωση δινει υψηλοτερες τιμες απο αυτη που χρησιμοποιω.
Απο τα λεγομενα σου φαινεται οτι χρηση υπερβολικα υψηλης τιμης θα ειχε ως αποτελεσμα σε καποιες περιπτωσεις χαμηλοτερη τελικα ταχυτητα αφου ο server θα ξαναστελνε τα πακετα δυο φορες.
Αυτο ομως ισχυει σε περιπτωση προβληματος οπως λες και εσυ.
Το προβλημα δεν ειναι η ληψη corrupted files με αποτελεσμα το download να πηγαινει χαμενο αλλα η καθυστερηση στην ολοκληρωση ληψης του αρχειου αντι για την επιταχυνση του επειδη σε περιπτωση χαμενου packet πρεπει να ξανασταλει ολοκληρη σειρα πακετων, η τουλαχιστον αυτο καταλαβαινω απο τα λεγομενα σου.
Μια λογικη αυξηση της τιμης του tcp recieve window δε σημαινει απαραιτητα και προβλημα.
Ποσα αληθεια χαμενα packets εχεις κατα τη διαρκεια downloading?
O τελικος κριτης λοιπον απο'τι καταλαβαινω ειναι η ταχυτητα.
Και η ταχυτητα μου στο downloading απο Ευρωπαικους servers αυξηθηκε απο τα 107-108 στα 110KB/sec και απο μακρινους servers απο 65-70 στα 100-110.
Η αυξηση που υπαρχει στην ταχητητα ληψης απο μακρινους servers υπερκαλυπτει ακομα και τη στιγμιαια πτωση ταχυτητας απο χαμενα πακετα.
Οσον αφορα τους κοντινους servers χρειαζεται λιγος χρονος για να δω κατα ποσο η ταχυτητα αυτη ειναι σταθερη η υπαρχουν στιγμιαιες πτωσεις και να συγκρινω με πριν.
Το ntua ειναι κοντινος server με τεραστια αρχεια οποτε μπορω να τα κατεβασω με τις δυο διαφορετικες ρυθμισεις και να συγκρινω και βλεπουμε.
Για την ωρα παντως ξαναπηγαινω στις ιστοσελιδες που μου σπαγανε τα νευρα και κατεβαζω με κατι κατοσταρες γιανα βγαλω το αχτι μου!

[christos_swc]

Οριστε οι τελευταιες και τελικες μου μετρησεις και απο εκει και περα ο καθενας αποφασιζει.

Μετρηση ταχυτητας στο http://www.speedtest.net/
σε μακρινο server(Los Angeles)

TCP RECEIVE WINDOW / SPEED(kbits/sec)
17520(default) / 570
19000 /695
20000 /650
21600 /714
23200 /762
24800 /736
26280 /834
27880 /884

Κατεβασμα 5MB απο αρχειο στο ftp-ntua απο μακρινο server(Indiana)

TCP RECEIVE WINDOW /average speed(KB/sec)
17520 / 75,6
19000 /75,8
20000 /75,1
21600 /75,8
23200 /87,3
24800 /87,9
26280 /87,8
27880 /96,8

Κατεβασμα 8MB απο αρχειο της ATI (προφανως μεσω καποιου Ευρωπαικου server)

TCP RECEIVE WINDOW /SPEED(KB/sec)
17520 /109
19000 /109
20000 /109
21600 /109
23200 /109
24800 /109
26280 /108
27880 /110

Μετρηση αξιοπιστιας σε κοντινο server.
Κατεβασμα αρχειου 350 MB απο ftp-ntua απο κοντινο server(Munich)
Μεση ταχυτητα 109ΚΒ/sec

Η default τιμη των windows ειναι ιδανικη για κοντινους server και συνδεση 1mbit
H αυξηση της αυξησε την ταχυτητα σε μακρινους servers χωρις να μειωσει την ταχυτητα σε κοντινους, μεχρι την τιμη που δοκιμασα.
Η σωστη τιμη εξαρταται απο την ταχυτητα της συνδεσης, για μια συνδεση 2Mbit πρεπει να ειναι πολυ υψηλοτερη.

[yiapap]

http://www.adslgr.com/forum/showthread.php?t=1675 (6/9/2003 !)
http://www.adslgr.com/forum/showthread.php?t=25599
Το θέμα έχει αναλυθεί εκτενώς. Αν κάποιος δεν ξέρει ΑΚΡΙΒΩΣ γιατί πειράζει αυτές τις ρυθμίσεις, τότε είναι καλύτερα να ΜΗΝ τις πειράξει.
Ενδεικτικά αναφέρω ότι η αύξηση του RWIN συχνά οδηγεί σε μείωση των επιδόσεων εφόσον στη γραμμή υπάρχουν πολλά σφάλματα, όταν υπάρχουν πολλά μικρά πακέτα (π.χ. p2p) ή όταν η απόκριση (latency) είναι πρώτης προτεραιότητας (online gaming, remote desktop κτλ.)

[deniSun]

http://www.adslgr.com/forum/showthread.php?t=1675 (6/9/2003 !)
http://www.adslgr.com/forum/showthread.php?t=25599
Το θέμα έχει αναλυθεί εκτενώς. Αν κάποιος δεν ξέρει ΑΚΡΙΒΩΣ γιατί πειράζει αυτές τις ρυθμίσεις, τότε είναι καλύτερα να ΜΗΝ τις πειράξει.
Ενδεικτικά αναφέρω ότι η αύξηση του RWIN συχνά οδηγεί σε μείωση των επιδόσεων εφόσον στη γραμμή υπάρχουν πολλά σφάλματα, όταν υπάρχουν πολλά μικρά πακέτα (π.χ. p2p) ή όταν η απόκριση (latency) είναι πρώτης προτεραιότητας (online gaming, remote desktop κτλ.)

Συμφωνώ απόλυτα

[christos_swc]

Ενα απλο search στο Google δινει απειρες πληροφοριες για το tcp receive window και τους "κινδυνους" που κρυβει και τι να κανει.
Οποιος δεν εχει τη διαθεση να το ψαξει η την εμπειρια απο υπολογιστες να εκτιμησει τα αποτελεσματα σιγουρα τωρα εχει τρομαξει και λεει αστο καλυτερα λες και θα κανει ζημια στο PC του.
Παντως εγω με τις τελευταιες ρυθμισεις που εγραψα τωρα κατεβαζω πια στο 1Mbit απο το 90% των ιστοσελιδων αντι για το 20% που κατεβαζα πριν.
Τα αρχεια κατεβαινουν πλεον full speed.Αλλο 70 , αλλο 110 , σα να εχεις αλλη συνδεση.
Το τιμημα?
Δεν το εχω δει.
Και μια χαρα συνεχιζω να ανεβοκατεβαζω με το μtorrent.
Το χειροτερο που μπορει να συμβει αν καποιος κανει κουλουβαχατο τη ρυθμιση στο tcp receive window γιατι δεν εχει ιδεα τι κανει ειναι να χειροτερεψει την ταχυτητα του και τιποτε αλλο και μπορει να επαναφερει τη default ρυθμιση οποτεδηποτε θελει.
Μιλαμε για μια και μονο παραμετρο και οχι 100 σα να ρυθμιζεις το router σου οπου θα τα καναμε μουσκεμα οι περισσοτεροι απο εμας καποια στιγμη.
Εχω ειδη παραθεσει το σχετικο προγραμματακι που πολυ απλα και ευκολα δινει διαφορετικες τιμες χωρις χειροκινητες επεμβασεις στη registry.
Αν διαβασετε στο ιντερνετ θα δειτε ολες τις τεχνικες ιστοσελιδες να γραφουν οτι ειναι η μονη παραμετρος που αξιζει να ασχοληθει κανεις για να βελτιστοποιησει την ταχυτητα του και σε τελικη αναλυση αυτο ψαχνουμε και δε μιλαμε για ψιλοδιαφορες.
Ποσοι χρηστες εχουν συνδεση στα 2Mbit και δεν πιανουν στις περισσοτερες ιστοσελιδες ουτε τη μιση τους ταχυτητα;
Για ριξτε μια ματια στον πινακα που λεει bandwidth delay estimate http://www.dslreports.com/tweaks/RWIN
Αυτο το ποστ δεν απευθυνεται σε αρχαριους χρηστες αλλα σε προχωρημενους χρηστες υπολογιστων σαν και την παρτη μου που ομως παραμενουν ανυποψιαστοι σε πολλα πραγματα λογω ελλειψης χρονου και βομβαρδισμου πληροφοριων.
Αν τωρα αυτα φανταζουν ψιλα γραμματα δεν τρεχει τιποτα ο καθενας ας κανει οτι θελει.
Αν εστω και ενας ψαχτηκε η ωφεληθηκε απο αυτο το ποστ τοτε θεωρω οτι καλως γραφτηκε και ας εχει ξαναγραφτει δυο φορες και εχει χαθει στο φορουμ.
Αν καποιος επαθε ζημια απο αυτο ας το γραψει να του ζητησω συγνωμη και να τη διορθωσουμε.
Πως;
Επαναφεροντας τη default ρυθμιση των windows.
Πυροσβεστηρας δε θα χρειαστει

[Parrot]

Αγαπητε φιλε christos_swc, και εγω ανηκω στους power users και ομολογω οτι το θεμα που εθιξες δεν το γνωριζα!

Ομολογω οτι αυτα που εγραψες ηταν διαφωτιστικα και με βλεπω να πειραματιζομαι συντομα για να καταθεσω και εγω τις παπαγαλισιες αποψεις μου Και προτεινω και οποιος αλλος ασχοληθηκε να γραψει τι του συνεβηκε (εκτος φυσικα οτι εκαψε το PC του)

Αλλα αυτο που εχει πρωτιστως σημασια, ειναι οτι αυτη την ρυθμιση την πειραζει οποιος θελει με ΑΠΟΛΥΤΩΣ δικη του ευθυνη!

[yiapap]

Διαβάστε τουλάχιστον το 2ο link που παρέθεσα. Έχει και άλλες ρυθμίσεις εκτός του RWIN