Κατεβάζοντας torrents σέρνεται το ίντερνετ μέσω περιηγητή

[Γιώργος Φιωτάκης]

Δεν είμαι και ο πλέον κατάλληλος για να βοηθήσω στην επίλυση θεμάτων torrent client αλλά θα συμφωνήσω με τον medigeek στο κομμάτι που λέει ότι το πρόβλημα δημιουργείται λόγω πολλών ταυτόχρονων συνδέσεων.
Διαφωνώ όμως ως προς το ότι είναι θέμα ρυθμίσεων του router αφού στην πρώτη δημοσίευση αναφέρεται ότι σε windows δεν υφίσταται το πρόβλημα και κάπου στη δεύτερη σελίδα επίσης αναφέρεται ότι με τις προτεινόμενες ρυθμίσεις του ktorrent υπάρχει σαφής βελτίωση.

Αυτό που απομένει είναι οι ρυθμίσεις του transmission.

Δεν μπόρεσα να βρω πληροφορίες για τον μέγιστο ονομαστικό ρυθμό αποστολής που δίνει η γραμμή σου, αλλά ούτως ή άλλως αυτός δεν είναι απόλυτος ούτε σταθερός πάντα και επιπλέον αν το ConneX έχει κάτι σαν turboboost ούτε το speedtest θα σου δώσει μέτρηση με ακρίβεια (αν χρησιμοποιεί turboboost, υπολόγισε ότι η πραγματική σου ταχύτητα είναι στο 60% της μέτρησης αυτής).
Ένας γενικός κανόνας για την αναλογία αποστολής/διαθέσιμο εύρος αποστολής είναι ότι δεν θα πρέπει να ξεπερνάει συνολικά το 10% (δηλαδή όλες οι αποστολές, όχι 10% για κάθε ένα αρχείο torrent).
Στις ρυθμίσεις του ktorrent που υπάρχουν στη δεύτερη σελίδα αυτός ο κανόνας τηρείται αλλά πιθανότατα να μην αναγνωρίζεται σωστά το διαθέσιμο εύρος (να βλέπει δηλαδή 40% μεγαλύτερη ταχύτητα όπως είπα πιο πάνω)
Επίσης όταν περνάς ρυθμίσεις, θα πρέπει να προσέξεις τη διαφορά ανάμεσα σε kb (kilobit) και kB (kilobyte).

Μερικά εργαλεία που ίσως σε βοηθήσουν να βρεις τις πιο κατάλληλες ρυθμίσεις:

1) iptraf
Αφού το εγκαταστήσεις (sudo apt-get install iptraf) το τρέχεις πάλι με sudo και χωρίς να τρέχεις οτιδήποτε άλλο που να δημιουργεί κίνηση στο δίκτυο.
Αυτό που σε ενδιαφέρει είναι οι πληροφορίες που θα σου δίνει από το Detailed Interface Statistics για τη σύνδεση σου (wlan0 υποθέτω αφού είσαι σε ασύρματο) και πιο συγκεκριμένα το outgoing rates.
Αρχικά δοκίμασε να κατεβάσεις από τον firefox κάποιο .iso που είναι αρκετά μεγάλο για να σου δώσει μια αξιόπιστη μέτρηση μεσα σε 5-10 λεπτά.
Αφού σταματήσεις το κατέβασμα, κλείσεις τον Firefox και πέσει ο ρυθμός αποστολής που δίνει στο 0, άνοιξε το transmission κι άφησε το λίγο να δουλέψει για να δεις τι ρυθμούς αποστολής δίνει.

2) Αφού πάρεις μια ιδέα για το τι παίζει με τις ταχύτητες που πιάνεις και που χρησιμοποιεί το transmission, πήγαινε στη σελίδα με τον υπολογιστή των ρυθμίσεων του Azureus. Οι ρυθμίσεις που προτείνει με βάση την ταχύτητα που θα του δώσεις είναι αρκετά αξιόπιστες και συνήθως δουλεύουν σε όλους τους torrent client.

