Αναζήτηση:

Μπορεις να ορισεις μικροτερο MTU αν θελεις, αλλα μαλλον δε θα αλλαξει κατι καθως οπως ειδες ο router ηδη κανει MSS clamping αρκετα παρακατω απο το πραγματικο MTU σου.

Εγω δεν εχω προβλημα γιατι φαινεται να δουλευει (πλεον, σε αντιθεση με το παρελθον) το path MTU discovery, και οχι λογω διαφορετικου router.

Αν εχεις προσβαση στο OpenVPN server, μπορεις να εξακριβωσεις οτι οντως αντιμετωπιζεις το προβλημα που ανεφερα νωριτερα, εκτελωντας κατι σαν:

# tcpdump -pn -v -i host <διευθυνση IP του CPE σου στο PPP interface> and greater 1350

Δοκιμασε ο,τι προκαλει το "παγωμα" στη συνδεση και θα δεις το tcpdump να καταγραφει μεγαλα πακετα:

20:38:07.406565 IP (tos 0x0, ttl 64, id 0, offset 0, flags , proto UDP (17), length 1457)
v.p.n.e.1194 > c.y.t.a.63990: UDP, length 1429

Αν στην πρωτη γραμμη το length δειχνει τιμη μεγαλυτερη απο το πραγματικο MTU στο PPP interface (το οποιο βρισκεις με traceroute οπως εγραψα στο προηγουμενο μηνυμα), τοτε ειναι σαφες οτι δε λειτουργει το path MTU discovery και σε "δαγκωνει" το μειωμενο MTU.

Δε νομιζω οτι εχεις προσβαση στο router να αλλαξεις το MTU στο PPP interface, τουλαχιστον οχι στο TG782.

Συμφωνα με τα αποτελεσματα του test, το MSS clamping φαινεται να εχει οριστει στα ιδια με αυτα που εγραψα νωριτερα.

Μπορεις να βρεις το actual MTU παντως χωρις να απενεργοποιησεις το firewall κ.λπ, στελνοντας απλα μεγαλα πακετα UDP με DF set:

$ traceroute -F www.cyta.gr 1500

traceroute to dias1.cyta.gr (78.87.0.8), 64 hops max, 1500 byte packets
1 192.168.10.254 (192.168.10.254) 94.806 ms 99.060 ms 100.027 ms
2 192.168.10.254 (192.168.10.254) 99.976 ms !F-1462 98.933 ms !F-1462 99.934 ms !F-1462

Το παραπανω παιζει σε linux η mac os, αλλα οχι σε windows (tracert, mturoute στελνουν πακετα ICMP που οπως εγραψα γινονται drop απο το TG782 αν > 512 bytes).

Παλιοτερα στη NetOne ειχα αντιμετωπισει ακριβως αυτο το προβλημα. Ψαχνοντας διαπιστωσα οτι ειχα μικροτερο MTU, 1452 αντι 1492 bytes ως συνηθως στο PPPoE. Η εξηγηση του προβληματος με το OpenVPN ηταν οτι το CPE (ST780wl) εκανε μεν TCP MSS clamping, παραλληλα με το ΝΑΤ, ως ειθισται, ετσι το μειωμενο MTU συνηθως δε γινοταν αντιληπτο, π.χ. κατα το σερφαρισμα στο web. Στο OpenVPN ομως, πακετα TCP που στελνονται μεσα στο tunnel τελικα ενθυλακωνονται σε πακετα UDP, για τα οποια δεν υπηρχε μηχανισμος αντιστοιχος με το MSS clamping. Επισης ο OpenVPN client (σε MacOS 10.5) δεν εκανε path MTU discovery. Ετσι παρουσιαζονταν συμπτωματα παρομοια με αυτα που προαναφερθηκαν: ανοιγοντας ενα ssh και εκτελωντας ls -lR / σχεδον αμεσως κολλαγε το session.

