QoS Τι είναι και πώς δουλεύει ...

[nicksoti]

Θα πρέπει πρώτα απο όλα ότι μια πλήρη σωστή υλοποίηση QoS απαιτεί να μπορείς να ρυθμίσεις (να κάνεις traffic shaping) και στα δύο άκρα. Στην περίπτωση λοιπόν ADSL αυτό σημαίνει ότι θα πρέπει να μπορούμε να κάνουμε αντίστοιχες ρυθμίσεις και στο άκρο του παρόχου. Κάτι που δεν μπορεί να γίνει..

Μπορεί να είναι πράγματι έτσι, ωστόσο με τον τρόπο που ανέφερα πάνω, σωστά -ξεσωστά, δουλευει, και μάλιστα απρόσμενα καλά, με δεδομένο ότι έχω μια τυπική 512 γραμμή με τα ψιλοπροβληματάκια της, και όχι καμιά 8 mbit.

Και όταν λέω δουλεύει, εννοώ δουλεύει! Δηλαδή κατεβάζω με 50, torrents(10-15 αρχεία με ~100 connections) , και μπαίνω πχ σε server cod2 και παίζω με 50 ping! Και με το που τελειώνω, τσουπ πάλι 50 download. Ενώ πριν με τέτοιες συνθήκες, ούτε σελίδα στον browser δεν τολμούσα να ανοίξω. Και το browsing, που το έχω σε medium, γενικά απρόσκοπτο, καθυστερεί πολύ λίγο, ρίχνοντας ελαφρώς τα torrents στιγμιαία, όσο φορτώνουν οι σελίδες.

Οπότε τελικά αναρωτιέμαι, μήπως υπάρχει αδυναμία στα φτηνά ρουτεράκια, να κάνουν καλό qos, λόγω πχ επεξεργαστικής ισχύος, ή σωστής υλοποίησης. Ειδικά για το τελευταίο, σε πολλά routers υπάρχουν μικροπροβήματα και bugs στο συγκεκριμένο μενού, σε άλλα πρέπει να σώνεις τις ρυθμίσεις, κάθε φορά που μπαίνεις στο interface, άλλα δεν τις σώζουν καθόλου, άλλα δεν αντέχουν, και σε συνδιασμό με ζέστη κλπ "κολάνε", κλπ κλπ.

Περιμένω, όσοι μπορούν να έχουν πρόσβαση σε 2 router, κατά προτίμιση παρόμοια, να δοκιμάσουν αν τους δουλεύει το 2πλό qos, έχω απορία να δω αν απλά μου "έκατσε" εμένα, η γενικά λειτουργεί ο συγκεκριμένος τρόπος.

[anon]

Nαι φίλε μου δουλεύει. Τα torrents & p2p εφόσον παίζουν με tcp μπορείς να τα περιορίσεις.... Ευτυχώς που γίνεται αντιληπτό, ότι το QoS σε οποιαδήποτε μορφή και εαν το χρησιμοποιούμε, εφόσον δεν έχουμε άπλετο bw, βοηθάει....

Οσο για τον προβληματισμό σου για τα φθηνά ρουτεράκια που λές, όντως ισχύει, ειδικά όταν ανεβαίνει ο αριθμός των συνδέσεων. Πχ εαν πάς στο tomshardware.com υπάρχει ένα άρθρο που ελέγχουν μια σειρά απο ρουτεράκια και πως ανταποκρίνονται όταν αυξάνει ο αριθμός των συνδέσεων. Ειναι άκρως αποκαλυπτικό!

Η χρήση δύo QoS που έκανες δουλεύει, γιατί φαίνεται ότι κόβει ή κάνει policy το ένα και έτσι μπορει να κάνει traffic shaping το άλλο ή κάτι τέτοιο. Χαίρομαι που σου δούλεψε, αν και θάπρεπε να έχουμε την δυνατότητα να τα κάνουμε αυτά με ένα ρουτεράκι και όχι με δύο.... Φυσικά μια λύση cisco κοστίζει. Και μια λύση linux είναι too much για ένα σπίτι....

[chatasos]

Hierarchical QoS

[nicksoti]

