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

[odysseas]

Επίσης αν μπορείς τρέξε το ίδιο τεστ μεταξύ δύο thin clients, οι οποίοι έχουν διαφορετική κάρτα δικτύου (πάρε κονσόλα διαχειριστή μέσα από την εκτέλεση των sch-scripts).

Για να είμαι σίγουρος οτι καταλαβαίνω τι εννοείς: "το ίδιο τεστ" είναι το τεστ με το iperf; Θες ένας thin client να είναι server κι ο άλλος client;

[alkisg]

Ακριβώς έτσι, για να βεβαιωθούμε ότι δεν έχεις πρόβλημα αλλού, π.χ. στο switch.
Αν από π.χ. realtek σε realtek πιάνεις 95 Mbps,
ενώ από atl1e σε atl1e πιάνεις 50 Mbps,
ε τότε είναι αρκετά βέβαιο ότι φταίει ο driver, οπότε και δοκιμάζεις με νεότερο kernel και απενεργοποίηση του checksum offloading και στον server και στον εικονικό δίσκο.

(επίσης από περιέργεια κοίτα λίγο πόσο πιάνεις από atl1e σε realtek, δηλαδή εννοώ να κάνεις το τεστ μεταξύ του server και κάποιου thin client, και μάλιστα αν μπορείς εναλλάξ, με τον "iperf server" να είναι τη μία φορά ο ένας και την άλλη ο άλλος).

[odysseas]

Στα πειράματα με το 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...  Επίσης, στο netstat (server και fat clients) οι αριθμοί των retransmitted segments και bad segments είναι από αμελητέοι μονοψήφιοι έως μηδενικοί.

Κάτι άλλο τώρα: το ethtool επιτρέπει και τώρα την απενεργοποίηση του checksum offloading. Έκανα λοιπόν:

sudo ethtool -K eth0 tso off

και με την επιλογή -k διασταύρωσα ότι έχει απενεργοποιηθεί. Επανέλαβα τα πειράματα αλλά δεν είδα κάποια αλλαγή.

Αυτό για το οποίο ακόμα δεν είμαι σίγουρος είναι αν όλα αυτά έχουν πράγματι κάποια σχέση με τα squashfs errors, τα οποία εμφανίζονται τυχαία, σε τυχαία μηχανήματα. Άλκη, λίγο ακόμα να το παλέψουμε, είμαι έτοιμος να δεχθώ ότι μερικές φορές θα πρέπει να κάνω reboot και να αφήνω τα παιδιά να με δουλεύουν γιατί είναι τα καινούργια μηχανήματα που έχουν πρόβλημα! 

[alkisg]

Χωρίς 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 και δούλεψέ το έτσι για κάμποσο καιρό να δεις αν καλυτέρευσε.

[odysseas]

Στη συνέχεια κάνε συμπίεση του εικονικού δίσκου μέσα από τα sch-scripts και δούλεψέ το έτσι για κάμποσο καιρό να δεις αν καλυτέρευσε.

Αναφορά: (1) Τα squashfs errors προφανώς δεν εμφανίζονται πια. (2) Τα μηχανήματα πηγαίνουν αισθητά πιο αργά, το δούλεμα λοιπόν το τρώω ούτως ή άλλως. (3)  Υπάρχουν φορές που κάποια μηχανήματα δεν ολοκληρώνουν τη διαδικασία εκκίνησης και χρειάζεται να τα ξαναξεκινήσω. Το μήνυμα που ξεχωρίζω πριν κολλήσουν είναι το "nbd0: hangup". Στους clients που ολοκληρώνουν την εκκίνηση, το αντίστοιχο μήνυμα είναι "nbd0:unknown partition table". Δεν ξέρω κατά πόσο αυτά έχουν άμεση σχέση.

Να ρωτήσω γιατί πρέπει να γίνουν και οι δύο αλλαγές ταυτόχρονα (συμπίεση δίσκου και nbd_proxy); Θα είχε νόημα να πειραματιστώ μόνο με μία από τις δύο;

[alkisg]