Στη NetOne ειχα βρει το πραγματικο MTU κανοντας ping/traceroute με πακετα μεγαλου μεγεθους και DF (don't fragment) bit set, απο μεσα (πισω απο το CPE) προς τα εξω και αναποδα. Προχθες που συνδεθηκα στην Cyta με το Thomson TG782 (καινουρια συνδεση) προσπαθησα να κανω τους ιδιους ελεγχους, αλλα διαπιστωσα οτι by default, με το provisioned configuration της Cyta, υπαρχει ενεργοποιημενο firewall που κοβει α) απο εξω προς τη διευθυνση του PPP πρακτικα τα παντα (icmp, udp, tcp) και β) απο μεσα προς τα εξω πακετα ICMP μεγαλυτερα απο 512 bytes.

Απο το CLI απενεργοποιησα το firewall (firewall config state disabled) και ετσι μπορεσα να κανω ping απο εξω στο PPP με πακετα μεγεθους μεχρι 1462 bytes.. Προσοχη ομως, με απενεργοποιημενο το firewall ειναι προσβασιμο απο το internet τα CLI και web interface του TG782. Για τον αλλο περιορισμο (icmp > 512 bytes) δε βρηκα κατι.

$ ping -M do -s 1434 xxx.dynamic.cyta.gr
PING xxx.dynamic.cyta.gr (178.59.xxx.xxx) 1434(1462) bytes of data.
1442 bytes from 178.59.xxx.xxx: icmp_seq=1 ttl=58 time=40.0 ms

$ ping -M do -s 1435 xxx.dynamic.cyta.gr
PING xxx.dynamic.cyta.gr (178.59.xxx.xxx) 1435(1463) bytes of data.
From 78.87.2.218 icmp_seq=10 Frag needed and DF set (mtu = 1462)

Απο τα παραπανω το MTU φαινεται να ειναι περιορισμενο στα 1462 bytes. Επισης σαφης ενδειξη ειναι το TCP MSS, μετα το clamping. Οπως φαινεται στο http://www.speedguide.net/analyzer.php ειναι 1411 bytes, απο το οποιο προκυπτει οτι η Cyta το εχει ρυθμισει για MTU 1451 bytes, ακομα μικροτερο απο το τρεχον.

Παρολα αυτα εγω δεν αντιμετωπιζω προβλημα με το OpenVPN, μαλλον γιατι, σε αντιθεση με το παρελθον, δουλευει το path MTU discovery στο setup μου. Αν κατι τετοιο δε συνεβαινε παντως, ειμαι σιγουρος οτι θα υπηρχε το ιδιο προβλημα. Το workaround που ειχα εφαρμοσει παλιοτερα, αντιμετωπιζοντας εν μερει το προβλημα χωρις να πειραξω το server configuration, ηταν να προσθεσω στο client configuration την παραμετρο "fragment 1452" (υπαρχει και το mssfix αλλα επρεπε να προστεθει και στο server).

Γενικοτερα πιστευω οτι το περιορισμενο MTU ειναι σοβαρο θεμα, δυσκολο ομως να αντιμετωπιστει γιατι συνδεεται με την τοπολογια του δικτυου του παροχου, ιδιως το transport που χρησιμοποιειται για το backhauling των DSLAMs μεχρι τον LNS.

Αυτο το φαινομενο λογικα θα παρατηρειται στους περισσοτερους συνδρομητες Cyta, τουλαχιστον στην Αθηνα, ωστοσο θα ειχε ενδιαφερον να δουμε αν υπαρχουν εξαιρεσεις.

Παναγιωτη,

Εχω κι εγω γραμμη με παρομοια χαρακτηριστικα attenuation και SNR (υπολογιζω αποσταση περι τα 2.75 Km), που αναγκαστικα εχει κλειδωθει απο το DSLAM χαμηλα για να μην πεφτει. Ειναι κανα τριμηνο τωρα που παιδευομαι με αυτη την ιστορια, ακομα δεν εχω καταληξει καπου, και δε βλεπω να καταληγω συντομα.

Υπαρχει το εξης θεμα με τους βροχους: Καθως δεν υπαρχει καμια εγγυηση για τα χαρακτηριστικα των καλωδιων (περα απο το κλασικο 9600 bps), κανεις δεν μπορει να εγγυηθει οτι αλλαζοντας ενα προβληματικο μεν, operational ωστοσο καλωδιο με ενα αλλο, απο το ιδιο υπαρχον εγκατεστημενο δικτυο παντα φυσικα, θα δεις ετσι καλυτερα αποτελεσματα απο πριν. Και κυριως κανεις δεν εγγυαται οτι δε θα εχεις και χειροτερα αποτελεσματα με το αλλο καλωδιο. Συνεπως η αλλαγη βροχου ισως ειναι και δικοπο μαχαιρι τελικα.
Συν τοις αλλοις, νομιζω οτι η αλλαγη βροχου συνεπαγεται μεγαλο διαχειριστικο βαρος για την (καθε) Vivodi, απο το οποιο καλως η κακως δεν κερδιζουν τιποτε. Ειναι μια διαδικασια χρονοβορα, αβεβαιη, σχετικα νεφελωδης και μαλλον unregulated, συνεπως θα ελεγα hit & run. Γι αυτο και ειναι λογικο να θελει η (καθε) Vivodi οσο γινεται να μην μπλεκει.

Δυστυχως τα σαπια-τραυματισμενα-πεπαλαιωμενα καλωδια ειναι η αχιλλειος πτερνα του ADSL2+, για την οποια κανεις δεν εχει συμφερον να γινεται λογος τη σημερον ημερα που πλεον βρεχει megabit απο παντου. Μονη (ακριβη) λυση να αυξηθει η πυκνοτητα DSLAM ανα περιοχη, π.χ. με συνεγκατασταση σε ΚΑΦΑΟ κ.λπ.

Κανονικα σε interleaved mode τα pings ειναι κατα περιπου 20-25 ms αυξημενα, αλλα ακομα και οταν ηταν σε interleaved παλι 7-8ms εδινε στο πρωτο hop και γενικα δεν παρατηρησα καποια μεταβολη στα pings (για τα οποια θελω να συγχαρω τη Vivodi επι τη ευκαιρια - ελπιζω να κρατησει).

Σε τετοια bitrates δε νομιζω οτι θα επρεπε να βλεπεις τοσο μεγαλη διαφορα μεταξυ interleaved και fast-path. Σε ιδανικες συνθηκες θα μου φαινοταν λογικο κατι σαν 2-3 ms με fast-path vs. 8-9 με interleaved.

Απο τα CRC RX/TX βλεπεις ομως ποσο ευαισθητη στο θορυβο ειναι η μεταδοση σε fast-path. Οποτε σε μια ζορισμενη γραμμη ισως το interleaved mode να δουλευει καλυτερα (πιο σταθερος συγχρονισμος).

Παλι καλα παντως που δεν το εχουν κλειδωσει σε interleaved mode για ολους.

Να κανω μια ερωτηση προς τους "ενεργοποιημενους":

Βλεπω οτι ολοι παιζετε σε interleaved path mode. Κανεις σε fast-path;

Τι latency βλεπετε κανοντας ping στον ppp peer, η στο πρωτο hop με traceroute (οπουδηποτε);
Ειδα 8 ms σε μια περιπτωση. Οι υπολοιποι;

Ευχαριστω kyrbill εμενα με εχεις ηδη καλυψει.

Στο δευτερο link που σου εδωσα πριν, βαζοντας το attenuation μπορεις να δεις μεχρι ποσα mbps μπορει να πιασει η γραμμη σου.

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

Ο τεχνικος δηλωσε βλαβη και θα επανελθει η σου ειπε δεν γινεται τιποτα και ακυρωσες το CableTV;

Σε ποια περιοχη εισαι; Τι ταχυτητα εχεις τωρα;

Στο δευτερο link που εδωσες τα 19 dB δινουν 20983 Kbps downstream. Για καποιο λογο πιστευω οτι δεν ειναι τοσο απλη η εξισωση, και δε βλεπω να μπαινουν πουθενα το SNR και το transmit power σε αυτη.

Μια ειναι η γραμμη. Δεν υπηρξε ουτε βλεπω να υπαρξει αλλη. Η μετρηση εγινε μεσα στο κτιριο. Θα ηθελα να ειχε γινει και εξω αλλα δεν. Τελος παντων, εχω την υποψια οτι η διαφορα μεσα/εξω δεν ειναι χαωδης τελικα, η τουλαχιστον δεν ειναι το προβλημα.

Του ζητησα και δηλωσε βλαβη. Αλλα αυτο δεν αποκλειει το 2ο ενδεχομενο...

Χαλανδρι MAXX2.

Με προχειρους υπολογισμους για attenuation 30 θα επρεπε να πιανεις μεχρι 15mbps.
Προφανως ομως υπαρχει καποιο προβλημα στη γραμμη που θα εβαζαν και για αυτο το χαμηλο νουμερο.
Μια που το σκεφτηκα τωρα τα χαρακτηριστικα αυτα που λες (το SNR, attenuation) κλπ ειναι σε αυτη τη γραμμη που θα ενεργοποιουνταν το CableTV η στην υπαρχουσα που εχεις τωρα. Τωρα εισαι σε Vivodi full η κατι αλλο; Υπ' οψην οτι το CableTV ενεργοποιειται σε καινουργια γραμμη ακομα και αν εχεις shared απο Vivodi.

Ειμαι σε Full LLU εδω και 44 μηνες.

Ευχαριστω για τα 15 Mbps! Κανεις αλλος; :)

Χμ... Τι γινεται στην περιπτωση που οι τιμες που δινει το τερματικο του τεχνικου εχει μεγαλη αποκλιση απο τις τιμες που δινει το ρουτερ?

Το τερματικο ειναι DSL modem, οποτε λογικα...

Αν ωστοσο αναφερεσαι σε ενδεχομενη διαφορα μεταξυ attainable rate και τις πραγματικες τιμες συγχρονισμου, καλη ερωτηση... Αλλα θα μεινω με την απορια, αφενος γιατι ο τεχνικος βιαζοταν και δε βαλαμε το Vood πανω στη γραμμη. Εδω ουτε μια προσθετη μετρηση στο σημειο υποδοχης του καλωδιου εξω απο το κτιριο δεν καναμε, παροτι το ζητησα. Αφετερου και το τερματικο με ADSL2+ linecard (νομιζω) συνεχισε να συγχρονιζει στα 2048/256, κατι που ενισχυει τις υποψιες μου...

Ο,τι ξερει ξερω :(

Εσυ μπορεις να υπολογισεις ποσο περιπου νομιζεις οτι θα επρεπε να ειναι το attainable rate; Αλλος κανεις;

Οταν λες "βγηκε" τι εννοεις; Το μετρησε τεχνικος της Vivodi και σου ειπε τοσο, το ειδες σε καποια στατιστικα router, το υπολογισες με καποιο προγραμμα;

Το μετρησε με το τερματικο του.

Δεν χρειαζεσαι την αποσταση τοτε, αν ξερεις απο την αρχη το attenuation και τα SNR θα μπορουσες να υπολογισεις το πιθανο rate που θα κλειδωνες...
http://www.adslgr.com/forum/showthread.php?t=21205
http://whatismyspeed.interwebit.com/demo/index.php

Τι καθομαστε και συζηταμε τωρα.... Εχουμε γινει μανιακοι με τη γραμμη μας και ποσο πιανει, ετσι για να ξεχνιομαστε μεχρι να μας ενεργοποιησουνε...:p

(και ειμαστε και off-topic)

Τι θα ελεγες αν σου ελεγα οτι με τα εξης χαρακτηριστικα:

Local Tx. Power(dB) : 9.34 Remote Tx.Power(dB) : 19.7
Local Line Atten(dB) : 30.0 Remote Line Atten(dB) : 19.0
Local SNR Margin(dB) : 14.0 Remote SNR Margin(dB) : 24.0

και αποσταση απο το DSLAM περιπου οσο ο kyrbill το attainable rate βγηκε στα 4.5 Mbps downstream και γι αυτο δεν ενεργοποιηθηκε το cableTV;

Δεν μπορω ακομα να καταλαβω γιατι τετοιο attainable rate. Το ψαχνω (η θελω να το ψαξω), γι αυτο ρωταω.

Ειμαστε ακομα off-topic; :)

Να θυμασαι cajoline οτι δεν παιζει ρολο μονο η αποσταση αλλα και η ποιοτητα του χαλκου και της γραμμης...

Αν εχουμε την ιδια περιπου αποσταση απο το DSLAM, και παρεμφερη χαρακτηριστικα attenuation, SNR κ.λπ, δεν ειναι λογικο να περιμενω οτι θα μπορουσα να πετυχω αντιστοιχο attainable rate;