3) Αν χρειαστεί να κάνεις μετατροπές σε διαφορετικές μονάδες μέτρησης, μπορείς να βρεις αρκετά βοηθήματα όπως αυτό ή αυτό.

[Χανδόλιας Νίκος]

Δεν ξέρω αν μου διέφυγε κάπου, αλλά ποιο router χρησιμοποιείς; Με το THOMSON TG585 v7, ενσύρματη σύνδεση, Ubuntu 11.04 και Transmission τα πάντα λειτουργούν άψογα. Καταρχάς, κατά τη γνώμη μου απενεργοποίησε το UpnP, τόσο στο router όσο και στο Transmission και προτίμησε να ορίσεις στο router χειροκίνητα θύρα που θα χρησιμοποιείς. Αν μπορείς δοκίμασε και κάποιο άλλο router, για να αποκλείσεις την πιθανότητα (αν και μικρή, αφού στα win λειτουργεί σωστά) προβληματικού router. Στο θέμα των συνδέσεων δεν υπάρχει κανένας λόγος να τις έχεις τόσο χαμηλές, εγώ έχω αριθμό συνδέσεων 300 σε κάθε torrent και συνολικά 10 ενεργά τορρεντ με 24αρα σύνδεση, με το DL στο 1mb/s και το UL στα 80kb/s και χωρίς κανένα θέμα στο browsing. Αν και με άλλο router έχεις θέμα, τότε πρέπει να κοιτάξουμε και αλλού, ίσως σε σκληρό.

[filippos.xf]

Καλησπέρα και ευχαριστώ για τις απαντήσεις σας. Πριν κάνω οτιδήποτε θα ήθελα να δείτε τις παρακάτω πληροφορίες.

