MAX6DYN teller

[xming]

Hebben hier ook mensen gemerkt dat de EDP teller meer telt? Telt die soms de ATM traffiek ipv IP traffiek?

van myedp

Code: Selecteer alles

Download  	 265 MB
Upload 	98 MB
Totaal 	363 MB
Toegestaan 	61440 MB
Verbruikte trafiek 	0%

Effectief IP traffiek

Code: Selecteer alles

ppp0      Link encap:Point-to-Point Protocol
          inet addr:213.x.y.z  P-t-P:213.a.b.c  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:563626 errors:0 dropped:0 overruns:0 frame:0
          TX packets:618731 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:272305468 (259.6 Mb)  TX bytes:91309302 (87.0 Mb)

[Phuncz]

Overhead ?

[xming]

Zeker geen IP overhead noch PPP, dus ATM overhead, das toch wel erg. Gebruiken ze RADIUS accounting met ATM switch ipv RADIUS + PPP sessions? hmm

[xming]

hehe,

Ticket aangemaakt en ik krijgt ook eerst en antwoord dat het over overhead gaat, tot dat ik zei dat de overhead (IP + PPP) inbegrepen was en vroeg of er geteld werd met de ATM trafieken. Als antwoord geven ze nee, ze tellen de IP trafieken maar als het over zo kleine verbruik kunnen ze geen conclusies trekken, euh.

Er is nog al nu al verschil van 17,7 % voor de upload en 2,88 voor de download.

Nog iemand die zoiets heft gemerkt?

[MRC101]

Nog iemand die zoiets heft gemerkt?

'k Heb soms ook de indruk dat de teller wat te veel telt, maar heb me nog niet bezig gehouden met testen over een lange tijd.

[xming]

'k Heb soms ook de indruk dat de teller wat te veel telt, maar heb me nog niet bezig gehouden met testen over een lange tijd.

Ik ben just klant geworden, dus het is wel gemakkelijk dat allemaal bij te houden, en aangezien dat ze geen forced discounts (meer) hebben, maakt het nog gemakkelijker.

Ik hou jullie wel op de hoogte

[xming]

Antwoord van hun helpdesk, dat ze geen conclusie kunnen trekken over "kleine hoevelheden" maar sorry accouting moet correct zijn, hoe kan het tellen van bytes verschillen van de hoeveelheden, volgens mij hopen ze gewoon dat er meer nachtsurfen erbij komt, dus het verschil niet meer te zien is.

Ok nu na 3 weken EDP en 10GB op de teller:

Download = 8385 MB
Upload = 2265 MB

14/07/2006 22,98 MB 3,61 MB
13/07/2006 83,66 MB 12,06 MB
12/07/2006 183,53 MB 17,66 MB

Dus tot 12/7 (ja ik trek hier wel te veel af)

Download = 8385 - 22.98 - 83.66 - 183.53 = 8094
Upload = 2265 - 3.61 - 12.06 - 17.66 = 2231.67

volgens mij (er was een disconnect geweest) zonder rekening te houden met het nachtsurfen:

Jul 12 14:06:57 spaceball pppd[25543]: Sent 2333799354 bytes, received 289999395 bytes.

Download = 289999395/1024/1024 + 8196 MB (2x overflow 32-bit counter) = 8468 MB
Upload = 2333799354/1024/1024 = 2225.68 MB

Zien jullie het? Ik tel geen nacht upload (dus geen - 50%) en ik trek wel 1/2 dag (12/7) meer traffiek af van hun stats, kom ik nog op 6 MB minder uit.

Conclusie: ze tellen niet aleen IP traffiek.

xming

[xming]

De volumes zijn heel waarschijnlijk incl. ATM traffiek. Dus voor elke byte die men download telt daar de TCP/IP of UDP/IP overhead + PPP overhead + ATM overhead bij je volume.

14/08/2006 15:39:39

Beste klant

Onze radiusaccounting werkt op basis van het effectieve aantal bits (dus inclusief de overhead) aan trafiek die u genereert op de Redback of Cisco 10000 waarmee u op het Broba II-adsl-netwerk aangesloten bent.

Dit verklaart waarom de trafiek die uw applicatie meet licht kan afwijken van wat u daadwerkelijk genereert op deze routers.

[UB_removed1963]

Toen ik pas Edpnet had heb ik dit probleem ook een keer aangehaald, maar mijn ticket werd helaas gesloten met de melding dat dit overhead zou zijn. tijd voor een fatsoenlijk antwoord van hun kant lijkt me.

[Dave]

Er klopt momenteel sowieso de ballen van hun teller, zie ook dit topic:
http://www.userbase.be/forum/viewtopic. ... highlight=

Tickets worden afgesloten met verwijzing naar:
http://www.edpnet.be/cms.aspx?S=Helpcen ... tus_Issues

Ik veronderstel dat wachten op beterschap de boodschap is ...
Het is mij ook wel een raadsel wat ze gaan aanrekenen

[ubremoved_2964]

Wat ook kan meespelen :

het window waarin JIJ meet en het window waar zij meten, is dat exact hetzelfde ?

Verschil lijkt idd overhead, maar op zulke kleine volumes is het idd een beetje zinloos - je blijft onder je limiet.

Stel dat je bvb 25GB DL gedaan hebt volgens je eigen meting en EDP claimed 27,5GB DL dan stelt zich een ander probleem gezien je dan onterecht bijbetaalt.

Vroeger gebruikte ik jarenlang ipac :

http://www.daneben.de/ipac.html