Σ' ευχαριστω, να 'σαι καλα. Ισως μου εφτιαξες τη μερα :)

Μια ερωτηση προς ολους τους ενεργοποιημενους:

Οταν ηρθε ο τεχνικος και μετρησε την καινουρια η υπαρχουσα γραμμη σας, πριν την εγκατασταση του εξοπλισμου, μηπως σας ειπαν σε τι αποσταση βρισκεστε απο το DSLAM;

Η αποσταση μετραται με σχετικη ακριβεια απο το μαυρο ογκωδες τερματικο (tester) που φερνουν μαζι τους, που το ανεμιστηρακι του κανει χαρακτηριστικο θορυβο οταν μπαινει σε λειτουργια. Ομως για να μετρησει την αποσταση ισως πρεπει να αλλαξει στο τερματικο το linecard στο οποιο συνδεει πανω τη γραμμη για να τη μετρησει, οποτε δεν ξερω αν το κανουν σε ολους.

kyrbill, να σε ρωτησω κατι: Οταν ηρθε ο τεχνικος και μετρησε τη γραμμη, πριν εγκαταστησει τον εξοπλισμο, μηπως σου ειπε η ειδες τι αποσταση μετρησε απο το DSLAM;

(Ρωταω ειδικα γιατι με ενδιαφερει σε σχεση με τις μετρησεις Atten/SNR.)

Και τριτο, αυτο μας ενδιαφερει γιατι παρα πολυ απλα οταν η οπτικη ινα ανηκει στη Vivodi μπορει να αυξησει αμεσα το bandwidth οποτε χρειαστει, οταν ομως η οπτικη ινα ανηκει στην Hellascom του ΟΤΕ πληρωνει αναλογα με το bandwidth και επιπλεον η αυξηση δε γινεται αμεσα.

Χωρις να θελω να παρεμβω στη συζητηση σας (lewton-Telecom) απροσκλητος, αλλα και γιατι δεν εχει νοημα, χωρια που ειμαστε εκτος θεματος, ωστοσο:

Τα πραγματα με τα DSLAM και το backhaul->backbone (η οπως θελετε πειτε το) της Vivodi, και οχι μονο, δεν ειναι τοσο απλα.

Καταρχας ως προς το πρωτο εχω την εντυπωση (και νομιζω οτι ειναι γνωστο) οτι σε καποια σημεια (νομιζω τα πρωτα οπου εδωσε υπηρεσιες over ULL) η Vivodi εχει και δηλ. διαχειριζεται η ιδια τα δικα της DSLAM. Σε καποια αλλα το ιδιο πραγμα το παιρνει ως υπηρεσια απο αλλους (συγκεκριμενα εχω την εντυπωση οτι συνεργαζεται-συνεργαζοταν με τις Αττικες Τηλεπικοινωνιες).

Ως προς τη συνδεση των DSLAM με τον κορμο τωρα, το μονο που θελω να πω ειναι οτι γενικα η διαπιστωση πως "οταν η οπτικη ινα ανηκει στη Vivodi μπορει να αυξησει αμεσα το bandwidth οποτε χρειαστει" υπεραπλουστευει καπως τα πραγματα. Ενα ζευγος ινων ως φορεας συνδεσης δυο απομακρυσμενων σημειων μπορει να κουβαλαει διαφορα πραγματα. Αναλογως τι κουβαλαει, πως το κουβαλαει και τι υπαρχει στο καθε ακρο της ινας, το να περασει ενα σημα διαφορετικο η διαφορετικου ρυθμου μεσα απο τον ιδιο συνδεσμο μπορει να ειναι απο εξαιρετικα απλο (1-2 εντολες σε 1-2 συστηματα απο μακρια) μεχρι εξαιρετικα συνθετο (διαφορετικα interfaces, transponders, patchcords κ.λπ).
Το ποσο ευκολο λοιπον ειναι το να "αυξησει το bandwidth" (για οποιοδηποτε σημα περναει μεσα απο το συνδεσμο) εχει να κανει αρκετα περισσοτερο με το πως συνδεονται οι διαφορες συσκευες του δικτυου πισω απο καθε ακρο, παρα με το σε ποιον ανηκει η ινα.
Αλλα και απο οικονομικη αποψη, η συγκριση ιδιοκτητης (η μακροχρονια μισθωμενης) ινας με την ενοικιαση κυκλωματος η υπηρεσιας bitstream δεν ειναι ασπρο-μαυρο, ειναι εντελως διαφορετικα πραγματα που λειτουργουν με εντελως διαφορετικα οικονομικα μοντελα (κοστος αποκτησης, συντηρησης, διατηρησης, αποσβεσεις κ.λπ). Συνεπως και εν ολιγοις δεν ειναι για ολους και σε καθε περιπτωση πιο καταλληλη και συμφερουσα λυση η πρωτη απο τη δευτερη.

Παρεμπιπτοντως στα HellasCom, οπως και στα περισσοτερα ψηφιακα δομημενα κυκλωματα μεχρι Ε1 (ευρος ζωνης μεχρι 2 Mbps), ο φυσικος φορεας δεν ειναι οπτικη ινα αλλα συνεστραμμενο ζευγος χαλκου.

Κλεινοντας επαναλαμβανω οτι η απαντηση μου δεν αφορα την ουσια της συζητησης σας, στην οποια δε θελω να παρεμβω, αλλα μονο τη διευκρινιση ως προς τα παραπανω.

Συμφωνα με τη Vivodi το set-top box (θα) ειναι καποιο απο αυτα που διαθετει η MCOM για την υπηρεσια media stream.

Να κανω κι εγω μια ερωτηση τωρα μηπως ξερει κανεις απο τους τοσους ηδη χρηστες Vivodi LLU που (νομιζω οτι) διαβαζουν το thread. Κι αν ειναι για αλλο thread απλα πειτε μου ποιο (εχω χασει το μετρημα).

Στα καινουρια (?) DSLAM για ADSL2+ (Ericsson?) η Vivodi υποστηριζει και επιτρεπει PPPoE;
Αν ναι, το Vood επιτρεπει αραγε να γυρισουμε το VC για το internet service σε bridging (RFC1483) ωστε να κανω PPPoE απο το δικο μου router;
Αν οχι (γιατι οχι;) τοτε το Vood υποστηριζει και επιτρεπει κανενα αλλο κολπο για να εχω τουλαχιστον public IP address σε δικο μου μηχανακι και να κανω NAT (μονο) εκει; ZIPB/half-bridging (λογικα ναι) η ακομα καλυτερα PPTP-relay;

Εν αναμονη του cabletv, οποιος ξερει ας με/μας (δια)φωτισει...

5)mpeg 2 encoding στη iptv που τρωει ενα τεραστιο μερος της 10mbit γραμμης αντι για το αυτονοητο h264

Η vivo προς το παρον
προσφερει H264

Για την ακριβεια το video service της vivodi, κατα δηλωση των ιδιων, βασιζεται σε κωδικοποιηση-συμπιεση VC-1 (Windows Media) και οχι H.264 (MPEG-4 Part 10). Βεβαια και τα 2 ειναι σιγουρα πολυ πιο bandwidth efficient απο το MPEG-2, αλλα ο εξοπλισμος encoding/decoding σε hardware για το τελευταιο ειναι για την ωρα πολυ πιο διαδεδομενος και φθηνος (και λογω καθολικης αποδοχης του MPEG-2 transport στα προτυπα DVB).

Κι εγω ευελπιστω οτι τελικα θα μπορεσω να φερω το Vood στα μετρα μου, καθοτι φαινεται επαρκως προσαρμοσιμο και πληρες σε features, αν και δε θα παρω ορκο πριν δω ποσο δυστροπο ειναι το διαχειριστικο του περιβαλλον και ποια features/ρυθμισεις θα ειναι προσβασιμα και ποια κλειδωμενα. Αν ειναι βεβαια σε καθε power cycle να κανει reset τα παντα και provisioning απο τον provider, σωθηκαμε. Πιστευω παντως οτι τουλαχιστον το internet service θα παιζει πολυ απλα και με αλλο modem, αν δεν εχουν αλλαξει τις βασικες παραμετρους.

