Δεν ολοκληρώνεται η εκκίνηση εφαρμογής σε fat clients

[odysseas]

Μου έχει τύχει ορισμένες φορές να μην ολοκληρώνεται η φόρτωση του 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

Υποθέτω ότι πρόκειται για κάποιο προσωρινό πρόβλημα με τον εικονικό δίσκο, αλλά από κει και πέρα...

[alkisg]

Τρεις λόγους έχω δει για το προκαλούν αυτό,
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, αλλά δεν το έχω δει να συμβαίνει ποτέ και πιστεύω ότι η απενεργοποίησή της απλά κρύβει όποιο πραγματικό πρόβλημα υπάρχει από τα τρία παραπάνω.

[odysseas]

Τρεις λόγους έχω δει για το προκαλούν αυτό,
1) Πρόβλημα στην καλωδίωση του εργαστηρίου.
2) Να μην υπάρχει το nbd_proxy=false στο pxelinux.cfg/default (το βάζουν αυτόματα τα sch-scripts).
3) Προβληματικός driver της κάρτας δικτύου.

Άλκη, σ' ευχαριστώ. Επειδή έχω κάποιες υποψίες* για το (1), γνωρίζεις κάποιο διαγνωστικό που θα μπορούσα να κάνω;

* παλιότερα έκανα cloning κάποιων μηχανημάτων μέσω δικτύου, χρησιμοποιώντας το trinity rescue kit και ανέφερε συνεχώς προβληματικά πακέτα.

[alkisg]

Το σωστό θα ήταν αυτός που έκανε την εγκατάσταση του εργαστηρίου να το είχε ελέγξει με cable tester από άκρη σε άκρη.
Δες αν έχει να σου δανείσει cable tester το ΚΕΠΛΗΝΕΤ σου ή το κέντρο δικτύων της περιοχής σου.

Αλλιώς, για software testing, δεν έχω κάτι συγκεκριμένο να προτείνω, θα μπορούσες ίσως να βάλεις το δίκτυο να παίζει full π.χ. με το iperf και να δεις τα στατιστικά του tcp για dropped frames κτλ.

[odysseas]

Σ' ευχαριστώ.

[odysseas]

Ίσως το μονάδικό μου πρόβλημα αυτή τη στιγμή στο εργαστήριο είναι η περίεργη συμπεριφορά των fat clients μερικές φορές. Προβλήματα όπως η αδυναμία login στο ldm, η μη-ολοκλήρωση της εκκίνησης μερικών εφαρμογών και αρκετά άλλα μικροπροβλήματα.