Dit pakketje meet de packets vrij correct onder linux, namelijk puur op layer 3. Ik heb mijn eigen statistieken dikwijls vergeleken met de stats van evonet (zij meten elke ppp sessie, en tellen per maand gewoon de som van de ppp sessies).

[xming]

Er zijn verschillende overhead, hun manier van tellen is altijd tussen mijn Linux teller (incl. IP en PPP overhead) en mijn modem (IP + PPP + ATM).

Ongeacht nacht tarief, dwz zelfs met 50% korting telt mijn Linux voor de upload < EDP teller < mijn modem.

Ik moest gewoon een duidelijk antwoord hebben, helaas dat heb ik nog niet gekregen. Eerst kreeg ik een (niet al te vriendelijke) antwoord van "we gebruiken Cisco 10000, u (als een klein gebruiker) denkt toch niet dat daar fouten zijn. Tot dat ik heb wees dat er meer fouten in de IOS en zeker bij Cisco 10000 (met verwijzing naar de Cisco site) specifiek met de accouting (ok alleen in cimbinatie met L2TP, dus niet voor ons).

Laaste antwoord is dat ze accouting doen op cisco (die as bas functioneert) en redback, maar daar kan men nog altijd radius accouting doen op PPP of op ATM.

Ik heb hier heel veel gelezen dat EDP goed was enz, daarom was ik overgeschakeld, maar momenteel heb ik met momenten heel trage snelheid heb, helpdesk zegt gewoon dat ik met een andere modem moest proberen terzijl de ticket werd afgesloten met de melding "info expected 4/07 - vp cap". Dan nog 2 uur down geweest, en nu nog heel onduidelijke antwoord of zo'n simpele vraag.

Ik ben ondertussen 2 maanden bij EDP, ik kan niet zeggen dat ik ontevreden ben, maar toch niet so "happy" zoals sommigen hier. Er is iets te veel fanboyism hier op UB.

--

http://wojia.be/

[xming]

Wat ook kan meespelen :

het window waarin JIJ meet en het window waar zij meten, is dat exact hetzelfde ?

't maakt niet uit, zelfs met -50% komt hun teller nog boven mijne

Verschil lijkt idd overhead, maar op zulke kleine volumes is het idd een beetje zinloos - je blijft onder je limiet.

Er zijn verschillende overhead, zinloos? Niet als ze meer dan 25% meer tellen dan wat ze beweren, tot nu toe geven ze nog niet echt toe dat ze ATM meetellen

Stel dat je bvb 25GB DL gedaan hebt volgens je eigen meting en EDP claimed 27,5GB DL dan stelt zich een ander probleem gezien je dan onterecht bijbetaalt.

Dat wil ik just vermijden, VOOR dat ik moet bijbetalen

Vroeger gebruikte ik jarenlang ipac :

http://www.daneben.de/ipac.html

Dit pakketje meet de packets vrij correct onder linux, namelijk puur op layer 3. Ik heb mijn eigen statistieken dikwijls vergeleken met de stats van evonet (zij meten elke ppp sessie, en tellen per maand gewoon de som van de ppp sessies).

EN? kijk gewoon in je logs, bij terminatie van elke pppd sessie is er totaal aantal bytes gelogd.[/quote]

[Mr.T]

Volgens mij tellen ze gewoon het atm verkeer. Dit is tenslotte ook de traffiek die verbruikt wordt op het laagste niveau.

Waar maken jullie je trouwens druk om? Als men zegt dat er 20GB traffiek inbegrepen is, en men telt steeds het volume ATM verkeer, dan weet je toch perfect hoeveel je kan downloaden? Je hebt pas recht op klagen als ze de meet methode gaan aanpassen.

[Phuncz]

Je hebt ook mensen die klagen dat hun 250GB schijf maar 235GB groot is enzo, terwijl praktisch iedereen weet dat dat gewoon zo is. GSM's met een standbytijd van 200u die nog niet eens 160u halen is ook niet abnormaal. En jij praat over loggen van ATM-trafiek, waar misschien 0,01% van Belgie ooit van heeft gehoord.

Om het samen te vatten: BOEIEUH !

[xming]

Je hebt ook mensen die klagen dat hun 250GB schijf maar 235GB groot is enzo, terwijl praktisch iedereen weet dat dat gewoon zo is. GSM's met een standbytijd van 200u die nog niet eens 160u halen is ook niet abnormaal. En jij praat over loggen van ATM-trafiek, waar misschien 0,01% van Belgie ooit van heeft gehoord.

Om het samen te vatten: BOEIEUH !

Om korrect te zijn dir schijven zijn 250GB ~=235 Gib, maar EDP beweert dat ze PPP traffiek tellen, zonder ATM, en dit is het geval niet.

En bij mij weten sit standby time wordt altijd aangegeven met "to x uren".

FYI WD heeft een rechtzaak verloren ivm GB en GiB

[xming]

Je hebt ook mensen die klagen dat hun 250GB schijf maar 235GB groot is enzo, terwijl praktisch iedereen weet dat dat gewoon zo is. GSM's met een standbytijd van 200u die nog niet eens 160u halen is ook niet abnormaal. En jij praat over loggen van ATM-trafiek, waar misschien 0,01% van Belgie ooit van heeft gehoord.

Om het samen te vatten: BOEIEUH !

Om korrect te zijn die schijven zijn 250GB ~=235 Gib, maar EDP beweert dat ze PPP traffiek tellen, zonder ATM, en dit is het geval niet.

En bij mij weten sit standby time wordt altijd aangegeven met "to x uren".

FYI WD heeft een rechtzaak verloren ivm GB en GiB