Τελος παντων, επειδη συμφερει για χρηστες full llu (κι επειδη θελω να δω στην πραξη το video service) εκανα κι εγω αιτηση τελικα.

και η παναγια μαζι μας, ευχαριστω!:p
απο τη μικρη μου εμπειρια στη βιβο ειναι ο μοναδικος τροπος να παιρνεις απαντησεις χωρις να περιμενεις σα το βλακα στην αναμονη και ακομα πιο σημαντικο...παιρνεςι απαντησεις που δεν αναιρει η επομενη τηλεφωνικη θεση!
απλα εγω πχ που παιρναω καθε μερα απεξω βολευει (και ενας λογος που επελεξα βιβο), σιγουρα δεν ειναι οτι καλυτερο για αλλους ομως

Καμια αντιρρηση, κι εγω εξαλλου γι αυτους ακριβως τους λογους πηγα, και ελπιζω εσυ να καταφερεις να παρεις πιο ξεκαθαρες απαντησεις.

Τελος παντων, ειναι σημαντικο να ξεκαθαριστει αν α) θα εχουμε πληρη προσβαση στο Vood και β) δεχεται η Vivodi (συμβατικα) να το αντικαταστησουμε με δικο μας εξοπλισμο, αν θελουμε, αποδεχομενοι φυσικα οτι με το δικο μας εξοπλισμο ενδεχομενως να μην παιζει μια η ολες οι υπηρεσιες και οτι η Vivodi δε φερει ευθυνη για αυτο και δεν οφειλει να μας υποστηριξει.

καποιος εθελοντης να περασει απο τα κεντρικα να μιλησει με τεχνικο ρε παιδια!

Καλη τυχη...

Οχι, απολυτως σιγουρος δεν ειμαι γιατι δεν εκανα την ερωτηση "Θα μπορω να πειραζω το Vood;" για να μου απαντησουν ναι η οχι.
Οπως εγραψα, μου απεκλεισαν το ενδεχομενο α) self-install β) να μη χρησιμοποιησω το Vood.
Αν και δε θυμαμαι ακριβως τα διαμειφθεντα, μου εχει μεινει η αισθηση οτι ειδικα στο cabletv θελουν ο χρηστης να μην πειραζει *καθολου*, ει δυνατον, το CPE. Οπως επισης εγραψα ομως μπορει αυτο το καθολου στην πραξη να μεταφραζεται σε περιορισμενη προσβαση, αλλα αυτο δεν μπορω να το ξερω γιατι δεν εχω Vood και τηλεφωνια IP της Vivodi, και δεν ξερω πως δουλευει στην πραξη.

Συγγνωμη αν δεν ειναι απολυτα σαφη τα παραπανω.

Με βαση τις προδιαγραφες του Vood, και καποια πραγματα που θυμαμαι σχετικα με την υλοποιηση του DSLPhone, μου φαινεται λογικο στο cabletv οι 3 υπηρεσιες να χρησιμοποιουν ξεχωριστο ATM VC η καθε μια.
Το ερωτημα ειναι: υπαρχει κανεις που εχει το Vood μαζι με τηλεφωνια Vivodi να μας πει πως δουλευει το συστημα (με 2 υπηρεσιες), αν π.χ. εχει αντιληφθει την υπαρξη 2 VC, αν και κατα ποσο εχει ελεγχο στις ρυθμισεις του CPE και να μας δωσει καποιο αναλυτικο manual του CPE, αν υπαρχει;

Καθως εχω ηδη full llu (απο τον Αυγουστο του 2003), και η τιμη της "προσφορας" ισοφαριζει τα χρηματα που πληρωνω ηδη για "maxx2", μου φανηκε πιθανως ενδιαφερον το "cabletv", οποτε τους επισκεφθηκα για ορισμενες διευκρινισεις.

FYI οριστε τι αποκομισα:
- Το ευρος ζωνης που δεσμευεται downstream για την τηλεοπτικη υπηρεσια ειναι 2 Mbps. Δεν μπορεσα να μαθω ποιο ειναι το αντιστοιχο ευρος ζωνης για την τηλεφωνια, αλλα καταλαβα οτι θα ισχυουν τα ιδια με τις υπαρχουσες υπηρεσιες. Επισης δεν μπορεσα να μαθω ποιο ειναι το ονομαστικο (maximum) ευρος ζωνης upstream, ουτε πως κατανεμεται αυτο στις υπηρεσιες video, φωνης και προσβασης στο internet.
- Ακομη και αν υπαρχει ηδη ενεργος βροχος full llu, οπως στην περιπτωση μου, δινεται χρονος "ενεργοποιησης" γυρω στις 2 εβδομαδες. Αυτο πιθανως να δειχνει ποση ζητηση υπαρχει για το "cabletv", αλλα προσωπικη εκτιμηση ειναι οτι ο χρονος αυτος ειναι απαραιτητος για τη Vivodi για να ολοκληρωσει πριν την επισκεψη του τεχνικου η να συγχρονισει με αυτη τυχον απαιτουμενες αλλαγες: μικτονομιση σε αλλο dslam, παραμετροποιηση πορτας κ.λπ.
- Self installation αποκλειεται. Ο τεχνικος υποχρεωτικα ερχεται, μετραει τη γραμμη, συνδεει εξοπλισμο, ρυθμιζει το CPE και ενεργοποιει τις υπηρεσιες. Δε θυμηθηκα να το διευκρινισω, αλλα εχω την εντυπωση οτι κατα συνεπεια το τελος ενεργοποιησης (η κατι αντιστοιχο) ειναι υποχρεωτικο για ολους, ακομα κι αν υπαρχει βροχος full llu.
- Το CPE ειναι το (γνωστο) Tilgin Vood 452w. Το σημαντικο ειναι οτι δυστυχως οπως καταλαβα εγω ως τελικος χρηστης δεν εχω *ΚΑΜΙΑ ΑΠΟΛΥΤΩΣ ΠΡΟΣΒΑΣΗ* σε αυτο το μηχανημα. Εγκαθισταται και ρυθμιζεται απο τη Vivodi, η οποια και το διαχειριζεται (απο μακρια). Αυτο προφανως σημαινει οτι ξεχνατε ο,τι προσθετες ρυθμισεις τυχον χρειαζεστε (π.χ. port forwarding), ειναι στη διακριτικη ευχερεια της Vivodi να τις οριζει on demand (και δεν εχω προλαβει να δω αν προβλεπεται κατι για αυτο στη συμβαση).
Δεν παρακολουθω τις εξελιξεις με τις υπηρεσιες της Vivodi, αρα δεν αποκλειεται τα παραπανω να σας ειναι ηδη γνωστα η να μην ειναι απολυτα ακριβη τελικα. Ωστοσο για μενα αυτη η "λεπτομερεια" ειναι επιεικως απαραδεκτη, και ειναι ικανος και επαρκης λογος για να μη συνδεθω στο "cabletv", αν τελικα ειναι μη διαπραγματευσιμη παραμετρος του πακετου υπηρεσιων.
Κι αυτο για πολλους λογους (π.χ. εχω ηδη δικο μου εξοπλισμο IP), αλλα κυριως, αν μη τι αλλο, γιατι θεωρω ανεπιτρεπτο να υπαρχει εξοπλισμος IP, στο δικο μου ακρο της γραμμης, ο οποιος εχει εξ ορισμου αμεση και απεριοριστη προσβαση στο δικο μου τοπικο δικτυο, υπολογιστες κ.λπ, και ο οποιος δεν ειναι υπο τον ελεγχο μου, αλλα υπο τον αποκλειστικο ελεγχο καποιου τριτου (οπως η Vivodi).
Χωρις να γνωριζω τιποτε περισσοτερο, πιστευω οτι η Vivodi πρεπει ειτε να δωσει πληρη προσβαση στο CPE και το δικαιωμα στον πελατη να μην το χρησιμοποιησει, με δικη του ευθυνη (ας μην τον υποστηριζει π.χ. με καποιο αλλο setup), ειτε *τουλαχιστον* να δινει την επιλογη για καποιο πιο διαφανη τροπο συνδεσης (PPPoE, ZIPB, PPTP relay) στην υπηρεσια internet, ωστε ο πελατης να μπορει να συνδεσει back-to-back δικο του εξοπλισμο.

Αυτα τα λιγα.