• Το Transmission δεν είναι η μοναδική εφαρμογή που έχω δοκιμάσει. Σε Kubuntu χρησιμοποιούσα Ktorrent, τώρα στο Ubuntu έχω εγκατεστημένο και το Deluge.
• Δεν έχω πλέον dual boot, έχω μόνο Ubuntu. Άρα "δυστυχώς" στην προκειμένη περίπτωση, δεν μπορώ να ελέγξω πως θα λειτουργούσε ένας torrent client στα Windows. Όσες φορές δοκίμασα σε Windows όμως δεν υπήρχε πρόβλημα, εκεί χρησιμοποιούσα το μTorrent/uTorrent. Χωρίς να λέω ότι κατέβαζα με 1mb το δευτερόλεπτο δίχως να έβλεπα κάποιο σύρσιμο στον Firefox, ωστόσο δεν θυμάμαι να έβγαζε σφάλμα τύπου σφάλμα σύνδεσης κτλ. Στα Windows μπορεί να κατέβαζα π.χ. με 500 KiB/s και όταν έκανα ανανέωση μια σελίδα στον Firefox, φόρτωνε κανονικά κι ας αργούσε ελάχιστα. Σε Linux με το πρόβλημα που έχω μπορεί στο Transmission να κατεβάζω με 30 KiB/s, ωστόσο αν κάνω ανανέωση μια σελίδα στον Firefox να μου βγάλει σφάλμα σύνδεσης και ανανέωση δεν θα γίνει ποτέ.
• Δεν ξέρω πως και γιατί, αλλά τελευταία παρατηρώ μια ελάχιστη βελτίωση στο πρόβλημα. Τουλάχιστον τώρα μπορεί στο Transmission να κατεβάζω με 300 KiB/s, να πατήσω στον Firefox ανανέωση σε μια καρτέλα και να γίνει η ανανέωση έστω με κάποια καθυστέρηση. Βέβαια δεν νιώθω να έχει διορθωθεί το πρόβλημα εντελώς, πιστεύω παραμένει ακόμα. Σίγουρα δεν είναι αυτή η κατάσταση φυσιολογική, θα περίμενα κάτι καλύτερο.
• Το βράδυ που μας πέρασε έκανα κάποιες δοκιμές. Εγκατέστησα το gufw για ρύθμιση Firewall και έβαλα rule για το Transmission, είδα ότι το καταχώρησε με το port 51413. Μετά έβαλα αυτό το port και στο Transmission.
• Κάτι άλλο που αξίζει να αναφέρω είναι ότι φόρτωσα στο Transmission διάφορα torrents, ένα από αυτά είναι το Ubuntu από την σελίδα του Ubuntu. Μόλις τώρα δοκίμασα να σταματήσω ότι άλλο torrent έχω φορτωμένο στο Transmission και έκανα εκκίνηση στο Ubuntu για να κατεβαίνει. Επίσης έβγαλα εντελώς το όριο που είχα στο κατέβασμα. Το αποτέλεσμα ήταν το download μου να φτάσει γύρω στο 1 mb το δευτερόλεπτο και να μπαινοβγαίνω σε ιστοσελίδες στον Firefox κανονικά, βέβαια δεν φόρτωναν σφαίρα οι σελίδες και αυτό είναι λογικό. Θέλω να πω όμως ότι βλέπω διαφορά σε σχέση του torrent του Ubuntu με τα υπόλοιπα torrents.
• Εδώ και πολύ καιρό κατεβάζω torrents από συγκεκριμένες σελίδες και σε Windows δεν υπάρχει πρόβλημα. Σε Linux δεν μπορώ να καταλάβω, μια έχω πρόβλημα μια δεν έχω. Βέβαια πολλά παίζουν ρόλο.
• Το router που έχω είναι αυτό: Ασύρματο Router BaudTec PSTN / TW263R4-A2
• Αν και δεν έχω πολλές γνώσεις γύρω από το θέμα, δεν μπορώ να καταλάβω για ποιον λόγο μπορεί να έχει πρόβλημα το Router. Το πρόβλημα με το οποίο έχουμε να κάνουμε σε Windows δεν το έβλεπα, αλλά και σε Linux ανά περιόδους απ' όσο θυμάμαι κατέβαζα κανονικά. Ίσως οφείλεται το πρόβλημα σε ρυθμίσεις, τώρα που ακριβώς και ποια ρύθμιση φταίει δεν ξέρω.
• Δεν έχω δεύτερο router για να κάνω δοκιμές και αυτήν την περίοδο δεν μπορώ να πάρω κάποιο νέο. Αν όμως επιμένετε στο να κάνω δοκιμές με ένα δεύτερο router, ξέρω από που να βρω ένα για να κάνω δοκιμές, δεν θα μπορώ όμως να το έχω συνέχεια εδώ.

[medigeek]

Αρχισε να κατεβάζεις από torrent και μολις σου παρουσιαστεί το πρόβλημα, δώσε το αποτέλεσμα των εντολών:

Κώδικας: Επιλογή όλων

ping -s 1472 -M do -c 5 www.google.com
sleep 5
ping -s 1440 -M do -c 5 www.google.com
sleep 5
ping -s 1400 -M do -c 5 www.google.com
sleep 5
ping -c 5 -M do www.google.com
sleep 5
ping -c 5 www.google.com
ifconfig


Χρειάζομαι το αποτέλεσμα του ifconfig για να δω το MTU και το local ip. Μην το βάλεις με αστεράκια.
Πηγή: http://www.dslreports.com/faq/695

[filippos.xf]

Κώδικας: Επιλογή όλων

[code]$ ping -s 1472 -M do -c 5 www.google.comPING www.l.google.com (173.194.66.105) 1472(1500) bytes of data.

--- www.l.google.com ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4023ms

