Μου έχει τύχει ορισμένες φορές να μην ολοκληρώνεται η φόρτωση του Writer (OpenOffice) σε fat clients. Συγκεκριμένα, προβάλεται η splash οθόνη του αλλά σε κάποιο σημείο η εφαρμογή crashάρει. Το φαινόμενο κάνει την εμφάνισή του τυχαία και λύνεται πάντα με επανεκκίνηση.
Σήμερα μου συνέβη σε ώρα που δεν είχα μάθημα κι έτσι είχα την ευκαιρία να κοιτάξω το /var/log/syslog, το οποίο κατέληγε με τις εξής γραμμές:
Oct 13 18:17:27 goodie06 kernel: [ 1198.213149] SQUASHFS error: zlib_inflate error, data probably corrupt
Oct 13 18:17:27 goodie06 kernel: [ 1198.213154] SQUASHFS error: squashfs_read_data failed to read block 0x2fa2b525
Oct 13 18:17:27 goodie06 kernel: [ 1198.213156] SQUASHFS error: Unable to read fragment cache entry [2fa2b525]
Oct 13 18:17:27 goodie06 kernel: [ 1198.213158] SQUASHFS error: Unable to read page, block 2fa2b525, size b05d
Υποθέτω ότι πρόκειται για κάποιο προσωρινό πρόβλημα με τον εικονικό δίσκο, αλλά από κει και πέρα...
Τρεις λόγους έχω δει για το προκαλούν αυτό,
1) Πρόβλημα στην καλωδίωση του εργαστηρίου.
2) Να μην υπάρχει το nbd_proxy=false στο pxelinux.cfg/default (το βάζουν αυτόματα τα sch-scripts).
3) Προβληματικός driver της κάρτας δικτύου.
Για πιο γρήγορη αναπαραγωγή του προβλήματος, ώστε να δεις αν λύθηκε ή όχι, υποθέτω ότι μπορείς να κάνεις ένα copy του εικονικού δίσκου ενώ κάθεσαι σε κάποιον fat client (π.χ. με rsync -an /rofs /tmp), έτσι θα φανεί αμέσως αν συμβαίνει ακόμα το πρόβλημα ή όχι.
Έχω ακούσει επίσης ότι μπορεί να φταίει η συμπίεση που γίνεται στο squashfs image, την οποία και μπορείς να απενεργοποιήσεις από το /etc/ltsp/ltsp-update-image.conf, αλλά δεν το έχω δει να συμβαίνει ποτέ και πιστεύω ότι η απενεργοποίησή της απλά κρύβει όποιο πραγματικό πρόβλημα υπάρχει από τα τρία παραπάνω.
Παράθεση από: alkisg στις 14 Οκτ 2010, 09:24:51 ΠΜ
Τρεις λόγους έχω δει για το προκαλούν αυτό,
1) Πρόβλημα στην καλωδίωση του εργαστηρίου.
2) Να μην υπάρχει το nbd_proxy=false στο pxelinux.cfg/default (το βάζουν αυτόματα τα sch-scripts).
3) Προβληματικός driver της κάρτας δικτύου.
Άλκη, σ' ευχαριστώ. Επειδή έχω κάποιες υποψίες* για το (1), γνωρίζεις κάποιο διαγνωστικό που θα μπορούσα να κάνω;
* παλιότερα έκανα cloning κάποιων μηχανημάτων μέσω δικτύου, χρησιμοποιώντας το trinity rescue kit και ανέφερε συνεχώς προβληματικά πακέτα.
Το σωστό θα ήταν αυτός που έκανε την εγκατάσταση του εργαστηρίου να το είχε ελέγξει με cable tester (http://en.wikipedia.org/wiki/Cable_tester) από άκρη σε άκρη.
Δες αν έχει να σου δανείσει cable tester το ΚΕΠΛΗΝΕΤ σου ή το κέντρο δικτύων της περιοχής σου.
Αλλιώς, για software testing, δεν έχω κάτι συγκεκριμένο να προτείνω, θα μπορούσες ίσως να βάλεις το δίκτυο να παίζει full π.χ. με το iperf και να δεις τα στατιστικά του tcp για dropped frames κτλ.
(http://images.e-shop.gr/images/PER/BIG/PER.751549.jpg) (http://www.e-shop.gr/show_per.phtml?id=PER.751549)
Σ' ευχαριστώ.
Ίσως το μονάδικό μου πρόβλημα αυτή τη στιγμή στο εργαστήριο είναι η περίεργη συμπεριφορά των fat clients
μερικές φορές. Προβλήματα όπως η αδυναμία login στο ldm, η μη-ολοκλήρωση της εκκίνησης μερικών εφαρμογών και αρκετά άλλα μικροπροβλήματα.
Κοιτάζοντας την έξοδο του dmesg βλέπω ότι σε όλους αυτούς τους clients εμφανίζονται μηνύματα λάθους για το squashfs (έχω γράψει σχετικά στο https://alkisg.mysch.gr/steki/index.php?topic=3325.msg33431#msg33431 (https://alkisg.mysch.gr/steki/index.php?topic=3325.msg33431#msg33431) αλλά δεν ξέρω κατά πόσο σχετίζονται άμεσα με το πρόβλημα ή αν είναι παρενέργεια.
Γράφω τώρα εδώ επειδή η κάρτα δικτύου και στους clients και στους servers είναι η Atheros AR8121/AR8113/AR8114, η οποία χρησιμοποιεί το module atl1e. To module φορτώνεται κανονικά στους clients, όμως στο http://www.pubbs.net/201001/kernel/35092-atl1e-tso-is-broken.html (http://www.pubbs.net/201001/kernel/35092-atl1e-tso-is-broken.html) αναφέρει ότι το NFS έχει προβλήματα με αυτό το module. Γράφει μάλιστα ότι η απόδοση του δικτύου είναι γύρω στα 25MBps, όσο ακριβώς τη μέτρησα και στο δικό μου εργαστήριο με τη μέθοδο που περιγράφεται στο https://alkisg.mysch.gr/steki/index.php?topic=3324.msg33979#msg33979 (https://alkisg.mysch.gr/steki/index.php?topic=3324.msg33979#msg33979).
Παράθεση από: alkisg στις 01 Νοε 2010, 10:36:50 ΜΜ
Στο μεταξύ το έψαχνα να δω τι φταίει, και τουλάχιστον για το εργαστήριο του sectorovic βρήκα ότι μάλλον φταίει ο driver της κάρτας (http://www.spinics.net/lists/linux-nfs/msg16519.html), και ότι ένα workaround είναι να καθοριστεί από το lts.conf ότι το NFS θα χρησιμοποιεί το πρωτόκολλο UDP αντί του TCP, δηλαδή να προστεθεί η γραμμή:
NFS_HOME_OPTIONS="nolock,proto=udp,rsize=4096,wsize=4096"
Αυτό είναι το πρώτο που δοκίμασα, γιατί και στο link που βρήκα εγώ εντοπίζει το πρόβλημα στο TCP. Η ταχύτητα διπλασιάστηκε γύρω στα 50MBps, αλλά εξακολουθούσαν να υπάρχουν προβλήματα. Στη συνέχεια, κατέφυγα στο NFS_HOME="", το οποίο πήγε την ταχύτητα κοντά στα 100MBps (όσο πάει δηλαδή) και
προς το παρόν φαίνεται να λύνει το πρόβλημα.
Επομένως, επιβεβαιώνω τα προβλήματα και για τον atl1e, αλλά και την εγκυρότητα των workarounds. Άλκη, στο link που αναφέρω πιο πάνω εντοπίζει το ακριβές πρόβλημα που έχει το NFS με το TCP και γράφει ότι το λύνει με το ethtool. Αν θες ρίξε μια ματιά, πιο πολλά θα καταλάβεις...
Παράθεση από: odysseas στις 10 Νοε 2010, 06:29:00 ΜΜ
Στη συνέχεια, κατέφυγα στο NFS_HOME="", το οποίο πήγε την ταχύτητα κοντά στα 100MBps (όσο πάει δηλαδή) και προς το παρόν φαίνεται να λύνει το πρόβλημα.
Αυτό ουσιαστικά απενεργοποιεί το NFS, οπότε οι συγκεκριμένοι clients θα τρέχουν με SSHFS, και επομένως λίγα προγράμματα (evolution, chromium-browser, googleearth) δεν θα τρέχουν σε fat clients.
Είναι το ίδιο με το να απεγκατασταθεί το πακέτο nfs-kernel-server από τον server.
Παράθεση από: odysseas στις 10 Νοε 2010, 06:29:00 ΜΜ
Άλκη, στο link που αναφέρω πιο πάνω εντοπίζει το ακριβές πρόβλημα που έχει το NFS με το TCP και γράφει ότι το λύνει με το ethtool. Αν θες ρίξε μια ματιά, πιο πολλά θα καταλάβεις...
Απ' ότι λέει χρειάζεται νεότερος kernel από αυτόν που έχει τώρα η Lucid, ώστε η κάρτα να υποστηρίξει τη σχετική επιλογή του ethtool που απενεργοποιεί το checksum offloading. Επίσης θεωρητικά με το UDP θα λυνόταν το πρόβλημα, οπότε ίσως να έχεις ακόμα πρόβλημα καλωδίωσης στο εργαστήριο - αυτό θα έλεγχα πρώτα στη θέση σου.
Αν θες να δοκιμάσεις πιο καινούργιο kernel, γίνεται μέσω του αποθετηρίου lucid-proposed (https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS), αλλά θέλει να γίνει και στον εικονικό δίσκο για τα τερματικά, οπότε γενικότερα θέλει λίγο προσοχή σε τόσο ριζικές αλλαγές - κάνε π.χ. backup όλο το /opt/ltsp για να μην παιδεύεσαι να το επαναφέρεις αν κάτι δεν πάει καλά.
Παράθεση από: alkisg στις 10 Νοε 2010, 07:49:42 ΜΜ
Επίσης θεωρητικά με το UDP θα λυνόταν το πρόβλημα, οπότε ίσως να έχεις ακόμα πρόβλημα καλωδίωσης στο εργαστήριο - αυτό θα έλεγχα πρώτα στη θέση σου.
Δυστυχώς, τα squashfs errors εξακολουθούν να εμφανίζονται συχνότατα, είτε με UDP, είτε με απενεργοποίηση του NFS. Σήμερα δανείστηκα έναν cable tester όμως δε διαπίστωσα κάποιο πρόβλημα. Όλοι όσοι αναφέρουν ότι δουλεύει το UDP έχουν το module atl1c; Υπάρχει κανείς του οποίου οι κάρτες να χρειάζονται το atl1e, όπως οι δικές μου;
odysseas μετακίνησα εδώ μερικά μηνύματά σου από το θέμα για την προσθήκη driver κάρτας δικτύου στον εικονικό δίσκο (https://alkisg.mysch.gr/steki/index.php?topic=3335.0), γιατί μάλλον δεν είναι σχετικό με το πρόβλημά σου και δημιουργούσε σύγχιση και σε εμάς τους δυο αλλά και στους υπόλοιπους αναγνώστες.
Αφού λοιπόν τσέκαρες το δίκτυο, πάμε στην περίπτωση (3), προβληματικός driver της κάρτας δικτύου.
Αναφέρεις παραπάνω (https://alkisg.mysch.gr/steki/index.php?topic=3325.msg34493#msg34493) ότι οι αλλαγές στο lts.conf (π.χ. NFS_HOME κτλ) επηρεάζουν την ταχύτητα του δικτύου, μετρώντας τη με το iperf.
Αυτό δεν θα έπρεπε να συμβαίνει. Το iperf δεν κοιτάει τις επιλογές του lts.conf, χρησιμοποιεί τις παραμέτρους που του βάζεις στο command line του. Έτσι οι αλλαγές στο lts.conf μπορούν να επηρεάσουν την ταχύτητα του NFS, αλλά όχι του iperf.
Αν λοιπόν η ταχύτητα του iperf επηρεάζεται από το lts.conf, τότε το πρόβλημά σου είναι κάτι εντελώς διαφορετικό από αυτά που συζητάμε μέχρι τώρα και θα πρέπει να εστιάσουμε σε αυτό.
Αν δεν επηρεάζεται, οκ, συνεχίζουμε να κοιτάμε για προβληματικό driver.
Για να ελέγξεις αν το δίκτυό σου παίζει καλύτερα με UDP, μπορείς να δοκιμάσεις με iperf -u. Αν δεις μεγάλη αύξηση στην ταχύτητα σε σχέση με όταν το iperf τρέχει με TCP, τότε προχωράμε με τη λύση του νέου kernel που αναφέρεις παραπάνω.
Ένα ακόμα σημείο είναι ότι το NFS_HOME και το NFS_HOME_OPTIONS δεν έχουν καμία σχέση με τα squashfs errors. Αυτά αφορούν το /home που συνδέεται με το πρωτόκολλο NFS (και αυτό μπορεί όντως να στο κάνουν πιο γρήγορο), ενώ αντίθετα το squashfs αναφέρεται στο / που συνδέεται με πρωτόκολλο NBD.
Δυστυχώς ο NBD client δεν έχει επιλογή για να χρησιμοποιήσει UDP, κι έτσι μόνο με καινούργιο kernel θα μπορούσες να απενεργοποιήσεις το checksum offloading και να δεις αν φταίει αυτό.
Ή, θα μπορούσες να σταματήσεις να χρησιμοποιείς NBD και να πας σε NFS και για το /, όπως αναφέρεται στην τελευταία παράγραφο αυτής της σελίδας (https://help.ubuntu.com/community/UbuntuLTSP/LTSPWithoutNFS). Αλλά μην το δοκιμάσεις αυτό, δοκίμασε πρώτα το iperf και μετά την αλλαγή kernel + ethtool.
Παράθεση από: alkisg στις 25 Νοε 2010, 07:07:50 ΠΜ
odysseas μετακίνησα εδώ μερικά μηνύματά σου από το θέμα για την προσθήκη driver κάρτας δικτύου στον εικονικό δίσκο (https://alkisg.mysch.gr/steki/index.php?topic=3335.0), γιατί μάλλον δεν είναι σχετικό με το πρόβλημά σου και δημιουργούσε σύγχιση και σε εμάς τους δυο αλλά και στους υπόλοιπους αναγνώστες.
Ναι, καλά έκανες, είναι ενδεικτικό ότι κι εγώ αναρωτιόμουν σε ποιο από τα δύο threads έπρεπε να postάρω. Ευχαριστώ για τις διευκρινίσεις, θα το κοιτάξω.
Παράθεση από: alkisg στις 25 Νοε 2010, 07:07:50 ΠΜ
Αναφέρεις παραπάνω ότι οι αλλαγές στο lts.conf επηρεάζουν την ταχύτητα του δικτύου, μετρώντας τη με το iperf. Αυτό δεν θα έπρεπε να συμβαίνει.
Έχεις δίκιο, είναι απόλυτα λογικό. Προσπάθησα να αναπαράγω τη διαφοροποίηση της ταχύτητας για να αναρτήσω εδώ τις μετρήσεις.
Δεν τα κατάφερα... Το οποίο είναι ολίγον τι ρεζιλίκι, αφενός γιατί το είχα δει με τα μάτια μου, αφετέρου γιατί το πόσταρα και στο άλλο thread αποπροσανατολίζοντας τον κόσμο. :-[ Λοιπόν, το iperf (χωρίς -u) αναφέρει transfer rate ανά client γύρω στα 25 Mbps. Ενημερωτικά, είναι 5 fat clients και 5 thin clients. Οι fat clients και ο server έχουν την ίδια κάρτα δικτύου.
Παράθεση από: alkisg στις 25 Νοε 2010, 07:07:50 ΠΜ
Για να ελέγξεις αν το δίκτυό σου παίζει καλύτερα με UDP, μπορείς να δοκιμάσεις με iperf -u. Αν δεις μεγάλη αύξηση στην ταχύτητα σε σχέση με όταν το iperf τρέχει με TCP, τότε προχωράμε με τη λύση του νέου kernel που αναφέρεις παραπάνω.
Ακολουθώντας το man page του iperf, έτρεξα sudo iperf -u -s σε όλους τους clients και iperf -u -c στον server (για όλους τους clients μαζί). Μου ανέφερε ~1Mbps ανά client. ???
Αυτό με έστειλε αδιάβαστο, δεν ξέρω αν/τι έκανα λάθος και τι πρέπει να συμπεράνω.
ΠαράθεσηΈνα ακόμα σημείο είναι ότι το NFS_HOME και το NFS_HOME_OPTIONS δεν έχουν καμία σχέση με τα squashfs errors. Αυτά αφορούν το /home που συνδέεται με το πρωτόκολλο NFS (και αυτό μπορεί όντως να στο κάνουν πιο γρήγορο), ενώ αντίθετα το squashfs αναφέρεται στο / που συνδέεται με πρωτόκολλο NBD.
Αυτό είναι πολύ ενδιαφέρον, δεν το γνώριζα για το NBD. Αυτό που λες είναι σαφέστατο, κατάλαβα.
ΠαράθεσηΔυστυχώς ο NBD client δεν έχει επιλογή για να χρησιμοποιήσει UDP, κι έτσι μόνο με καινούργιο kernel θα μπορούσες να απενεργοποιήσεις το checksum offloading και να δεις αν φταίει αυτό.
Εντάξει, θα το προσπαθήσω κι αν χρειαστώ βοήθεια θα ενημερώσω. Άλκη, θερμές ευχαριστίες για το χρόνο σου (ειδικά και γενικά) και από εμένα.
Παράθεση από: odysseas στις 26 Νοε 2010, 12:03:36 ΠΜ
Ακολουθώντας το man page του iperf, έτρεξα sudo iperf -u -s σε όλους τους clients και iperf -u -c στον server (για όλους τους clients μαζί). Μου ανέφερε ~1Mbps ανά client. ???
Αυτό με έστειλε αδιάβαστο, δεν ξέρω αν/τι έκανα λάθος και τι πρέπει να συμπεράνω.
Στο UDP πρέπει να ορίσεις και το bandwidth-στόχο, με κάτι σαν:
iperf -u -c server -b 100m
Ο προεπιλεγμένος στόχος είναι το 1 Mbps, γι' αυτό σου έβγαλε τόσο (το λέει στη man page).
Επίσης αν θυμάμαι καλά η σύνδεση server <=> switch σου είναι 100 Mbps και όχι gigabit, επομένως δε νομίζω ότι έχει νόημα να δοκιμάζεις με πολλούς clients μαζί, ένας αρκεί αφού δεν πρόκειται να ξεπεράσεις τα 100 Mbps σε καμία περίπτωση.
Τα 25 Mbps που λες ότι πιάνεις είναι για κάθε client χωριστά, έτσι; Δηλαδή 25 Mbps * 4 clents = 100 Mbps, δηλαδή και με το TCP το "γεμίζεις" το δίκτυο, αντίθετα με αυτά που γράφει ο τύπος στο link που έδωσες με το checksum offloading, και επομένως δεν έχετε το ίδιο πρόβλημα... Αν έχεις 100Mbps δίκτυο, δοκίμασε με έναν μόνο client για να είναι πιο ξεκάθαρα τα πράγματα.
Αν θες έλα και από το IRC να δοκιμάσουμε μαζί για benchmarks + πιθανώς νέο kernel. Άσε ανοιχτό τον server και κανά δυο clients το μεσημέρι και τα κάνουμε απομακρυσμένα το απόγευμα.
Παράθεση από: alkisg στις 26 Νοε 2010, 07:45:53 ΠΜ
Στο UDP πρέπει να ορίσεις και το bandwidth-στόχο, με κάτι σαν:
iperf -u -c server -b 100m
Ο προεπιλεγμένος στόχος είναι το 1 Mbps, γι' αυτό σου έβγαλε τόσο (το λέει στη man page).
Α, εντάξει, δεν το πρόσεξα. Θα το ξανατρέξω.
Παράθεση
Επίσης αν θυμάμαι καλά η σύνδεση server <=> switch σου είναι 100 Mbps και όχι gigabit, επομένως δε νομίζω ότι έχει νόημα να δοκιμάζεις με πολλούς clients μαζί, ένας αρκεί αφού δεν πρόκειται να ξεπεράσεις τα 100 Mbps σε καμία περίπτωση.
Όχι, ο server μπαίνει σε gigabit θύρα επάνω στο switch. Οπότε με 10 clients πιάνω συνολικά ~250 Mbps, δε γεμίζει το δίκτυο.
Παράθεση
Αν θες έλα και από το IRC να δοκιμάσουμε μαζί για benchmarks + πιθανώς νέο kernel. Άσε ανοιχτό τον server και κανά δυο clients το μεσημέρι και τα κάνουμε απομακρυσμένα το απόγευμα.
Είμαι σε εσπερινό σχολείο. Συνήθως πηγαίνω αρκετά νωρίτερα το απόγευμα για να προλάβω να κάνω πειράματα, αλλιώς κατά τη διάρκεια των μαθημάτων είναι πάρα πολύ δύσκολο, σκέψου ότι τα διαλείμματα είναι 5λεπτα. Οπότε θα κάνω τα benchmarks, θα αναφέρω και αν είναι θα σε ψάξω. Ευχαριστώ.
Πειράματα με το iperf σε 5 fat clients, συνδεδεμένους σε 100-αρα θύρα.
O server σε gigabit θύρα.
- TCP: ~50 Mbps ανα client => συνολικά γύρω στα 250 Mbps. Αυτό είναι απόλυτα συνεπές με τα ~25 Mbps που μετρούσα με 5+5 clients.
- UDP: Όταν ο στόχος ήταν μέχρι και 90 Mbps ανά client, τα έπιανε πάντα. Μετά η απόδοση έπεφτε αλλά φαντάζομαι ότι δεν έχει και πολλή σημασία.
Αυτό αποδεικνύει ότι υπάρχει πρόβλημα με τη χρήση του TCP;
Παράθεση από: odysseas στις 27 Νοε 2010, 12:41:34 ΠΜ
TCP: ~50 Mbps ανα client => συνολικά γύρω στα 250 Mbps. Αυτό είναι απόλυτα συνεπές με τα ~25 Mbps που μετρούσα με 5+5 clients.
Αυτό αποδεικνύει ότι υπάρχει πρόβλημα με τη χρήση του TCP;
Θα έλεγα ναι, π.χ. σε μένα πιάνει γύρω στα 95 Mbps σε 100 Mbps δίκτυο.
Ξανατρέξε το ίδιο τεστ.
Στη συνέχεια, και από τον server και από τον fat client, τρέξε την παρακάτω εντολή και ανέβασε τα αποτελέσματά της για να δούμε τα στατιστικά του TCP:
netstat -s -p tcp
Και πιο συγκεκριμένα κοίτα για τις γραμμές "segments retransmited" και "bad segments received".
Επίσης αν μπορείς τρέξε το ίδιο τεστ μεταξύ δύο thin clients, οι οποίοι έχουν διαφορετική κάρτα δικτύου (πάρε κονσόλα διαχειριστή μέσα από την εκτέλεση των sch-scripts).
Παράθεση από: alkisg στις 27 Νοε 2010, 09:05:39 ΜΜ
Επίσης αν μπορείς τρέξε το ίδιο τεστ μεταξύ δύο thin clients, οι οποίοι έχουν διαφορετική κάρτα δικτύου (πάρε κονσόλα διαχειριστή μέσα από την εκτέλεση των sch-scripts).
Για να είμαι σίγουρος οτι καταλαβαίνω τι εννοείς: "το ίδιο τεστ" είναι το τεστ με το iperf; Θες ένας thin client να είναι server κι ο άλλος client;
Ακριβώς έτσι, για να βεβαιωθούμε ότι δεν έχεις πρόβλημα αλλού, π.χ. στο switch.
Αν από π.χ. realtek σε realtek πιάνεις 95 Mbps,
ενώ από atl1e σε atl1e πιάνεις 50 Mbps,
ε τότε είναι αρκετά βέβαιο ότι φταίει ο driver, οπότε και δοκιμάζεις με νεότερο kernel και απενεργοποίηση του checksum offloading και στον server και στον εικονικό δίσκο.
(επίσης από περιέργεια κοίτα λίγο πόσο πιάνεις από atl1e σε realtek, δηλαδή εννοώ να κάνεις το τεστ μεταξύ του server και κάποιου thin client, και μάλιστα αν μπορείς εναλλάξ, με τον "iperf server" να είναι τη μία φορά ο ένας και την άλλη ο άλλος).
Στα πειράματα με το iperf, σε όλους τους συνδυασμούς μεταξύ δύο μηχανημάτων (server, fat clients, thin clients) η ταχύτητα ήταν ~95 Mbps.
Στη συνέχεια, επέστρεψα στην κλασσική διαμόρφωση (5 fat clients ως servers και ο server ως client σε αυτούς), αλλά αύξησα σταδιακά τον αριθμό των fat clients με τους οποίους έκανα τη μέτρηση. Λοιπόν, η ταχύτητα των 50 Mbps ανά fat client εμφανίζεται μόνο στην περίπτωση των 5 fat clients. Από 1-4 fat clients μετράω ταχύτητες της τάξης των ~90Mbps ανά client... :o Επίσης, στο netstat (server και fat clients) οι αριθμοί των retransmitted segments και bad segments είναι από αμελητέοι μονοψήφιοι έως μηδενικοί.
Κάτι άλλο τώρα: το ethtool επιτρέπει και τώρα την απενεργοποίηση του checksum offloading. Έκανα λοιπόν:
sudo ethtool -K eth0 tso off
και με την επιλογή -k διασταύρωσα ότι έχει απενεργοποιηθεί. Επανέλαβα τα πειράματα αλλά δεν είδα κάποια αλλαγή.
Αυτό για το οποίο ακόμα δεν είμαι σίγουρος είναι αν όλα αυτά έχουν πράγματι κάποια σχέση με τα squashfs errors, τα οποία εμφανίζονται τυχαία, σε τυχαία μηχανήματα. Άλκη, λίγο ακόμα να το παλέψουμε, είμαι έτοιμος να δεχθώ ότι μερικές φορές θα πρέπει να κάνω reboot και να αφήνω τα παιδιά να με δουλεύουν γιατί είναι τα καινούργια μηχανήματα που έχουν πρόβλημα! ;)
Χωρίς live testing δεν έχω κάποια άλλη ιδέα να σου προτείνω, παρά μόνο το να δοκιμάσεις τα defaults του Ubuntu, δηλαδή να απενεργοποιήσεις τη συμπίεση του εικονικού δίσκου (θα πάει λίγο πιο αργά) και να ενεργοποιήσεις το nbd-proxy (και λίγο ακόμα πιο αργά :)).
Στο αρχείο /etc/ltsp/ltsp-update-image.conf, κάνε τις παρακάτω αλλαγές που φαίνονται με κόκκινο. Στο NO_COMP απλά αλλάζει η σειρά των δύο πρώτων παραμέτρων:
Παράθεση
# By default, do not compress the image
# as it's reported to make it unstable
NO_COMP="-noD -noF -noI -no-exports"
BOOTPROMPT_OPTIONS="quiet splash nocompcache"
# BEGIN added by sch-scripts
...
Στη συνέχεια κάνε συμπίεση του εικονικού δίσκου μέσα από τα sch-scripts και δούλεψέ το έτσι για κάμποσο καιρό να δεις αν καλυτέρευσε.
Παράθεση από: alkisg στις 30 Νοε 2010, 06:59:05 ΜΜ
Στη συνέχεια κάνε συμπίεση του εικονικού δίσκου μέσα από τα sch-scripts και δούλεψέ το έτσι για κάμποσο καιρό να δεις αν καλυτέρευσε.
Αναφορά: (1) Τα squashfs errors προφανώς δεν εμφανίζονται πια. (2) Τα μηχανήματα πηγαίνουν αισθητά πιο αργά, το δούλεμα λοιπόν το τρώω ούτως ή άλλως. (3) Υπάρχουν φορές που κάποια μηχανήματα δεν ολοκληρώνουν τη διαδικασία εκκίνησης και χρειάζεται να τα ξαναξεκινήσω. Το μήνυμα που ξεχωρίζω πριν κολλήσουν είναι το "nbd0: hangup". Στους clients που ολοκληρώνουν την εκκίνηση, το αντίστοιχο μήνυμα είναι "nbd0:unknown partition table". Δεν ξέρω κατά πόσο αυτά έχουν άμεση σχέση.
Να ρωτήσω γιατί πρέπει να γίνουν και οι δύο αλλαγές ταυτόχρονα (συμπίεση δίσκου και nbd_proxy); Θα είχε νόημα να πειραματιστώ μόνο με μία από τις δύο;
Βασικά με το nbd-proxy παίζει το εξής: ο νέος LTSP maintainer του Ubuntu το έβαλε για την περίπτωση του LTSP cluster που συντηρεί, όπου υποτίθεται ότι αν κάποιος από τους πολλούς LTSP servers πέσει, αυτό συνδέεται σε κάποιον άλλο server που δεν έχει πέσει.
Το κακό είναι ότι για όσους δεν έχουν cluster τρώει τζάμπα RAM και CPU.
Επίσης με τον maintainer διαφωνούμε σχετικά με τη σταθερότητά του, εγώ και αρκετοί άλλοι (https://bugs.launchpad.net/ltsp/+bug/589034) πιστεύουμε ότι κάνει το σύστημα πιο ασταθές, ενώ αυτός το αντίθετο.
Έτσι τα sch-scripts χρησιμοποιούν τα defaults που είχε το Ubuntu με τον παλιό maintainer (compression και όχι nbd-proxy), τα οποία δίνουν εμφανώς καλύτερη ταχύτητα (και btw ούτε το Debian χρησιμοποιεί nbd-proxy),
ενώ οι νέες εκδόσεις του Ubuntu χρησιμοποιούν no compression και nbd-proxy - γιατί απ' ότι έλεγε ο maintainer είδε προβλήματα με το compression, ενώ εγώ πιστεύω ότι τα προβλήματα που είδε ήταν του nbd-proxy.
Γι' αυτό σου είπα να δοκίμαζες και τα νέα defaults, μήπως τυχόν ο maintainer είχε δίκιο, αλλά τα αποτελέσματα ήταν αναμενόμενα, δηλαδή δεν είδες βελτίωση. Ούτε και έχει νόημα να δοκιμάσεις διαφορετικούς συνδυασμούς, ξαναγύρνα σε compression + no nbd-proxy όπως τα είχαν τα sch-scripts.
Εν τέλει πιστεύω ότι είτε είναι πρόβλημα καλωδίωσης, που το απέρριψες, είτε πρόβλημα driver, οπότε και θέλει δοκιμές με άλλες κάρτες, kernels κτλ. Δηλαδή αν π.χ. αντιμεταθέσεις τις atl με τις realtek, μεταφέρεται αυτόματα και το πρόβλημα σε άλλα PC;
Παράθεση από: alkisg στις 06 Δεκ 2010, 07:26:42 ΜΜ
Δηλαδή αν π.χ. αντιμεταθέσεις τις atl με τις realtek, μεταφέρεται αυτόματα και το πρόβλημα σε άλλα PC;
Οι atl είναι integrated και realtek δεν έχω! :P Θα δανειστώ από πουθενά αλλού και θα αναφέρω.
Ευχαριστώ Άλκη.
ΟΚ δεν ήξερα ότι οι atl είναι onboard και νόμιζα ότι οι thin έχουν realtek.
Δανείστηκα (με τη σέσουλα) από το τοπικό ΠΛΗΝΕΤ κάρτες δικτύου 100άρες με τσιπάκι Realtek, τις οποίες τοποθέτησα στον server και στους 5 clients. Με το που bootαρε o πρώτος client κατάλαβα ότι το πρόβλήμα δεν υπήρχε πια -- η διαφορά στην ταχύτητα ήταν αισθητή. Έκανα εκτενείς δοκιμές, δεν υπάρχει αμφιβολία ότι το πρόβλημα είναι στον driver atl1e.
Προχωράω με καινούργιο kernel...
Παράθεση από: odysseas στις 09 Δεκ 2010, 12:43:09 ΠΜ
Έκανα εκτενείς δοκιμές, δεν υπάρχει αμφιβολία ότι το πρόβλημα είναι στον driver atl1e.
Προχωράω με καινούργιο kernel...
Ωραίος! Λοιπόν επειδή δεν βρήκα κάποιο καλό how-to στο Internet για την εγκατάσταση νέου kernel στις LTS εκδόσεις του Ubuntu (https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS), γράφω ένα εδώ:
Ανοίγουμε τα sch-scripts.
Πηγαίνουμε στο μενού Εξυπηρετητής → Εικονικός δίσκος → Ενημέρωση. (ΔΕΝ κάνουμε Συμπίεση).
Πηγαίνουμε στο μενού Εξυπηρετητής → Εικονικός δίσκος → Άνοιγμα κονσόλας, και στο τερματικό που θα ανοίξει δίνουμε τις παρακάτω εντολές:
# Προσθέτουμε το αποθετήριο lucid-proposed:
echo 'deb http://archive.ubuntu.com/ubuntu lucid-proposed restricted main multiverse universe' >> /etc/apt/sources.list
# Καθορίζουμε ότι δεν θέλουμε τίποτα από αυτό εκτός κι αν το ζητήσουμε ρητά:
echo -e 'Package: *\nPin: release a=lucid-proposed\nPin-Priority: 400' > /etc/apt/preferences.d/lucid-proposed
# Ενημερώνουμε τις πληροφορίες για τα πακέτα:
apt-get update
# Εγκαθιστούμε τον νεότερο kernel:
apt-get --yes install linux-image-generic-lts-backport-maverick
# Αν χρειάζεται, εγκαθιστούμε και τους headers:
test -n "$(dpkg -l 'linux*headers*' | grep ^ii)" && apt-get --yes install linux-headers-generic-lts-backport-maverick
# Βγαίνουμε από το τερματικό
exit
Στη συνέχεια πηγαίνουμε στο μενού Εξυπηρετητής → Εικονικός δίσκος → Συμπίεση, και τελικά επανεκκινούμε τους clients.
Όμως εσύ επειδή έχεις κάρτα atl1e και στο server, θα χρειαστεί να εκτελέσεις τις παραπάνω εντολές και στον server. Πήγαινε στο μενού Εφαρμογές → Βοηθήματα → Τερματικό, δώσε την εντολή
sudo -i και στη συνέχεια τις εντολές που αναφέρθηκαν παραπάνω.
Αν ο νέος kernel σου λύσει το πρόβλημα, ανάφερέ το στο launchpad ώστε να κάνουν "cherry pick" το bug fix για όλους όσους έχουν Lucid.
Αν δεν σου λύσει το πρόβλημα, ανάφερέ το σ' εκείνη τη mailing list που παράθεσες παραπάνω ώστε να φτιαχτεί από τους netdev kernel developers.
Γράφω και τη αντίστροφη διαδικασία αφαίρεσης του νεότερου kernel, μήπως κάποιος τη χρειαστεί:
Ανοίγουμε τα sch-scripts.
Πηγαίνουμε στο μενού Εξυπηρετητής → Εικονικός δίσκος → Άνοιγμα κονσόλας, και στο τερματικό που θα ανοίξει δίνουμε τις παρακάτω εντολές:
# Αφαιρούμε το αποθετήριο lucid-proposed:
sed '/lucid-proposed/d' -i /etc/apt/sources.list
# Ενημερώνουμε τις πληροφορίες για τα πακέτα:
apt-get update
# Αφαιρούμε το apt-pinning:
rm /etc/apt/preferences.d/lucid-proposed
# Αφαιρούμε τον νεότερο kernel και τους headers:
rm /boot/nbi.img*
apt-get --yes purge --auto-remove linux-image-generic-lts-backport-maverick linux-image-2.6.35-22-generic linux-headers-generic-lts-backport-maverick
# Δυστυχώς σε downgrades παρουσιάζονται προβλήματα με κάποια symlinks, οπότε θα πρέπει να τα διορθώσουμε χειρωνακτικά:
test -f /boot/vmlinuz || mv /boot/vmlinuz.old /boot/vmlinuz
test -f /boot/initrd.img || mv /boot/initrd.img.old /boot/initrd.img
test -f /boot/nbi.img || mv /boot/nbi.img.old /boot/nbi.img
# Βγαίνουμε από το τερματικό
exit
Στη συνέχεια πηγαίνουμε στο μενού Εξυπηρετητής → Εικονικός δίσκος → Συμπίεση, και τελικά επανεκκινούμε τους clients.
Τα καλά νέα είναι ότι η διαδικασία εγκατάστασης του νέου kernel κύλησε ομαλότατα. Ομολογώ ότι τη φοβόμουν γιατί σε ένα σχετικό tutorial είχα διαβάσει την αμίμητη ατάκα: "if it breaks, you get to keep all the pieces...". Δυστυχώς όμως δεν υπήρξε κάποια αλλαγή. Τα squashfs errors επιμένουν.
Τώρα πρέπει να απενεργοποιήσω το tso με το ethtool, αλλά φαντάζομαι ότι αυτό πρέπει να γίνει με κάποιο scriptακι στο /etc/init.d, αλλιώς η απενεργοποίηση δεν είναι μόνιμη (και ούτως ή άλλως τα squashfs errors εμφανίζονται από το bootάρισμα).
Άλκη, αν έχεις προτάσεις...
Υπόθεση: Έστω ότι, με τον καινούργιο πυρήνα, η απενεργοποίηση του tso (ή του tx όπως διάβασα σε άλλα threads) θα έλυνε το πρόβλημα. Αυτό μπορεί να γίνει και μετά την εκκίνηση στον server αλλά πότε και πως πρέπει να γίνει στους fat clients; Δε θα έπρεπε να γίνει πριν αρχίσουν να διαβάζουν τον εικονικό δίσκο; Έχω προβληματιστεί γιατί δεν ξέρω πως να το δοκιμάσω.
Με την ευκαιρία, επισυνάπτω και ένα syslog από έναν client, για να υπάρχει ένα δείγμα των squashfs errors. Το δεύτερο σετ σφαλμάτων προέρχεται από την κονσόλα που άνοιξα στο μηχάνημα μέσω των sch-scripts.
odysseas ένας γρήγορος τρόπος απλά για δοκιμή είναι να ανοίξεις το αρχείο /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default και να αντικαταστήσεις το quiet splash με break=bottom.
Μόλις ξεκινήσουν οι clients θα σε βγάλουν σε ένα busybox shell πριν ακόμα επικοινωνήσουν με τον εικονικό δίσκο.
Σ' αυτό το σημείο δοκίμασε να τρέξεις /root/usr/sbin/ethtool -K eth0 tso off. Αν αυτό εκτελεστεί σωστά, έστω και με τη δεύτερη ή την τρίτη προσπάθεια, τότε πατάς Ctrl+D για να βγεις από το shell και να συνεχιστεί η εκκίνηση.
Αν όντως η απενεργοποίηση του checksum offloading σε γλυτώνει από τα squashfs errors, τότε να σου γράψω πιο αναλυτικές οδηγίες για το πώς μπορεί να μπει το ethtool στο initramfs και να εκτελείται από εκεί αυτόματα πριν ακόμα γίνει οποιαδήποτε επικοινωνία μέσω nbd.
Το πιο σημαντικό όμως είναι να επικοινωνήσεις με τη mailing list των netdev kernel developers ώστε να λύσουν το πρόβλημα σωστά αυτοί χωρίς να βρίσκουμε workarounds...
Άλκη, ευχαριστώ.
Παράθεση από: alkisg στις 10 Δεκ 2010, 07:00:28 ΜΜ
Το πιο σημαντικό όμως είναι να επικοινωνήσεις με τη mailing list των netdev kernel developers ώστε να λύσουν το πρόβλημα σωστά αυτοί χωρίς να βρίσκουμε workarounds...
Ok.
Παράθεση από: odysseas στις 09 Δεκ 2010, 08:10:24 ΜΜ
Τα καλά νέα είναι ότι η διαδικασία εγκατάστασης του νέου kernel κύλησε ομαλότατα. Ομολογώ ότι τη φοβόμουν γιατί σε ένα σχετικό tutorial είχα διαβάσει την αμίμητη ατάκα: "if it breaks, you get to keep all the pieces...". Δυστυχώς όμως δεν υπήρξε κάποια αλλαγή. Τα squashfs errors επιμένουν.
Δεν είναι ακριβώς έτσι τα πράγματα.
Όταν είχα ολοκληρώσει την εγκατάσταση του νέου πυρήνα στον εικονικό δίσκο είχα ελέγξει ότι αυτός είχε εγκατασταθεί με uname -r
στην κονσόλα του εικονικού δίσκου (δηλαδή όχι από τους ίδιους τους clients). Δεν ξέρω αν πρέπει να με μαλώσω για αυτό, δε φαντάστηκα όμως ότι θα έκανε κάποια διαφορά. Σήμερα κάνοντας update παρατήρησα ότι έφερνε ενημερώσεις για πυρήνα 2.6.32 (δηλαδή τον "κανονικό") και όχι 2.6.35! Οπότε συμβαίνει το εξής παράδοξο: στους clients το uname -r δίνει ακόμα 2.6.32 αλλά στην κονσόλα του εικονικού δίσκου μου λέει ότι είναι εγκατεστημένος ο 2.6.35.
Εν τω μεταξύ, συνέβαινε και το εξής που με κάνει να πιστεύω ότι ο 2.6.35 θα δουλέψει σωστά (όταν τελικά μπει...): με τον 2.6.35 στον server (όπου εγκαταστάθηκε μια χαρά) και την ενσωματωμένη atheros και με realtek κάρτες στους clients έπαιζε ρολόι...
Όταν είσαι στον εικονικό δίσκο, τρέχει ο kernel του server αφού είσαι στον server. Έτσι το uname -r σου λέει τι έχει εγκατεστημένο ο server.
Έκανες εντός του εικονικού δίσκου τα βήματα που ανέφερα παραπάνω;
Ανέβασε το αποτέλεσμα των παρακάτω εντολών:
ls -l /var/lib/tftpboot/ltsp/i386
ls -l /opt/ltsp/i386/boot
sudo chroot /opt/ltsp/i386 dpkg -l 'linux*' | grep ^ii
Παράθεση από: alkisg στις 23 Δεκ 2010, 01:07:41 ΠΜ
Έκανες εντός του εικονικού δίσκου τα βήματα που ανέφερα παραπάνω;
Ανέβασε το αποτέλεσμα των παρακάτω εντολών:
ls -l /var/lib/tftpboot/ltsp/i386
ls -l /opt/ltsp/i386/boot
sudo chroot /opt/ltsp/i386 dpkg -l 'linux*' | grep ^ii
Όταν εκτέλεσα τα παραπάνω ls είδα ότι τα vmlinuz, initrd.img κλπ έδειχναν στον 2.6.32
αλλά τα vmlinuz.old, initrd.img.old κλπ έδειχναν στον 2.6.35, με χθεσινή ημερομηνία. Εγώ από αυτό συμπεραίνω ότι η εγκατάσταση του νέου πυρήνα είχε γίνει σωστά αλλά το χθεσινό update για κάποιο λόγο επανέφερε τον παλιό πυρήνα. Εν πάσει περιπτώσει, αφαίρεσα το νέο πυρήνα και τον ξαναέβαλα (σύμφωνα με τις οδηγίες σου, λες και το ήξερες) και η κατάσταση έχει επανέλθει.
Όσο για τα προηγούμενα, δεν έχω προλάβει δυστυχώς να κάνω καμία περαιτέρω δοκιμή. Ανακεφαλαιώνω: Δουλεύω με την onboard gigabit atheros στον server και με 100άρες realtek στους clients, 2.6.35 σε όλους (τελικά) και όλα δουλεύουν ρολόι. Επιβεβαίωσα και πάλι ότι με την onboard atheros στους clients και 2.6.35 εμφανίζονται squashfs errors.