Καλες οι 12μηνες συνδρομες, αλλα Πασχα, Χριστουγεννα, και το καλοκαιρι που οι φοιτητες που σπουδαζουν μακρια απο τον τοπο κατοικιας τους επιστρεφουν σπιτι τους, τι γινεται;Πληρωνουν 4 μηνες χωρις αντικρισμα;

Αν υπαρξει η θεληση, τεχνικα υπαρχει η δυνατοτητα να παγωνει/ξεπαγωνει το service για ενα φοιτητη.

Με τον καιρο θα στρωσουν (πιστευω) ολες οι λεπτομερειες. Υπομονη...

Δεν υπαρχει θεμα εγγυητικης.........το απεσυραν απο την συμβαση!
Να στησω κι εγω τοτε εναν radius server να βγαλω κανενα φραγκο ευκολα.

:)

Δεν ειναι ουτε τοσο απλο (το πρωτο) ουτε τοσο ευκολο (το δευτερο).

Δηλαδη εμεις που δεν εχουμε σταθερο τηλεφωνο,ας ξεχασουμε το Di0DOS :down:Δηλαδη περιπτωση λυσης οπως το FULL LLU της Vivodi που εχω δεν υπαρχει ε?:cry:

Η γραμμη τηλεφωνου (υπο την εννοια PSTN η ορθοτερα PATS) δεν ειναι προυποθεση για το Διοδος αλλα για το ADSL service του ΟΤΕ, καθως οπως ξερεις η εννοια "naked DSL" δεν υφισταται στην Ελλαδα.

Οσοι παροχοι συμμετεχουν στο προγραμμα και μπορουν να χρησιμοποιησουν αλλα δικτυα προσβασης DSL, μπορουν καλλιστα να προσφερουν συνδεσεις χωρις να απαιτειται αυτο που αναφερεται ως "τηλεφωνικη γραμμη".

Ενταξει καλο αγιο ηρθε επιτελους το φοιτητικο internet αλλα στο site λεει ''Για τους προπτυχιακους φοιτητες των ΑΕΙ και των ΑΤΕΙ, η υπηρεσια παρεχεται μονο στην κατοικια του φοιτητη στην ευρυτερη περιοχη της εδρας του οικειου Τμηματος η Σχολης.''. Δηλαδη εγω που σπουδαζω Λαρισα αλλα μενω Βολο και πηγαινω μονο για τα εργαστηρια δεν μπορω να βαλω;:hmm:

Η "ευρυτερη περιοχη της εδρας" σημαινει στο νομο της εδρας και σε ολους τους γειτονικους. Οι νομοι Μαγνησιας και Θεσσαλιας οντως γειτνιαζουν, αρα αν εισαι γραμμενος σε σχολη με εδρα τη Λαρισα μια χαρα μπορεις να βαλεις στο Βολο, εφοσον εκει μενεις και το δηλωνεις υπευθυνα.

Ενα ερωτημα ομως στο helpdesk θα σου ειχε λυσει την απορια.

Η σελιδα του ΕΔΕΤ επρεπε να λεει "μεσω του internet" και οχι "με το internet", ετσι οπως εξαγω απο το http://www.geant.net/server/show/nav.128

Ισως καποιος να μπορουσε να το διευκρινισει.
http://www.dante.net/server/show/nav.190

Η απαντηση απευθυνεται στους... μπαμπαδες:

Στο ΔΙΟΔΟΣ-portal, στις οδηγιες συμμετοχης, στα απαραιτητα δικαιολογητικα, διαβαζω:

* Εγγραφο που εκδιδει ο τηλεπικοινωνιακος παροχος (π.χ. λογαριασμος τελων) απο το οποιο αποδεικνυεται η συνδεση της γραμμης στη διευθυνση κατοικιας του φοιτητη.

Και αν η γραμμη δεν ειναι στο ονομα του φοιτητη αλλα στο ονομα συγγενη η εκμισθωτη του:

* Υπευθυνη Δηλωση του κατοχου της γραμμης οτι αποδεχεται την ενεργοποιηση ADSL προσβασης.


Αρα δε χρειαζεται η γραμμη τηλεφωνου να ειναι στο ονομα του παιδιου. Τωρα για τη γραμμη, as in κυκλωμα προσβασης ADSL, εξαρταται, απο 2 πραγματα:

Πρωτον, η συνδυασμενη (bundled) παροχη και ενεργοποιηση κυκλωματος ADSL ειναι υποχρεωτικη, οπως λεει. Αρα αν καποιος εχει παρει γραμμη απο το retail ADSL του ΟΤΕ (aka HighStream), τοτε σιγουρα δε γλυτωνει τη διακοπη, για να παρει (το παιδι πλεον) ΑΡΥΣ απο τον Παροχο του φοιτητικου.

Δευτερον, αν (ο μπαμπας) εχει ηδη bundled service contract με εναν Παροχο, και (το παιδι) θελει να παρει φοιτητικο bundled service (προφανως απο τον ιδιο Παροχο), δηλ. ο μπαμπας θελει να "κληροδοτησει" την ΑΡΥΣ στο παιδι του, τοτε αυτο (το περιπλοκο σεναριο) ειναι στη διακριτικη ευχερεια του Παροχου, αν θελησει να εξυπηρετησει τον/τους συνδρομητες του. Τυπικα θα πρεπει να γινει διακοπη και επανασυνδεση ΑΡΥΣ, αλλα πρακτικα για τον Παροχο το ενα κυκλωμα μαλλον δε διαφερει σε κατι απο το αλλο.

(Υπαρχει και το helpdesk παντως για ολες τις αποριες, και του γιου και της κορης.)

384 και 512, στην αρχη.

Αν και συγκρινεις ανομοια πραγματα-παροχες, οκ τελικα μπορει να εχεις δικιο. Θα δουμε...

Ναι, συμφωνα με τις μεχρι τωρα προδιαγραφες για τους κανονες επιλεξιμοτητας μπορει να εχει φοιτητικο adsl σε ολες αυτες τις περιπτωσεις. Μελλοντικα δεν αποκλειεται να αλλαξει η αποφαση, ωστοσο σε πρωτη φαση, ακομη και να συνεβαινε αμεσα αυτο, δε θα υπηρχε η δυνατοτητα τεχνικα/νομικα/διαδικαστικα η καθε γραμματεια να λεει ναι/οχι κατα περιπτωση.
Συνεπως, οπως γραψατε... φοιτητικο dsl για παντα, αρκει να εχεις βεβαιωση σπουδων.

Βεβαια χαρα στο κουραγιο του οποιουδηποτε να δινει κατατακτηριες για Χ ευρω το μηνα οφελος :)

Στατιστικα παντως ειναι μικρη η διαφορα (σε απολυτα νουμερα).

Προγραμμα «Διοδος»
Ατεκμηριωτες οι αιτιασεις ΣΕΠΕ για το φθηνο φοιτητικο Internet δηλωνει ο Δ.Σιουφας

15/12/05 15:10

Αθηνα Μεγαλο ενδιαφερον καταγραφεται απο τις ελληνικες επιχειρησεις ηλεκτρονικων επικοινωνιων για το προγραμμα «Διοδος», επισημαινει ο υπουργος Αναπτυξης Δημητρης Σιουφας, αντικρουοντας τις αιτιασεις του ΣΕΠΕ περι «συρρικνωσης του ανταγωνισμου» και «ελλειψης επιχειρηματικου ενδιαφεροντος».

Ο κ. Σιουφας χαρακτηριζει ατεκμηριωτες τις αποψεις του ΔΣ του ΣΕΠΕ και επισημαινει πως δεν προκειται να εμποδισουν την ταχεια εφαρμογη του μετρου.

«Το ενδιαφερον των ελληνικων επιχειρησεων ηλεκτρονικων επικοινωνιων για το προγραμμα «Διοδος» ειναι ηδη σημαντικο, οπως καταδεικνυεται απο τη μεγαλη συμμετοχη τους στην τρεχουσα πιλοτικη φαση υλοποιησης του εργου. Η αποφαση της κυβερνησης να παρασχει στους ελληνες φοιτητες συνθηκες εργασιας παρομοιες με αυτες των αλλων ευρωπαικων κρατων ειναι αταλαντευτη».

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

Επισημαινεται οτι :