$ sleep 5
$ ping -s 1440 -M do -c 5 www.google.comPING www.l.google.com (173.194.66.104) 1440(1468) bytes of data.
72 bytes from we-in-f104.1e100.net (173.194.66.104): icmp_req=1 ttl=47 (truncated)
72 bytes from we-in-f104.1e100.net (173.194.66.104): icmp_req=2 ttl=47 (truncated)
72 bytes from we-in-f104.1e100.net (173.194.66.104): icmp_req=3 ttl=47 (truncated)
72 bytes from we-in-f104.1e100.net (173.194.66.104): icmp_req=4 ttl=47 (truncated)
72 bytes from we-in-f104.1e100.net (173.194.66.104): icmp_req=5 ttl=47 (truncated)

--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 75.457/124.421/315.537/95.565 ms
$ sleep 5
$ ping -s 1400 -M do -c 5 www.google.comPING www.l.google.com (173.194.66.147) 1400(1428) bytes of data.
72 bytes from we-in-f147.1e100.net (173.194.66.147): icmp_req=1 ttl=47 (truncated)
72 bytes from we-in-f147.1e100.net (173.194.66.147): icmp_req=2 ttl=47 (truncated)
72 bytes from we-in-f147.1e100.net (173.194.66.147): icmp_req=3 ttl=47 (truncated)
72 bytes from we-in-f147.1e100.net (173.194.66.147): icmp_req=4 ttl=47 (truncated)
72 bytes from we-in-f147.1e100.net (173.194.66.147): icmp_req=5 ttl=47 (truncated)

--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 265.034/300.699/331.476/22.302 ms
$ sleep 5
$ ping -c 5 www.google.com
PING www.l.google.com (173.194.66.99) 56(84) bytes of data.
64 bytes from we-in-f99.1e100.net (173.194.66.99): icmp_req=1 ttl=47 time=65.8 ms
64 bytes from we-in-f99.1e100.net (173.194.66.99): icmp_req=2 ttl=47 time=70.6 ms
64 bytes from we-in-f99.1e100.net (173.194.66.99): icmp_req=3 ttl=47 time=85.9 ms
64 bytes from we-in-f99.1e100.net (173.194.66.99): icmp_req=4 ttl=47 time=73.8 ms

--- www.l.google.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4005ms
rtt min/avg/max/mdev = 65.865/74.088/85.937/7.417 ms
$ <abbr title='Βλέπουμε πληροφορίες για τις συνδέσεις δικτύου.'>ifconfig</abbr>
eth0 Link encap:Ethernet HWaddr
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:47

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:212 errors:0 dropped:0 overruns:0 frame:0
TX packets:212 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18322 (18.3 KB) TX bytes:18322 (18.3 KB)

wlan0 Link encap:Ethernet HWaddr
inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::f27b:cbff:fe11:9b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5214791 errors:0 dropped:0 overruns:0 frame:0
TX packets:3523887 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6563202330 (6.5 GB) TX bytes:670171395 (670.1 MB)

$
[/code]

[medigeek]

Δοκίμασε να θέσεις το MTU στο wireless μέσω του "network connections" ( nm-connection-editor ). Επιλέγεις wireless > τη συσκευή σου και Edit. Είναι στην πρώτη ταμπέλα το MTU. Δοκίμασε "1450". Αποθήκευσε τις αλλαγές.
Ξεκίνα ξανά το network manager - στο εικονίδιο του network-manager > enable networking (για να το απενεργοποιήσεις/ξετικάρεις) και ξανά το ίδιο για να το ενεργοποιήσεις/τικάρεις.

Κοίταξε αν άλλαξε το MTU που αναφέρει το ifconfig στο wlan0:

Κώδικας: Επιλογή όλων

ifconfig|grep --color=auto -E 'MTU:[^ ]*|$'

Για να επαναφέρεις το "automatic" στο MTU, το θέτεις "0".

Τώρα δοκίμασε να προκαλέσεις το πρόβλημα ξανά και δες αν δουλεύει. Η σύνδεσή σου με 1450 MTU ("packet size") πρέπει να είναι λίγο πιο σταθερή. Αν δεν λυθεί με αυτό, μένω χωρίς άλλες εισηγήσεις..