Η χρήση δύo QoS που έκανες δουλεύει, γιατί φαίνεται ότι κόβει ή κάνει policy το ένα και έτσι μπορει να κάνει traffic shaping το άλλο ή κάτι τέτοιο. Χαίρομαι που σου δούλεψε, αν και θάπρεπε να έχουμε την δυνατότητα να τα κάνουμε αυτά με ένα ρουτεράκι και όχι με δύο.... Φυσικά μια λύση cisco κοστίζει. Και μια λύση linux είναι too much για ένα σπίτι....

Συμφωνώ απόλυτα ότι θα έπρεπε να δουλεύει με 1. Το 2ο router δεν αγοράστηκε γι αυτόν το σκοπό αρχικά, αλλά για να κάνω wireless bridge με το 1ο. Απλά μου προέκυψε. Είμαι περίεργος - επαναλαμβάνω - να δω αν η διάταξη δουλεύει και με άλλα router, πχ 2 USR ή 2 speedtouch. Και λόγω του ότι, πολλοί διαθέτουν ήδη κάποιο που μας έχει έρθει πολύ φτηνά από κάποιο πακέτο σύνδεσης, το να πάρει κάποιος ένα 2ο απλό router, καινούριο ή μεταχειρισμένο, χωρίς να έχει απαραίτητα πάνω και modem και wireless κλπ, ίσως να αξίζει, ΕΑΝ δουλεύει βέβαια ο συνδιασμός

Όσο για το linux, δεν ξέρω, έχω κι εκεί τις αμφιβολίες μου. Τουλάχιστο για τον μέσο χρήστη, που δεν είναι γκουρού στο linux και στα δίκτυα. Είχα δοκιμάσει και με άλλο firmware στο wrt, το DD-wrt, το οποίο υποτίθεται προσφέρει ότι πιο εξελιγμένο σε QOS μπορεί να βρει κανείς σε ένα απλό router, με τεχνικές απ' ευθείας από τον μαγικό κόσμο του Linux. Δούλευε (μόνο του πάντα, με το WAG354 σε bridge mode), αλλά όχι όπως περίμενα. Όπως ακριβώς και το WAG354G μόνο του. Ήθελε πολύ περιορισμό από Netlimiter, και τα αποτελέσματα ήταν μέτρια.

@ndendris: Τα ports στον κάθε torrent client είναι διαφορετικά, άσε που μπορείς να ορίσεις συνήθως και μόνος σου. Στο utorrent που χρησιμοποιώ, έχω βάλει το 32451 TCP, την οποία αλλάζω κάθε εβδομάδα, για λόγους ασφαλείας. Για επιβεβαίωση, μπορείς να κοιτάξεις και το log του router, και να δεις από ποιό port στέλνει ο client που έχεις. Θα το καταλάβεις εύκολα, λόγο της μεγάλης συχνότητας που θα εμφανίζεται. Όσο για τα έτοιμα πεδία που έχει το QOS του WAG354G, με ΗΤΤP, FTP, SMNP κλπ, πρόκειται είτε για port-based QOS, με κάποιες standart πόρτες, πχ 80 για HTTP, αλλά το πιο πιθανό είναι να πρόκειται για layer7 qos, που είναι ανεξάρτητο της πόρτας που χρησιμοποιεί η κάθε εφαρμογή.

Α, και κάθε φορά που "παίζεις" πολύ ώρα με το interface του WAG, στο τέλος πάτα και ένα "save" στο QOS, ακόμα κι αν δεν αλλάξεις τίποτα. Για κάποιο ανεξήγητο λόγο, τα Linksys κάποιες φορές χάνουν τις ρυθμίσεις του QOS, μετά από πλοήγηση στο μενού τους. Επιβεβαιωμένο και με το WAG354, και με το WRT54 με Thibor και DDW-TRT firmware.....

Όσο για το υπόβαθρο των νέων παιδιών...ε χμμ, δεν είμαι και τόσο νέος, εαν αναφερόσουν σε εμένα, στα 32 αισίως.... Και δεν σπούδασα HY, και η δουλειά μου λίγη σχέση έχει με αυτό που σπούδασα... Ευτυχώς υπάρχουν και τα παιδιά που το έχουν σπουδάσει, ή έχουν ασχοληθεί σοβαρά, και δίνουν πολύτιμη βοήθεια και σε εμάς τους χομπίστες. Όπως ο ωραιότατος οδηγός του παρόντος thread, που φυσικά εκτυπώθηκε, διαβάστηκε, και μπήκε στο file-box μου.

