Biztosan nincs, és azért nincs mert a meglévő kapacitás >100%-át értékesítik.
Erről van szó. :)
10 éve felmérték a felhasználói szokásokat és rájöttek, hogy a felhasználók kb. 90 százaléka a megvásárolt sávszélességet alig használja ki, ezért kialakítottak olyan csomagokat, amelyekre rányomták a "korlátlan" bélyegzőt, a felhasználók pedig örültek annak, hogy nem kell fizetniük percenként azért (lásd modemes kapcsolat), hogy online a gépük, s nem kell éjjelre ütemezniük a tevékenységeiket, hogy kifizethető és kifizetődő lehessen a kapcsolat.
5 éve felmérték a felhasználói szokásokat és rájöttek, hogy a felhasználók kb. 70 százaléka a megvásárolt sávszélességet alig használja ki, ezért kialakítottak olyan csomagokat, amelyekre rányomták a "gyors és korlátlan" bélyegzőt, a felhasználók pedig örültek annak, hogy nem kell órákat várniuk egy nagyobb állomány vagy videó letöltéséhez. Elterjedtek a P2P szoftverek, a szolgáltatók pedig meghatároztak a korlátlan csomagjukhoz korlátot, de nem léptek fel érdemben a P2P hálózatok ellen, pedig azok szinte mindig szolgáltatók közötti forgalmat generáltak. A P2P megtűrt státusza abból adódik, hogy a P2P fájlcserélés eleinte sávszélességben nem mindig tudta kiterhelni a hálózatot, később a protokollok elemzésével be tudtak vezetni shaping-ot, így a P2P mindig ki tudta tömni a szolgáltatók által vásárolt gerinc sávszélességét, de ezzel nem veszélyeztették a többi forgalom sávszélességét, amikor a "legális" protokoll több sávot igényelt, akkor azt a P2P rovására tette. A felhasználók közül mindenki boldog volt, és ez örömmel töltötte el az ISP vezetőit is.
2 éve felmérték a felhasználói szokásokat és rájöttek, hogy a felhasználók panaszkodnak, hogy a P2P lassú, pedig a szolgáltató nem ezt ígérte a reklámokban, hanem gyors letöltést. Ekkor jelent meg a garantált minimum fogalma, amelyet a szolgáltatónak be kell tartania, illetve fel kell tüntetnie minden hirdetésben. Természetesen még a minimális sávszélesség is overbooking-on alapult, hiszen mindenki nem szokott folyamatosan letölteni ezzel a sávszélességgel, de ebből a számból már megismerhető volt a szolgáltató fizikai infrastruktúrája (például 80Mbps mögött a garantált 8Mbps, vagy 60Mbps mögött a garantált 20Mbps). A szolgáltatók továbbra is tudták a P2P kapcsolatokra shaping-ot tenni, hiszen nincs olyan felhasználó, amelyik P2P esetén _bizonyítani_ tudja, hogy a szolgáltató miatt lassú, illetve _bizonyítani_ akarja egyátalán, hogy P2P fájlcserét használ. Tehát továbbra is minden szép volt és jó... :)
Azonban jött a csúnya Web2.0 és a közösségi feeling divatja, mindenki orrba-szájba videókat és képeket tölt fel, oszt meg, kommentezik, ésatöbbi. A szolgáltató pedig abba a csúnya helyzetbe került, hogy nem elég az a 2-3 évvel ezelőtt femért igényekhez szabott sávszélesség, amelyet megvett vagy fejlesztett. A felhasználók pedig panaszkodnak, hogy nem tudja letölteni real-time a Youtube XYZ videóját, pedig azzel még bőven nincs a szerződésben garantált sávszélesség kihasználva. A szerződés pedig szerződés, annak fehér papírra írt fekete betűit be kell tartani. Ha ez üzleti veszteséggel jár, akkor azzal jár, akkor kellett volna gondolkodni, amikor olcsó, korlátlan és gyors csomagokat "fejlesztettek" ki a szolgáltatók, pedig ebből a háromból csak kettőt tudnak szolgáltatni.
Erre a problémára egy helyes és korrekt megoldás van: a befektetők bebukják az idei nyereséget, a szolgáltatók menedzsmentjét lecserélik, és felmérik újra a felhasználói szokásokat és arra "fejlesztenek" csomagokat. A hűségidős felhasználók pedig _végre_ _egyszer_ az életben jól járnak, mivel a hűségidő alatt a szolgáltató a szerződést és szolgáltatásukat csak az előnyükre módosíthatja.
A sávszélesség jóesetben csak a szolgáltató saját hálózatáig garantált. Ha ennél több kell, akkor bérelt vonalat kell rendelni, de az nem jön ki havi 100k HUF alatt!
Tudtommal a bérelt vonal szintén csak a saját hálózatig garantált... ellenben a rendelkezésre állása nem 95 százalék, hanem 99,5 vagy 99,9 szokott lenni. Más különbséget nem vettem eddig észre. :)
--
http://wiki.javaforum.hu/display/FREEBSD