- Το προγραμμα «Διοδος» ειναι παραλλαγη αναλογων εργων που εφαρμοζονται εδω και πολλα χρονια σε αλλες της Ε.Ε., στις οποιες δεν εχει τεθει κανενα θεμα κανονιστικης συμβατοτητας η στρεβλωσης του ανταγωνισμου.

- Το προγραμμα «Διοδος» υποστηριζεται καθολικα απο την ακαδημαικη κοινοτητα και απο πολλες φοιτητικες παραταξεις.

Υπενθυμιζεται πως με το προγραμμα «Διοδος» θα δοθει η δυνατοτητα ευρυζωνικης συνδεσης στο Internet, για ολους τους ενεργους φοιτητες των ΑΕΙ/ΤΕΙ, με ειδικους ορους και απλες διαδικασιες.

Οι συνδεσεις θα συναπτονται απο επιχειρησεις παροχης υπηρεσιων Διαδικτυου, οι οποιες θα χρησιμοποιουν ατελως το Εθνικο Δικτυο Ερευνας και Τεχνολογιας (ΕΔΕΤ), για τον περιορισμο του μηνιαιου κοστους καθε χρηστη.

news.in.gr, με πληροφοριες απο ΑΠΕ

Αυτο το κειμενο εκτυπωθηκε απο το in.gr,
στη διευθυνση http://www.in.gr/news/article.asp?lngEntityID=671131&lngDtrID=252

Προσωπικα το μονο που μπορω να παρατηρησω ειναι οτι μου φαινεται καπως παραδοξο να αντιδρουν για το "Διοδος" οι ιδιοι ανθρωποι που (τουλαχιστον συμφωνα με οσα ειδαν το φως της δημοσιοτητας τους προηγουμενους μηνες) με τις σαφως θεμιτες ενστασεις περι καταστρατηγισης του ανταγωνισμου οδηγησαν σε αδιεξοδο το προηγουμενο σχημα για το φοιτητικο ADSL, αδιεξοδο στο οποιο οπως φανηκε ισως δωσει λυση το "Διοδος".

Γιατι δε φροντισαν λοιπον να μην αφησουν να βαλτωσει το προηγουμενο σχημα, που θα εξυπηρετουσε ισως καλλιτερα και την αναπτυξη της αγορας που αναφερουν, απαντωντας π.χ. στο κατω του κοστους 5€ του ΟΤΕ με δικη τους αντιπροσφορα, εστω οχι τοσο φτηνη, προσπαθωντας παραλληλα και με τα νομικα επιχειρηματα να περισωσουν τον ανταγωνισμο. Οπως φανηκε ομως αρκεστηκαν μονο στα τελευταια, και μαλιστα υιοθετωντας τη λογικη της ισοπεδωσης της αγορας προς τα κατω και οχι της εξευρεσης μιας λυσης, με καποιες προσκαιρες παραχωρησεις, που θα συνεβαλε ομως στην ουσιαστικη αναπτυξη της αγορας. Και το αποτελεσμα της καθετης αντιδρασης, αναποφευκτα, αδιεξοδο.

Ομως ο "υψηλος στοχος της διαδοσης του Internet" και της ευρυζωνικοτητας, που αναγνωριζει και ο ΣΕΠΕ, προφανως θελει θυσιες, τις οποιες ωστοσο ουτε και προσκαιρα εστω δε φαινονται και οι Παροχοι διατεθειμενοι να επωμιστουν...

Τα περι "κωδικης ονομασιας" Ηφαιστιων, Hfestion κλπ ειναι αποκυημα της φαντασιας καποιου, ισως δημοσιογραφου, που μαλλον "μπερδευτηκε" απο κατι πολυ απλο και αθωο, η αφησε τη φαντασια του να καλπασει...
Δε φταιει κανεις αν καποιοι αρεσκονται σε υπερβολες και δε σημαινει οτι ολοι ασχολουνται μονο με "αμερικανικες μαλακιες" με τα ονοματα.

http://www.adslgr.com/forum/showthread.php?t=20827&page=28#411

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

The VoIP Backlash

Καποιοι Αραβες πληρωνουν για μια λυση στο προβλημα τους, καποιοι αλλοι τα 'καταφερνουν" καλλιτερα μονοι τους...

(:offtopic: :spam:)

Για το ποντικι δεν εχω ορισει καποιο passkey, αλλα για το πληκτρολογιο ορισα ενα δικο μου κωδικο.



Το θεμα ομως ειναι οτι απαξ και μπω σε περιβαλλον Linux, το πληκτρολογιο φαινεται να απορυθμιζεται και να μη δουλευει στο επομενο boot (και απο reboot και απο shutdown). Ετσι, δεν μπορω να χρησιμοποιησω πληκτρολογιο ουτε στο GRUB (και στο BIOS γενικοτερα), ουτε στα Windows. Το αποτελεσμα ειναι να φορτωνουν τα Windows (μιας και ειναι το προεπιλεγμενο OS) και μεσω του ποντικιου να αφαιρω και να ξανα-προσθετω το πληκτρολογιο.


Αυτο ειναι το βασικοτερο προβλημα με τα περιφερειακα bluetooth, οτι δηλαδη ια να λειτουργησουν χρειαζεται να φορτωθει software stack. Αυτο προφανως δεν ειναι διαθεσιμο την ωρα που ο υπολογιστης δεν εχει εκκινησει ακομα το Λ/Σ. Συνεπως δεν μπορεις ουτε sto boot loader, ουτε στο bios να επεμβεις με αυτο το πληκτρολογιο. Το συνειδητοποιησα κι εγω προσφατα οταν μου προσφεραν δωρο το συγκεκριμενο πακετο. Αλλωστε αν παρατηρησεις καπου πανω στη συσκευασια η στο εγχειριδιο το αναφερει εμμεσως: "μπορει να χρειαστει να χρησιμοποιησετε αλλο πληκτρολογιο & ποντικι για να εκτελεσετε την εγκατασταση".

Λυση σε αυτο το προβλημα θα δοθει μονο αν καποια στιγμη στο μελλον οι κατασκευαστες βγαλουν αντιστοιχο usb bluetooth dongle που θα ειναι πιο εξυπνο, δηλ. θα μπορει να φορτωσει μονο του στο δικο του υλικο το απαραιτητο software για να λειτουργησει transparently απο το Λ/Σ. Αλλα τοτε μαλλον δε θα χρειαζοταν USB διεπαφη, θα μπορουσε να εχει PS/2, και πιθανως να χρειαζοταν και δικη του αυτονομη τροφοδοσια...

Ενα αλλο θεμα που δεν εχω ψαξει ακομα ειναι αν υπαρχει καποιο αλλο (οχι Microsoft) bluetooth stack για Windows, που να ειναι λιγοτερο intrusive, δηλ. να μη σου φορτωνει αναγκαστικα το IntelliPoint/IntelliType. Αυτο ξεσκιζει οποιους αλλους ειδικους HID drivers υπαρχουν στο συστημα, π.χ. για τα touchpad/stick σε notebook, ετσι ουτε εκει εχει νοημα να το χρησιμοποιησει κανεις. Ιδανικο θα ηταν καποιο stack που να ειναι συμβατο και με περισσοτερα προφιλ bluetooth, οπως headset η hands-free η και αλλα, διοτι οπως καταλαβα η Microsoft δεν μπηκε στον κοπο να ασχοληθει με αλλα προφιλ περα απο αυτα που χρειαζονται για τη συγκεκριμενη δουλεια (HID)...

Τελος, οσο γιατι δε σου δουλευει το πληκτρολογιο οταν ξαναμπαινεις στα Windows, το ειπες και μονος σου: οταν κανεις pairing στο Linux, η συσκευη ξεχναει το προηγουμενο ζευγαρωμα που ειχε κανει στα Windows.

Γενικα απο ολα τα παραπανω ειναι προφανες οτι ο κατασκευαστης δεν ελαβε υποψη του τετοιες "advanced" χρησεις (dual booting) και δε θεωρει αναγκαιο ο χρηστης να μπορει να χρησιμοποιησει το πληκτρολογιο του πριν ξεκινησουν τα Windows. Τουλαχιστον οχι ο χρηστης στον οποιο φαινεται να απευθυνεται αυτο το (ακριβουτσικο) προιον...

Αν δεις στο εξωτερικο (δεν ξερω αν εκει δινουν στους φοιτητες) η ογκοχρεωση ειναι κατι το συνηθισμενο ;)