Παραθέτω και screenshot των ρυθμίσεων για τον φίλο ndendris.

[ndendris]

Όσο για το υπόβαθρο των νέων παιδιών...ε χμμ, δεν είμαι και τόσο νέος, εαν αναφερόσουν σε εμένα, στα 32 αισίως.... Και δεν σπούδασα HY, και η δουλειά μου λίγη σχέση έχει με αυτό που σπούδασα... Ευτυχώς υπάρχουν και τα παιδιά που το έχουν σπουδάσει, ή έχουν ασχοληθεί σοβαρά, και δίνουν πολύτιμη βοήθεια και σε εμάς τους χομπίστες. Όπως ο ωραιότατος οδηγός του παρόντος thread, που φυσικά εκτυπώθηκε, διαβάστηκε, και μπήκε στο file-box μου.

Φίλε nicksoti, ευχαριστώ για τα screenshots.

Φίλε μου, δεν αναφερόμουν σε κανέναν και ελπίζω να μην με παρεξηγήσατε. Άλλωστε το netiquette είναι βασικό για μένα και προσπαθώ να το τηρώ όσο γίνεται.

Είμαι κοντά 37 χρονών, και σπούδασα Η/Υ (αρχικά πολυτεχνείο και μετά...). Το σχόλιο λοιπόν είναι για το συγκεκριμένο οδηγό, και το παρόν thread, για τα οποίο με χαρά παρατηρώ κάτι που βλέπω να λείπει από τους νέους συχνά σήμερα: Να μάθουμε γιατί κάτι δουλεύει όπως δουλεύει, και όχι "άντε πέστε τη λύση να το μπουρδουκλώσουμε στα γρήγορα"... Το τελευταίο είναι κάτι που δυστυχώς κυριεύει το χώρο μας σήμερα ολοένα και περισσότερο.

[nicksoti]

Φίλε nicksoti, ευχαριστώ για τα screenshots.

Φίλε μου, δεν αναφερόμουν σε κανέναν και ελπίζω να μην με παρεξηγήσατε. Άλλωστε το netiquette είναι βασικό για μένα και προσπαθώ να το τηρώ όσο γίνεται.

Φυσικά και δεν σε παρεξήγησα......

Κι εγώ είμαι άνθρωπος που μου αρέσει να το "ψάχνω" λίγο παραπάνω. Αυτό αποτελεί και ένα μέρος της ευχαρίστησης κάθε ενασχόλησης. Απλά όσο μεγαλώνεις, και το μυαλό αρχίζει να "μπουκώνει", απαιτείται extra χρόνος, που δεν είναι πλέον άπλετος.

για το 2πλό qos: Να σημειώσω, ότι τελικά με το 2πλό QOS, μετά από 3-4 μέρες, το WRT άρχισε να "μπουκώνει", και να κολάει το wireless....... του έπεσε βαρύ φαίνεται.... βάλε και ότι στο σημείο που το έχω βράζει από τη ζέστη.... θα τη βρω την άκρη που θα πάει. Μέχρι να αποκτήσουμε αξιοπρεπείς γραμμές από οτε τουλάχιστο, ώστε το QOS να δουλεύει σωστά, με βοηθητικό ρόλο, μαγικά δεν κάνει δυστυχώς...

[sagiadinos]

Ευχαριστω παιδιά, μου δίνετε κουράγιο να συνεχίζω

Μπράβο φίλε μου, συνέχισε μήπως ξεστραβωθούμε και μείς γιατί, κακά τα ψέματα, οι περισσότεροι έχουμε πλήρη άγνοια πάνω σε τέτοια θέματα.

[Embraced]

Αλήθεια τι άλλη θεωρία σκέφτεσαι να γράψεις; Σκέφτεσαι να γράψεις πχ για περιπτώσεις όπου στη μετάδοση χανονται πακέτα απο παρεμβολές κτλ; Επίσης θα μπορούσαμε να γράψουμε για περιπτώσεις ενος DSLAM που είναι οπως λετε "πίτα" και τι αντίκτυπο έχει σε όσους είναι συνδεδεμένοι σε αυτο. Βεβαια αυτό σε άλλο Thread, είναι κατι πιο απλό αλλά και πιο ευκόλα κατανοητο σε αρχάριους.
Πολύ καλη ολη η προσπάθεια σου, αναβαθμίζει και την εικόνα του site, που πραγματικά στα μάτια μου είναι η εγκυκλοπαίδεια της ευρυζωνικότητας.