[Γιώργος Φιωτάκης]

Οκ, τώρα θα πατήσω πόδι!
Από τα δεδομένα του Φίλιππου, φαίνεται ότι υπάρχει κατά διαστήματα απώλεια εισερχομένων πακέτων (φαντάζομαι ότι τις δεδομένες χρονικές στιγμές το transmission έψαχνε για ιχνηλάτες - πράγμα που το κάνει να συμπεριφέρεται εξαιρετικά επιθετικά), χωρίς όμως να υπάρχουν σφάλματα ή συγκρούσεις στη σύνδεση.
Αυτό από μόνο του νομίζω πως αποκλείει την περίπτωση προβλημάτων στη διασύνδεση του router ή του υπολογιστή με το router.

Μπορεί να βελτιώσει την κατάσταση η μείωση του MTU; (ρητορική η ερώτηση και απαντώ αμέσως)
Θεωρητικά (και ίσως - ίσως πρακτικά) ναι, από τη στιγμή που τα πακέτα θα είναι μικρότερα και άρα τουλάχιστον θεωρητικά θα χωρούν περισσότερα στο ίδιο διαθέσιμο εύρος.
Το πιθανότερο όμως είναι ότι ακόμα και με μικρότερα πακέτα, το transmission θα προσπαθήσει να εκμεταλλευτεί όλο το διαθέσιμο εύρος και πάλι, οπότε θα εκμηδενίσει το όποιο κέρδος μπορεί να υπάρξει.
Μπορεί η αλλαγή του MTU να έχει επιπτώσεις άλλου; (και πάλι ρητορική η ερώτηση)
Η μείωση του MTU θα δώσει μεγαλύτερη σταθερότητα και ταχύτητα αφού τα πακέτα θα είναι μικρότερα. Ταυτόχρονα όμως θα μειώσει τις πληροφορίες που αυτά περιέχουν οπότε μπορεί σε κάποια στιγμή να προκαλέσει μεγαλύτερη απώλεια ταχύτητας σε «φορτωμένους» διακομιστές που θα ζητάνε περισσότερες πληροφορίες για πακέτα που χάσανε και θα πρέπει να τα στείλει ξανά το σύστημα ολόκληρα.

Και στις δυο περιπτώσεις νομίζω πως σε μια 24 γραμμή δεν έχει και τόσο μεγάλη σημασία.

Σε γενικές γραμμές δεν πρέπει να αντιμετωπίζει πρόβλημα ένα σύστημα με τέτοια γραμμή και MTU 1500 αφού το εύρος είναι αρκετό για τη μεταφορά τους.
Επιμένω ότι το πρόβλημα σου ξεκινάει από το γεγονός ότι το transmission εξαντλεί όλο το διαθέσιμο εύρος όταν τρέχει.
Το πιθανότερο μάλιστα είναι ότι αν το διαθέσιμο εύρος που του ορίζεις (ή που αναγνωρίζει αυτό αν δεν το έχεις ορίσει εσύ) ξεπερνάει το πραγματικά διαθέσιμο της γραμμής σου, συμπεριφέρεται σαν να μην υπάρχει άνω όριο και καλύπτει το 100% και σε αποστολές και σε λήψεις.

[filippos.xf]

.

[Γιώργος Φιωτάκης]

Δεν κατάλαβα γιατί ψάχνεις να βρεις πόσο θα βάλεις, αυτές τις τιμές της εικόνας δεν στις δίνει ο υπολογιστής του azureus σαν βέλτιστες/προτεινόμενες;
Επίσης, από τη δεύτερη εικόνα που παραθέτεις (και αν φυσικά δεν εφαρμόζεις όρια αποστολής στο transmission ), φαίνεται ότι το εύρος αποστολής είναι μικρότερο του 50kB/s