Βασικά με το nbd-proxy παίζει το εξής: ο νέος LTSP maintainer του Ubuntu το έβαλε για την περίπτωση του LTSP cluster που συντηρεί, όπου υποτίθεται ότι αν κάποιος από τους πολλούς LTSP servers πέσει, αυτό συνδέεται σε κάποιον άλλο server που δεν έχει πέσει.
Το κακό είναι ότι για όσους δεν έχουν cluster τρώει τζάμπα RAM και CPU.
Επίσης με τον maintainer διαφωνούμε σχετικά με τη σταθερότητά του, εγώ και αρκετοί άλλοι πιστεύουμε ότι κάνει το σύστημα πιο ασταθές, ενώ αυτός το αντίθετο.
Έτσι τα 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;

[odysseas]

Δηλαδή αν π.χ. αντιμεταθέσεις τις atl με τις realtek, μεταφέρεται αυτόματα και το πρόβλημα σε άλλα PC;

Οι atl είναι integrated και realtek δεν έχω!  Θα δανειστώ από πουθενά αλλού και θα αναφέρω.
Ευχαριστώ Άλκη.

[alkisg]

ΟΚ δεν ήξερα ότι οι atl είναι onboard και νόμιζα ότι οι thin έχουν realtek.

[odysseas]

Δανείστηκα (με τη σέσουλα) από το τοπικό ΠΛΗΝΕΤ κάρτες δικτύου 100άρες με τσιπάκι Realtek, τις οποίες τοποθέτησα στον server και στους 5 clients. Με το που bootαρε o πρώτος client κατάλαβα ότι το πρόβλήμα δεν υπήρχε πια -- η διαφορά στην ταχύτητα ήταν αισθητή. Έκανα εκτενείς δοκιμές, δεν υπάρχει αμφιβολία ότι το πρόβλημα είναι στον driver atl1e.

Προχωράω με καινούργιο kernel...

[alkisg]

Έκανα εκτενείς δοκιμές, δεν υπάρχει αμφιβολία ότι το πρόβλημα είναι στον driver atl1e.
Προχωράω με καινούργιο kernel...

Ωραίος! Λοιπόν επειδή δεν βρήκα κάποιο καλό how-to στο Internet για την εγκατάσταση νέου kernel στις LTS εκδόσεις του Ubuntu, γράφω ένα εδώ:

Ανοίγουμε τα 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.

[alkisg]

Γράφω και τη αντίστροφη διαδικασία αφαίρεσης του νεότερου 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.

[odysseas]

Τα καλά νέα είναι ότι η διαδικασία εγκατάστασης του νέου kernel κύλησε ομαλότατα. Ομολογώ ότι τη φοβόμουν γιατί σε ένα σχετικό tutorial είχα διαβάσει την αμίμητη ατάκα: "if it breaks, you get to keep all the pieces...". Δυστυχώς όμως δεν υπήρξε κάποια αλλαγή. Τα squashfs errors επιμένουν.

Τώρα πρέπει να απενεργοποιήσω το tso με το ethtool, αλλά φαντάζομαι ότι αυτό πρέπει να γίνει με κάποιο scriptακι στο /etc/init.d, αλλιώς η απενεργοποίηση δεν είναι μόνιμη (και ούτως ή άλλως τα squashfs errors εμφανίζονται από το bootάρισμα).

Άλκη, αν έχεις προτάσεις...

[odysseas]

Υπόθεση: Έστω ότι, με τον καινούργιο πυρήνα, η απενεργοποίηση του tso (ή του tx όπως διάβασα σε άλλα threads) θα έλυνε το πρόβλημα. Αυτό μπορεί να γίνει και μετά την εκκίνηση στον server αλλά πότε και πως πρέπει να γίνει στους fat clients; Δε θα έπρεπε να γίνει πριν αρχίσουν να διαβάζουν τον εικονικό δίσκο; Έχω προβληματιστεί γιατί δεν ξέρω πως να το δοκιμάσω.

Με την ευκαιρία, επισυνάπτω και ένα syslog από έναν client, για να υπάρχει ένα δείγμα των squashfs errors. Το δεύτερο σετ σφαλμάτων προέρχεται από την κονσόλα που άνοιξα στο μηχάνημα μέσω των sch-scripts.

[alkisg]

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

[odysseas]

Άλκη, ευχαριστώ.

Το πιο σημαντικό όμως είναι να επικοινωνήσεις με τη mailing list των netdev kernel developers ώστε να λύσουν το πρόβλημα σωστά αυτοί χωρίς να βρίσκουμε workarounds...

Ok.