[sdikr]

Αλήθεια τι άλλη θεωρία σκέφτεσαι να γράψεις; Σκέφτεσαι να γράψεις πχ για περιπτώσεις όπου στη μετάδοση χανονται πακέτα απο παρεμβολές κτλ; Επίσης θα μπορούσαμε να γράψουμε για περιπτώσεις ενος DSLAM που είναι οπως λετε "πίτα" και τι αντίκτυπο έχει σε όσους είναι συνδεδεμένοι σε αυτο. Βεβαια αυτό σε άλλο Thread, είναι κατι πιο απλό αλλά και πιο ευκόλα κατανοητο σε αρχάριους.
Πολύ καλη ολη η προσπάθεια σου, αναβαθμίζει και την εικόνα του site, που πραγματικά στα μάτια μου είναι η εγκυκλοπαίδεια της ευρυζωνικότητας.

Το θέμα μιλάει για qos, υποθέτει οτι όλα τα φυσικά μέρη (καλώδια, dslam, χαλκος, bbras, οπτικές )


δουλέυουν όπως πρέπει

[anon]

Kαι όχι μόνο αυτό. Εαν έχεις διαβάσει απο την αρχή κάθε κεφαλαίου, θα έχεις δεί ότι μιλάμε για δίκτυο που δεν παρεμβάλεται ΑΤΜ όπως στην περίπτωση των ADSL...

[Sebu]

Πολυ ωραιος ο οδηγος.Συγχαρητηρια σε οσους εργαστηκαν για να βγει αυτο το αποτελεσμα.

Στις ερωτησεις-αποριες μου τωρα:

Εστω οτι εχουμε μια γραμμη 768, με RWIN=48800 και MTU=1500.To MTU Discovery και το Selective ACKs ειναι στο Yes.

Στον οδηγο γινεται λογος για το buffer και ποσο σημαντικο ειναι αυτο!!!Πως το καθοριζουμε ομως το buffer ως αριθμο πακετων???Το RWIN δεν ειναι στην ουσια το μεγιστο buffer που μπορουμε να δεχτουμε σε bytes??? Το MTU δεν ειναι το μεγιστο μεγεθος πακετου που μπορουμε να στειλουμε??? Αρα RWIN/MTU=Αριθμος πακετων buffer???Η μηπως κανω καποιο λαθος καπου???

Αν οντως ισχυει αυτο τοτε αυξανοντας το RWIN θα επρεπε θεωρητικα να εχουμε καλυτερη-ομαλοτερη συμπεριφορα γιατι εχουμε μεγαλυτερη buffer και αρα δεν κοβονται πακετα.Αν ομως αυξησω το RWIN πανω απο ενα οριο τοτε το διαγραμμα του download απο http/ftp γινεται σαν το πριονωτο των περιπτωσεων με μικρο buffer.Και προκειται για download απο την ιδια πηγη αρα μιλαμε για ceteris paribus δλδ δεν αλλαζει ουτε το μεγεθος του πακετου ουτε το latency της γραμμης.

Οταν το MTU Discovery ειναι στο Yes σημαινει οτι το TCP πρωτοκολλο θα ριξει το μεγεθος του πακετου εκει που σηκωνει η γραμμη ωστε να αποφευχθει το congestion???Το MTU θα καθοριζεται καθε φορα δυναμικα ή κλειδωνει για καποιο προορισμο???

Συγγνωμη για τις πολλες αποριες αλλα επειδη εχω διαβασει αρκετα τελευταια για το συγκεκριμενο θεμα απο διαφορες πηγες και επειδη αυτος ο οδηγος ηταν ο πρωτος με παραδειγματα και πειραματισμους με διαφορες παραμετρους ειμαι κοντα στο να λυσω βασικες αποριες.

Ευχαριστω

[EvilHawk]

Αααα μας χρωστάει μια σελίδα ακόμα στο tutorial

[anon]