Κοιτάζοντας την έξοδο του dmesg βλέπω ότι σε όλους αυτούς τους clients εμφανίζονται μηνύματα λάθους για το squashfs (έχω γράψει σχετικά στο 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 αναφέρει ότι το NFS έχει προβλήματα με αυτό το module. Γράφει μάλιστα ότι η απόδοση του δικτύου είναι γύρω στα 25MBps, όσο ακριβώς τη μέτρησα και στο δικό μου εργαστήριο με τη μέθοδο που περιγράφεται στο https://alkisg.mysch.gr/steki/index.php?topic=3324.msg33979#msg33979.

Στο μεταξύ το έψαχνα να δω τι φταίει, και τουλάχιστον για το εργαστήριο του sectorovic βρήκα ότι μάλλον φταίει ο driver της κάρτας, και ότι ένα 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. Αν θες ρίξε μια ματιά, πιο πολλά θα καταλάβεις...

[alkisg]

Στη συνέχεια, κατέφυγα στο NFS_HOME="", το οποίο πήγε την ταχύτητα κοντά στα 100MBps (όσο πάει δηλαδή) και προς το παρόν φαίνεται να λύνει το πρόβλημα.

Αυτό ουσιαστικά απενεργοποιεί το NFS, οπότε οι συγκεκριμένοι clients θα τρέχουν με SSHFS, και επομένως λίγα προγράμματα (evolution, chromium-browser, googleearth) δεν θα τρέχουν σε fat clients.
Είναι το ίδιο με το να απεγκατασταθεί το πακέτο nfs-kernel-server από τον server.

Άλκη, στο link που αναφέρω πιο πάνω εντοπίζει το ακριβές πρόβλημα που έχει το NFS με το TCP και γράφει ότι το λύνει με το ethtool. Αν θες ρίξε μια ματιά, πιο πολλά θα καταλάβεις...

Απ' ότι λέει χρειάζεται νεότερος kernel από αυτόν που έχει τώρα η Lucid, ώστε η κάρτα να υποστηρίξει τη σχετική επιλογή του ethtool που απενεργοποιεί το checksum offloading. Επίσης θεωρητικά με το UDP θα λυνόταν το πρόβλημα, οπότε ίσως να έχεις ακόμα πρόβλημα καλωδίωσης στο εργαστήριο - αυτό θα έλεγχα πρώτα στη θέση σου.

Αν θες να δοκιμάσεις πιο καινούργιο kernel, γίνεται μέσω του αποθετηρίου lucid-proposed (https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS), αλλά θέλει να γίνει και στον εικονικό δίσκο για τα τερματικά, οπότε γενικότερα θέλει λίγο προσοχή σε τόσο ριζικές αλλαγές - κάνε π.χ. backup όλο το /opt/ltsp για να μην παιδεύεσαι να το επαναφέρεις αν κάτι δεν πάει καλά.

[odysseas]

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

Δυστυχώς, τα squashfs errors εξακολουθούν να εμφανίζονται συχνότατα, είτε με UDP, είτε με απενεργοποίηση του NFS. Σήμερα δανείστηκα έναν cable tester όμως δε διαπίστωσα κάποιο πρόβλημα. Όλοι όσοι αναφέρουν ότι δουλεύει το UDP έχουν το module atl1c; Υπάρχει κανείς του οποίου οι κάρτες να χρειάζονται το atl1e, όπως οι δικές μου;

[alkisg]

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

Αφού λοιπόν τσέκαρες το δίκτυο, πάμε στην περίπτωση (3), προβληματικός driver της κάρτας δικτύου.

Αναφέρεις παραπάνω ότι οι αλλαγές στο 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 και για το /, όπως αναφέρεται στην τελευταία παράγραφο αυτής της σελίδας. Αλλά μην το δοκιμάσεις αυτό, δοκίμασε πρώτα το iperf και μετά την αλλαγή kernel + ethtool.

[odysseas]

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

Ναι, καλά έκανες, είναι ενδεικτικό ότι κι εγώ αναρωτιόμουν σε ποιο από τα δύο threads έπρεπε να postάρω. Ευχαριστώ για τις διευκρινίσεις, θα το κοιτάξω.

[odysseas]

Αναφέρεις παραπάνω ότι οι αλλαγές στο lts.conf επηρεάζουν την ταχύτητα του δικτύου, μετρώντας τη με το iperf. Αυτό δεν θα έπρεπε να συμβαίνει.

Έχεις δίκιο, είναι απόλυτα λογικό. Προσπάθησα να αναπαράγω τη διαφοροποίηση της ταχύτητας για να αναρτήσω εδώ τις μετρήσεις. Δεν τα κατάφερα... Το οποίο είναι ολίγον τι ρεζιλίκι, αφενός γιατί το είχα δει με τα μάτια μου, αφετέρου γιατί το πόσταρα και στο άλλο thread αποπροσανατολίζοντας τον κόσμο.  Λοιπόν, το iperf (χωρίς -u) αναφέρει transfer rate ανά client γύρω στα 25 Mbps. Ενημερωτικά, είναι 5 fat clients και 5 thin clients. Οι fat clients και ο server έχουν την ίδια κάρτα δικτύου.

Για να ελέγξεις αν το δίκτυό σου παίζει καλύτερα με 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 και να δεις αν φταίει αυτό.

Εντάξει, θα το προσπαθήσω κι αν χρειαστώ βοήθεια θα ενημερώσω. Άλκη, θερμές ευχαριστίες για το χρόνο σου (ειδικά και γενικά) και από εμένα.

[alkisg]

Ακολουθώντας το 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 το μεσημέρι και τα κάνουμε απομακρυσμένα το απόγευμα.

[odysseas]

Στο 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, θα αναφέρω και αν είναι θα σε ψάξω. Ευχαριστώ.

[odysseas]

Πειράματα με το iperf σε 5 fat clients, συνδεδεμένους σε 100-αρα θύρα.
O server σε gigabit θύρα.

• TCP: ~50 Mbps ανα client => συνολικά γύρω στα 250 Mbps. Αυτό είναι απόλυτα συνεπές με τα ~25 Mbps που μετρούσα με 5+5 clients.
• UDP: Όταν ο στόχος ήταν μέχρι και 90 Mbps ανά client, τα έπιανε πάντα. Μετά η απόδοση έπεφτε αλλά φαντάζομαι ότι δεν έχει και πολλή σημασία.

Αυτό αποδεικνύει ότι υπάρχει πρόβλημα με τη χρήση του TCP;

[alkisg]

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).