Wanneer begint en eindigt de dag (bij scarlet)?

[Pleuris]

Er is niks filosofisch aan de titel. Ik heb al meermaals ontdekt dat het verbruik niet echt van 0u tot 24u loopt.

Voorbeeld, de laatste dag van mijn "scarlet"maand download ik van 16 tot 22u 90GB. Daarna nog wat genetflixed en dan in mijn bed gekropen. De eerste ochtend van de nieuwe maand kijk ik het verbruik na en er staat 30GB verbruik op de nieuwe maand.

Nu zaterdag ook weer zo iets. Een 20GB gedownload overdag, s'avonds een aflevering strager things in UHD tussen 22 en 23u en de hele zondag was ik tot maandagochtend weg. Toch zondag 7GB verbruik terwijl er volgens mij niets van verbruik is geweest. De NAS geeft geen verbruik in zijn log weer en alle toestellen stonden uit.

Weet iemand hoe dat komt, of werkt scarlet op een andere klok en begint de dag bv om 20u ipv 0?

[on4bam]

Wilde gok... van 22:00 tot 21:59 ofte UTC/GMT zodat ze geen rekening moeten houden met winter/zomeruur?

[Pleuris]

Het klinkt aannemelijk. Zal het de komende dagen proberen wat na te kijken.

[Pleuris]

Het lijkt inderdaad zo rond 22u te zijn dat het einde van de scarlet dag is.

Dankzij de traffic analyzer van mijn router heb ik het een paar dagen wat in de gaten proberen te houden.

[on4bam]

Het lijkt inderdaad zo rond 22u te zijn dat het einde van de scarlet dag is.

Het was mijn eerste idee aangezien hier ook alles op UTC draait

[philippe_d]

Ik heb het eens nagevraagd bij Scarlet.

De discrepantie tussen het reëel verbruik en de Telemeter is niet het gevolg van een foute klok of zo.

Voor het verbruik is er een mogelijke vertraging van 4u in het berekenen van de verbruikte GB’s omdat dit soms niet real-time gebeurt. Voor de duidelijkheid: Dit is niet altijd zo, er is een mogelijke vertraging van 4u.

Op het ogenblik dat de download limiet ingevoerd wordt, zal je dus pas later ‘squeezed’ zal worden dan jouw effectief verbruik, gezien deze mogelijke vertraging ...

[Pleuris]

bedankt voor de extra info. Maar dan nog...

Vind het wel jammer als het echt zo zou zijn. In deze digitale wereld zou men er toch van uit gaan dat verbruik DIRECT (of toch met steeds dezelfde vertraging van bv 15 min of zo) wordt geregistreerd. Nu er geen echte downloadlimiet is is dat minder belangrijk. Maar als men de 300GB wil invoeren hoop ik dat men wat sneller gaat tellen.

Afgelopen week heb ik het een 3 tal dagen bekeken. Dan klopte de 22u einde dag elke keer.

[Fluppeke]

Langer blijven surfen aan hogere snelheid omdat de meter achterloopt, en dan nog ontevreden . Rare mensen toch:p

Ge kunt altijd overstappen als ge liever regenboogkleurkes hebt enzo ... Daar in mechelen dan zit je bij de early adopters van de meters ..Phillipe_D heeft zelfs (onbewust?) hun marketingterm gebruikt voor de scarlet gebruiksmeter.."telemeter".

[Pleuris]

Het is maar hoe jij het ziet.

Als ik bij het begin van een nieuwe maand nog een hoop van de maand daarvoor "aangerekend" krijg dan ben ik daar niet zo blij mee. Daarom dat ik me af vroeg wanneer de dag en maand juist stopt.

[nickz]

Voor die paar uur... Daar kan je nu wel rekening mee houden he. Voor een operator is het sowieso niet wenselijk dat klanten op het einde van de maand plots massaal beginnen downloaden omdat ze 'nog data overhebben'. Langs de andere kant zouden ze dat gemakkelijk kunnen voorkomen als ze willen, door met een 'schuivende meter' te werken, waarbij steeds rekening wordt gehouden met het verbruik van de laatste 30 dagen. Als jij dan op één dag tijd 200 GB zou downloaden, dan zou het sowieso 30 dagen duren voordat dat verbruik niet meer meegerekend wordt, ongeacht de tijd van de maand.

[MClaeys]

De beste manier voor hen om dat massaal downloaden aan het eind van de maand te voorkomen is zonder limiet werken, dan kan een klant ook niet downloaden om deze nog te bereiken

[Pleuris]

Voor een operator is het sowieso niet wenselijk dat klanten op het einde van de maand plots massaal beginnen downloaden omdat ze 'nog data overhebben'. Langs de andere kant zouden ze dat gemakkelijk kunnen voorkomen als ze willen, door met een 'schuivende meter' te werken, waarbij steeds rekening wordt gehouden met het verbruik van de laatste 30 dagen. Als jij dan op één dag tijd 200 GB zou downloaden, dan zou het sowieso 30 dagen duren voordat dat verbruik niet meer meegerekend wordt, ongeacht de tijd van de maand.

Dat is ook de reden waarom niet alle klanten de eerste dag van de maand aan "hun" maand beginnen. Lang geleden toen ik nog voor een "gele" provider werkte die net hun datalimiet had ingevoerd bij elke klant in het begin van de maand merkte ze op het einde van de maand een heel duidelijke toename van het dataverbruik. Als je betaalt voor een hoeveelheid data (hoewel limietloos natuurlijk beter is) dus heeft de klant ook"het recht" om die data op te gebruiken.

Het idee van een schuivende meter daar ben ik een zeer grote tegenstander van, hoop dat je ze niet op ideeën brengt

[philippe_d]

Afgelopen week heb ik het een 3 tal dagen bekeken. Dan klopte de 22u einde dag elke keer.

Het zou kunnen zijn dat Scarlet het verbruik van de klanten om de 4 uur meet/bijhoudt. Deze metingen beginnen waarschijnlijk bij iedere PPPoE sessie (van 36 uur), dus zolang je uw sessie niet verbreekt zal dat tijdstip van de meting(en) iedere dag op hetzelfde uur gebeuren (vb 02:00, 06:00, 10:00, 14:00, 18:00, 22:00 enz ...).

• - Vandaar dat zij zeggen dat er maximaal 4 uur verschil zit, tussen reëel verbruik en gemeten verbruik.
  - Vandaar dat "jouw dag" telkens om 22.00 eindigt?

Voor een andere klant, waarvan de PPPoE sessie om 3:00 onderbroken werd, zal "zijn dag" om 23:00 eindigen?

Als ik bij het begin van een nieuwe maand nog een hoop van de maand daarvoor "aangerekend" krijg dan ben ik daar niet zo blij mee. Daarom dat ik me af vroeg wanneer de dag en maand juist stopt.

Misschien komt de maand overeen met de facturatiecyclus? Wat ook niet noodzakelijk voor alle klanten op dezelfde dag is?

Allemaal een beetje speculatie. Laat ons de officiële communicatie afwachten ...

[jantje81]

Op dit moment komt de reset van de verbruiksmeter bij mij in elk geval overeen met de facturatiedatum.