Εστω οτι εχουμε μια γραμμη 768, με RWIN=48800 και MTU=1500.To MTU Discovery και το Selective ACKs ειναι στο Yes.

Στον οδηγο γινεται λογος για το buffer και ποσο σημαντικο ειναι αυτο!!!Πως το καθοριζουμε ομως το buffer ως αριθμο πακετων???Το RWIN δεν ειναι στην ουσια το μεγιστο buffer που μπορουμε να δεχτουμε σε bytes???

Το RWIN είναι μια buffer, για την ακρίβεια λέγεται TCP Receive Window... Aρα πρώτο στοιχείο. Ειναι μόνο για το TCP και όχι για οτιδήποτε είναι κάτω απο το ΙΡ... Eπιπλέον αυτό είναι στον υπολογιστή σου, όχι στον router /modem, αρα δεν έχει σχέση με την buffer τους, αλλά μόνο στον υπολογιστή σου. Δηλαδή εαν έχεις ένα μικρό lan πχ στο σπίτι σου, το RWIN επηρεάζει όχι μόνο την ιντερνετική συμπεριφορά, αλλά και την συμπεριφορά με το υπόλοιπο τοπικο δίκτυο .

Το MTU δεν ειναι το μεγιστο μεγεθος πακετου που μπορουμε να στειλουμε??? Αρα RWIN/MTU=Αριθμος πακετων buffer???Η μηπως κανω καποιο λαθος καπου???

Μην ξεχνάμε ότι MTU σημαίνει το μέγιστο επιτρεπτό μέγεθος πακέτου που περνά.Τα ΙΡ πακέτα είναι μεταβλητού μήκους. Εαν το ΙΡ πακέτο είναι μεγαλύτερο απο το MTU, θα σπάσει σε κομμάτια. Πχ εαν έχουμε MTU=576 (τυπικό σε dialup συνδέσεις, μικρής ταχύτητας), και θέλουμε να περάσουμε πχ ένα πακέτο 1400 bytes, τότε αυτό θα σπάσει σε τρία μικρότερα, και θα "συναρμολογηθεί" στον προορισμό (fragmentation). Αυτό μπορεί να γίνει και ενδιάμεσα στην πορεία του πακέτου προς το προορισμό, όταν χρειαστεί πχ να περάσει απο κάποια σύνδεση (ρουτερ), όπου το MTU ειναι μικρότερο.
Ενας τρόπος για να δείς το fragmentation (εαν έχεις σύστημα windows) είναι να δώσεις την
εντολή
ping -f -l 1500 {site}
Το -f αποτρέπει το fragmentation, οπότε θα δείς ότι απο ένα μέγεθος και πάνω πρέπει να γίνει fragmentation και για αυτό θα αποτυχαίνει το ping, ενώ για μικρότερο μέγεθος πακέτου (το -l και δίπλα το μέγεθος πακέτου), πετυχαίνει....

Τώρα πόσα πακέτα χωρά η ουρά, εξαρτάται απο την υλοποίηση. Εαν είναι με βάση το μέγεθος του κάθε πακέτου, τότε εαν έχεις μικρά πακέτα, θα χωρά περισσότερα η ουρά. Ομως δεν αφορά το RWIN, γιατί όπως είπαμε αυτό αφορά μόνο το πρωτόκολλο TCP και ειναι στον υπολογιστή μας, ενώ ο router/modem δουλεύει γενικώς πακέτα (ΙP ή σε ποιό χαμηλό επίπεδο, Ethernet / PPP κλπ).

Αν οντως ισχυει αυτο τοτε αυξανοντας το RWIN θα επρεπε θεωρητικα να εχουμε καλυτερη-ομαλοτερη συμπεριφορα γιατι εχουμε μεγαλυτερη buffer και αρα δεν κοβονται πακετα.Αν ομως αυξησω το RWIN πανω απο ενα οριο τοτε το διαγραμμα του download απο http/ftp γινεται σαν το πριονωτο των περιπτωσεων με μικρο buffer.Και προκειται για download απο την ιδια πηγη αρα μιλαμε για ceteris paribus δλδ δεν αλλαζει ουτε το μεγεθος του πακετου ουτε το latency της γραμμης.