Το συνηθισμενο δεν ειναι ακριβες. Απο τα δυο παραδειγματα που αναφερονται στο αρθρο, στην περιπτωση του Surfsnel δεν υπαρχει ογκοχρεωση, ενω στο DFN@home υπαρχει (ομως το συγκεκριμενο -γερμανικο- NREN εχει και καποιες αλλες ιδιαιτεροτητες σε σχεση με τα υπολοιπα).

Τι ειδικοι ειναι αυτοι αραγε;

Να στο πω απλα, ας παρουν μεσω ΕΔΕΤ, (αλλα λογο ΕΔΕΤ no p2p, no mp3, maybe not video chat)

Τι σε κανει να πιστευεις οτι τοτε θα υπηρχαν τετοιοι περιορισμοι; Οπως εχει αναφερθει και στο παρελθον, τετοια πραγματα επιβαλλονται απο τους ιδιους τους φορεις η επιμερους νησιδες, εργαστηρια κ.λπ. και οχι απο το ιδιο το δικτυο του παροχου. Και οπου υπαρχουν τετοιοι περιορισμοι τελος παντων, αυτο συνηθως γινεται για πρακτικους-λειτουργικους λογους (αν και προφανως δεν ειναι η καλυτερη λυση) και σπανια (αν οχι ποτε) με στοχο καποια "αστυνομευση" της κινησης.

Ειναι πολυ σημαντικη η λεπτομερεια που αναφερεται στο παραπανω αρθρο: οτι δηλαδη τα 5 GB, η οσα ειναι αυτα τελος παντων, σε καμια περιπτωση δεν μπορει να γινει δεκτο οτι επαρκουν για webcast, e-class κ.λπ. (για τους ελαχιστους τυχερους βεβαια για τους οποιους τα τριτοβαθμια ιδρυματα παρεχουν τετοιες πολυτελειες).

Και τελος, περα απο το χαμηλοτερο τελικο κοστος, καποια ακομη πλεονεκτηματα που ισως δεν εχουν αναφερθει:
- διευθυνσιοδοτηση απο το φορεα του φοιτητη (σε πολλες περιπτωσεις σημερα αυτο διασφαλιζει αυτοματα προσβαση σε συνδρομητικες βιβλιοθηκες του εξωτερικου, η αλλες εσωτερικες υπηρεσιες)
- περαιτερω δυνατοτητες που δεν παρεχονται σε μια κλασικη υπηρεσια internet: multicast, ipv6 κ.λπ.

Αν εχετε ελεγχο στον nameserver που υποστηριζει το adslgr.com, γιατι δεν μειωνετε τα refresh και expire του domain στο SOA record ωστε οταν αλλαξετε IP στον server να ενημερωθουν ολοι γρηγοροτερα;

-Κ.

Φανταζομαι οτι η εγγραφη δε θα αφαιρεθει ποτε τελειως απο τη ζωνη, οποτε τυχον nxdomain caching λογω SOA δε θα επηρεασει. Μπορουν ομως να μειωσουν απο τωρα το TTL του ιδιου του A RR πχ για το www, ωστε ο resolver να ρωταει πιο συχνα. Βεβαια πολλοι name servers εχουν εσωτερικα ελαχιστο οριο για τα records που κανουν cache, οποτε δεν εχει νοημα και το πολυ μικρο TTL αν φθασει κανεις στην αλλη ακρη.

Μην εγκαθιστατε σειριακα τα πακετα, αλλα ολα μαζι, οσα πρεπει να μπουν, σε μια εντολη, ωστε να γινει ενα transaction.
Αφενος το μοναδικο transaction ειναι πολυ πιο γρηγορο (δεν επαναλαμβανονται ερωτηματα και κλειδωματα στην rpmdb), αφετερου ετσι δε θα εχετε προβλημα με αλληλεξαρτησεις καθως ο rpm θα υπολογισει μονος του με ποια σειρα πρεπει να μπουν ωστε να γινουν ικανοποιηθουν τα requirements κ.λπ.
Αν υπαρχουν και αλλα πακετα στο directory που δεν πρεπει να εγκατασταθουν, χρησιμοποιειστε καποιο pattern που να τα αποκλειει (η να μην τα περιλαμβανει). Για τη συνταξη δειτε το σχετικο κεφαλαιο στο manual του bash(1):
EXPANSION -> Pathname Expansion, Pattern Matching

Τα cisco που εχουν μπορουν να κανουν αριστη δουλεια σε οτι αφορα το κοψε/δωσε στο bandwidth

Αν με αυτο ο icedfun εννοει οτι οι routers αντιλαμβανονται αν το πακετο ειναι π.χ. απο το μουλαρι τοτε δεν υπαρχει σωτηρια (ουτε ελευθερια, ουτε ειρηνη, ουτε μαρια ...:roll: ).
Εγω δεν ξερω τι παιζει αλλα θα μου εκανε πολυ εντυπωση να μαθω οτι η Cisco η οποια αλλη εταιρια θες που κατασκευαζει routers εχει ενσωματωσει λογισμικο που ανιχνευει τετοια πακετα.

Μια χαρα γινεται και με misko και με linux, φυσικα παντα με αναλογο "κοστος".

Οχι οτι θα εχει 100% αποτελεσματικοτητα, παντως αν ειναι αναγκη ειναι μια χαρα εφικτο.

Αλλα δεν εχει κανει κατι τετοιο η Vivodi. Δεν ξερω τι εχει κανει, αν εχει κανει. Ισως κατι σε ξεχωριστη ουρα για τους φτηνιαρηδες πελατες, αλλα και παλι οχι σιγουρα (ξερω αρκετους με dslphone που δεν εχουν κανενα προβλημα) και οχι παντου.

Συμφωνα με τις συνεντευξεις της προεδρου της Vivodi και αλλες πηγες πληροφοριων, εχει επενδυσει καπου 30-40 εκατομμυρια απο το 2001 που ανοιξε μεχρι σημερα. Hard to believe? Εγω δεν θα το λεγα, καθως πολυ πιθανον να μην αναφερεται μονο σε σταθερο εξοπλισμο (π.χ. το CISCO DSLAM των εκατονταδων χιλιαδων Ε που τυχον αγοραζει για να φτιαξει δικτυο) αλλα και στα τρεχοντα κοστη (π.χ. το οτι για να εχει καποιο καλο παιδι ας πουμε στον Πειραια DSL απο Vivodi, ολο και καποιο κοστος θα εχει αυτη για το γεγονος οτι πρεπει να διασυνδεει το DSLAM της με ΟΤΕ γραμμες με τον ΟΤΕ - λεγε με "ο μονος τροπος για να δουλεψει ανθρωπινα το Shared LLU" ).

Ποσο το αγοραζει λεει το DSLAM; Για χαλαρωστε λιγο... με "εκαντονταδες χιλιαδες ευρω" ουτε CRS1 να επαιρνε! Και το DSLAM δεν παιρνει δα και καμια τοσο πια πανακριβη linecard για το uplink.

Οσο για τα κυκλωματα ειναι γνωστο, αλλα τι να κανουμε, ολοι πληρωνουν χαρατσι hellas stream για να συνδεθουν στο ΟΤΕ-ADSL. Για τη Vivodi βεβαια και τις συνδεσεις των δικων της DSLAM ειναι επισης γνωστο οτι πολλα (η μηπως τα περισσοτερα) link στην Αθηνα ειναι ακομα ασυρματα. Υποτιθεται, και το ειχαν ανακοινωσει καποτε, οτι συμφωνησαν να τους δωσουν ενα δακτυλιο οι Αττικες, αλλα προσωπικα δεν ξερω τι απεγινε, αν και τι εριξαν πανω εκει.

Για τα ελληνικα δεδομενα παντως 10Μ Ε ειναι αρκετα αν οχι πολλα λεφτα. Εχουν στηθει metro δικτυα με πολυ λιγοτερα. Αλλα ακομα και αν μιλαμε και για 100 χιλιομετρα σκαψιμο, ειναι πολλα τα λεφτα. Στα ευρυζωνικα της ΚτΠ για παραδειγμα (105) το συγκριτικο budget ανα χιλιομετρο ειναι μαλλον σημαντικα μικροτερο. Ενταξει ναι μεν στην Αθηνα το κοστος ειναι μεγαλυτερο, αλλα ακομα και η Tellas που εσκαψε παντου πολυ αμφιβαλλω οτι εδωσε τοσα λεφτα.
Συνεπως πιστευω οτι το πιθανοτερο ειναι να τα προοριζουν (και) για αλλα πραγματα τα λεφτα, εκτος απο ινες και χαλκο.