Θα πρέπει να καταλάβουμε πως δουλεύει το TCP. Οταν λαμβάνουμε πακέτα TCP, στέλνονται πίσω στον αποστολέα πακέτα ACK ότι έχουμε παραλάβει, διαφορετικά ο αποστολέας θα μας ξαναστείλει το πακέτο TCP (και εαν αυτό επαναλαμβάνεται θα στέλνει με μικρότερη ταχύτητα, γιατί ο αποστολέας θα νομίζει ότι έχουμε μικρότερη ταχύτητα και θα προσπαθήσει να προσαρμοστεί).

Τώρα εαν αυτό γίνεται για κάθε πακέτο, θα φορτώνεται άδικα η γραμμή. Για κάθε πακέτο TCP , να στέλνουμε και ένα ACK. Kαι δεν είναι μόνο, ότι φορτώνουμε την γραμμή προς το άλλο άκρο με πακέτα ACK, αλλά η καθυστέρηση της επιβεβαίωσης (για κάθε πακέτο), θα κάνει την σύνδεση πιο αργή. Αρα η λύση είναι να στέλνουμε πακέτο επιβεβαίωσης για μια ομάδα πακέτων TCP που λαμβάνουμε. Αυτό είναι το Receive Window. Αρα ο αποστολέας στέλνει σωρηδόν πακέτα, και περιμένει επιβαίωση ανα ομάδες και όχι ένα - ένα. Φαίνεται καλό έτσι; Ναι αλλά όμως εαν μια επιβεβαίωση δεν πάει γιατί δεν έγινε λήψη όλων των πακέτων, ή λόγω προβλήματος (CRC error κλπ), σημαίνει ότι αποστολέας θα πρέπει να ξαναστείλει όλη την ομάδα πακέτων, δηλαδή πολλά πακέτα. Ετσι το bw της γραμμής χαραμίζεται, γιατί εαν έχεις πολύ μεγάλο Receive Window πχ 64Κ, και δεν μπορείς να το επιβεβαιώσεις, ο αποστολέας θα πρέπει να ξαναστείλει τα 64Κ ξανά!

Αρα η αύξηση του RWIN δεν είναι πανάκεια, και έχει να κάνει και με τους λοιπούς συντελεστές της σύνδεσης. Εαν έχεις σύνδεση με μικρό latency, μπορείς να χεις μικρό RWIN πχ 8Κ, εαν το latency είναι μεγάλο (είπαμε πέρα δώθε ΑCK κλπ) και είναι εύλογα γρήγορα η σύνδεση (πχ πάνω απο 256Κ) τότε αυξάνεις το RWIN για να βελτιώσεις το Performance του TCP. (για το tcp μιλάμε και όχι γενικά για το ΙΡ).



Και για να δώσουμε ένα παράδειγμα. Εστω ότι έχεiς RWIN 8K. Και κατεβάζεις ένα αρχείο 1ΜΒ και η σύνδεση σου είναι 1Mbps (χωρίς πακετοπροβλήματα και κόφτες ) . Για να κατεβάσεις λοιπόν 8Κ (ενώ δεν κατεβαίνει τίποτα άλλο, και τερματίζεις την γραμμή), έχουμε και λέμε. Κατεβάζουμε με ταχύτητα 125ΚΒ/δευτ. Αρα για τα 8ΚΒ θέλουμε 8/125 = 0,064 δευτ, δηλαδή 64msec (θεωρητικά, στην πράξη περισσότερο). Στο σημείο αυτό λοιπόν ο αποστολέας θα σταματήσει να στέλνει και περιμένει το ACK ότι όλα πήγαν καλά διαφορετικά να ξαναστείλει την ομάδα. Εαν έχουμε λοιπόν ένα latency στα 100-200 msec (αισιόδοξο σενάριο) φαίνεται ότι πηγαίνουν 8Κ (65msec), και περιμένει πχ 200msec να πάρει απάντηση, την στιγμή που σε αυτό τον χρόνο θα μπορούσε να στείλει άλλες 3 ομάδες των 8Κ. Δηλαδή έχουμε "κόψει" την ταχύτητα στο 1/3. Βέβαια εαν αυξήσουμε πολύ το RWIN και πάει κάτι στραβά, ξαναστέλνεται όλη η ομάδα....

Αααα μας χρωστάει μια σελίδα ακόμα στο tutorial

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