Δεν εχω ιδεα ομως τι :?

cajoline εγραψε:

Οποτε ισως εχει νοημα να ζητησει καποιος να τον γυρισουν σε fast-path απο interleave για να διαπιστωσει αν εχει διαφορα.


-20 μεχρι -40 ms στο ping Wink


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

Εγω απλα δεν εχω την παραμικρη ιδεα :roll:

Συνεπως τη διαφορα την κανει το dslphone και το διαφορετικο προφιλ (παιζει με fast-path) που χρησιμοποιειται σε αυτη την περιπτωση. Εγω δεν εχω dslphone αλλα το επιβεβαιωνει και ενας φιλος που εχει ενεργοποιησει την υπηρεσια.

Οποτε ισως εχει νοημα να ζητησει καποιος να τον γυρισουν σε fast-path απο interleave για να διαπιστωσει αν εχει διαφορα. Να δουμε κιολας αν η Vivodi το κανει αυτο πια, γιατι παλιοτερα δε δεχοταν να κανει τετοιες αλλαγες.

Θεμα ελλειψης bandwidth στο upstream των DSLAM κατα τη γνωμη μου δεν τιθεται αφου αν υπηρχε τετοιο προβλημα θα ηταν φανερο και με αλλους τροπους, ενω γενικοτερα εκτος απο 1-2 περιπτωσεις που παρουσιαστηκε κατι τετοιο και λυθηκε μεσα σε 10 μερες μετα απο ασταματητα παραπονα και πιεση των χρηστων της περιοχης, δεν εχουν ακουστει αλλα παραπονα, οπως συμβαινει αντιστοιχα σε "πιταρισμενα" DSLAM του ΟΤΕ.

Το multicast μπορει να ειναι ενα καλο κινητρο για την τρεχουσα τοπολογια αλλα προσωπικα δεν πιστευω οτι η Vivodi κοιταζει τοσο μακρια. Δηλ. οταν και αν καποτε αποφασισει να παρεχει μια υπηρεσια διανομης περιεχομενου, τοτε και μονο προβλεπω να το λαβουν υποψη στο σχεδιασμο του δικτυου.

Υποψην παντως οτι η Vivodi καθοτι παντου εχει δικο της L2 δικτυο (και δε νομιζω να προβληματιζεται ιδιαιτερα για την ασφαλη διοδευση της κινησης αλλων ISP, π.χ. HOL), θα μπορουσε μια χαρα να βολευτει και με κατι ελαφρυτερο απο L2TP.

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

Δεν μπορω να ξερω τι DSLAM χρησιμοποιει η Vivodi, αν ειναι 6015 η κατι αλλο. Και δεν υποστηριζω οτι δεν μπορουν να παιξουν καλα με το τρεχον στησιμο. Με τον ορο ciscoκουτα εννοουσα απλα οτι ως γνωστον η Vivodi χρησιμοποιει αποκλειστικα εξοπλισμο Cisco. Μπορει να μην ειναι λοιπον τα DSLAM αλλα ο παραδιπλανος δρομολογητης, η οτιδηποτε αλλο στον κομβο. Το γεγονος παραμενει οτι στο 99% των περιπτωσεων το RTT στο πρωτο hop σε καθε pop της Vivodi ειναι ασυνηθιστα υψηλο. Το οτι υπαρχουν και καποιοι οπως ο ibari που παιζουν σωστα ειναι η εξαιρεση που επαληθευει οτι γινεται και καλυτερα.

Και τελος παντων οταν λεω "η προσπαθεια επεσε στο κενο" δεν εννοω οτι δεν τα καταφεραν λογω τεχνικων περιορισμων αλλα οτι απλα η οποια αλλαγη ξεκινησαν να κανουν τελικα αναιρεθηκε επειδη βγηκαν στη μεση πολλα προβληματα. Το γιατι σκονταψαν ειναι κατι για το οποιο δεν εχω την παραμικρη ιδεα.

Ας μας πει λοιπον ο ibari, αν θελει, σε ποια περιοχη συνδεεται, ποσο καιρο εχει συνδεθει και μηπως παιζει σε fast-path και οχι interleave που ειναι το συνηθες στη Vivodi, αν τυχον το εχει παρατηρησει.

Εχει και παραεχει σχεση, γιατι απο αλλο σημειο και με αλλους ορους ξεκιναει η δρομολογηση του ενος και του αλλου στη μια και στην αλλη περιπτωση.
Δειτε την απαντηση μου στο αλλο thread Vivodi και Latency με ελληνικα δικτυα.

Αυτο που γραφει ο terper αποδεικνυει αυτο που φανταζομουν. Για οσους συνδεονται μεσω ΟΤΕ τα πραγματα ειναι μια χαρα. Κι αυτο γιατι ειναι ο ΟΤΕ που τερματιζει την ενθυλακωση PPP κι οχι η Vivodi. Απο εκει και περα ειναι θεμα δικτυου, αλλα δε νομιζω οτι υπαρχει ιδιαιτερο προβλημα, κι οπου ισως υπαρχει, π.χ. στο εξωτερικο, ειναι θεμα του φορεα της κινησης της Vivodi κι οχι του δικτυου της.
Η διαφορα λοιπον ειναι προφανης: ο terper φτανει στο www.vivodi.gr (αλλα και στον achilles.noc.ntua.gr) με RTT 29 ms, ενω ο Zarzour για παραδειγμα (που εχει τη Vivodi ως παροχο DSL) με το που μπαινει στο δικτυο ξεκιναει με "penalty" 62 ms.
Αυτο οφειλεται στο γεγονος οτι ο ΟΤΕ τερματιζει το PPP σε δυο μολις σημεια κεντρικα, οπου εχει δυνατα μηχανακια που ανταποκρινονται μια χαρα σε αυτη τη δουλεια, ενω η Vivodi (ως παροχος DSL) τερματιζει το PPP ουσιαστικα επι τοπου στο καθε DSLAM, οπου το εκαστοτε μηχανακι δεν ειναι τοσο δυνατο, εχει λιγοτερη μνημη, υποφερει επειδη κανει authentication σε radius που βρισκεται στην αλλη ακρη του δικτυου της εταιρειας κ.λπ.
Ειναι γνωστο το θεμα, ειχα ρωτησει σχετικα καποιους τεχνικους περυσι μια εποχη που πειραματιζονταν με αυτο (ειχε γινει και καποιο renumbering αν θυμαμαι καλα) και υπηρχαν καποια παροδικα προβληματα οτι δεν μπορουσαμε να κανουμε login, και μου ειχαν πει τοτε οτι προσπαθουσαν να μεταφερουν τον τερματισμο κεντρικα. Η προσπαθεια επεσε στο κενο και προφανως γυρισαν στην προτεραια κατασταση, η οποια ισχυει μεχρι σημερα.

Συνεπως αν δεν αλλαξει αυτο ωστε να γινεται ο τερματισμος κεντρικα σε πιο καταλληλα μηχανηματα η αν δεν αναβαθμισει μαζικα η Vivodi ολα τα ciscoκουτα με ο,τι ισως τους λειπει, δεν προκειται να αλλαξει κατι ως προς αυτο. Τωρα βεβαια μπορει να υπαρχουν κι αλλοι λογοι που η Vivodi προτιμα να δρομολογει καθαρη IP κινηση απο τους κομβους της αντι για ppp, οπως π.χ. το integration με την κινηση των εταιρικων πελατων (που δεν εχουν ppp), η οτι δεν ξερει η δεν μπορει να δρομολογησει τα ενθυλακωμενα πακετα σωστα μεσα σε σηραγγες απο τις ακρες (τα σημεια παρουσιας της) μεχρι τον κορμο (τα κεντρικα στην Αθηνα), η ακομα και αλλοι, ασχετοι λογοι, π.χ. οτι καποιοι ισως να προτιμουν/βολευονται να παραμενει πιο "αποκεντρωμενο" το δικτυο.