/proc/net/dev bytes teller loopt uit int.

[PanMan]

Hoi!
Ik heb op mijn 1 floppy linux router coyote linux, http://www.coyotelinux.com/ . Nu heb ik, met enige hulp, thnx Steyn:), een script geschreven dat /proc/net/dev uitleest en deze gegevens doorstuurt naar een andere computer die ze in een database stopt en er een mooi MRTG ding van maakt. Nu het probleem: wat ik uitlees is het aantal getransferde bytes. Dus 2 getallen, up en down.
Nu het echte probleem: Regelmatig worden deze counters gereset. En zeeeer waarschijnlijk komt dit doordat ze te groot worden. Een int is op de meeste systemen 32 bit, 2^32 is 4294967296, dus kan ik dan 'maar'4 Gb traffic hebben. Meer traffic is geen probleem, maar dan wordt die counter gereset. Nu dus mijn vraag: Wat kan ik hier aan doen? Is er een of andere marnier om ervoor te zorgen dat die teller b.v. een 64 bits getal wordt? Of b.v. in Kbytes telt? Ik zou ook een script kunnen maken dat steeds kijkt of de huidige waarde kleiner is dan de vorige, en if so, het vorige erbij optelt (zo detect je die resets), maar dan moet ik telkens een hele log parsen terwijl ik graag gewoon het total traffic direct heb.
Iemand een oplossing? Ik ben benieuwd.

[Apache]

je kan je eigen systeem gebruiken met de detectie van de reset , en dan een extra variable bijhouden met hoeveel x hij al gereset is en die x de maximum waarde van /proc/net/dev

dus als hij al 2x reset is krijg je 8 gig + huidige waarde ... je zult het zoiezo ergens moeten opslaan en zo kan je een vrij kleine size behouden.

[deadinspace]

Het is trouwens mogelijk dat het een signed int is, en een 32bit signed int gaat van -2 miljard tot +2 miljard, dus het maximum voor een reset zou dan 2 GB zijn, niet 4 GB.

[blaataaps]

Als het een signed int is, zou ik dat vrij dom vinden eigenlijk, ik heb nog nooit negatief traffic gehad : )

[dinges]

ga gewoon een beetje kernel hacken ofzo
nm
het is coyote

[odysseus]

Ik heb niet kunnen vinden of het een signed int of een unsigned int is, maar volgens mij kun je het ook eenvoudiger oplossen door niet de output van /proc/net/dev te gaan parsen, maar die van ifconfig. Voor zover ik uit de manpage daarvan kan opmaken heeft ifconfig geen moeite met traffic van meer dan 4GB, dus dan hoef je helemaal geen counter meer bij te houden. Ifconfig geeft bovendien RX en TX in zowel bytes als SI-units, dus zelfs omrekenen voor als je nettere output zou willen is niet nodig. En eventueel kun je natuurlijk ook ipac gebruiken, volgens mij telt die onafhankelijk van /proc-entries.

* odysseus vraagt zich wel af hoe ifconfig kan bijhouden hoe vaak die teller al is gereset, hij kan daar helemaal niet bij zolang je ifconfig niet draait...weird.

[overigens ben ik er vrij vast van overtuigd dat het een unsigned int is: je zou anders wel vreemde effecten krijgen als hij over de 2GB gaat: dan is je traffic niet nul, maar -2GB ]

[deadinspace]

Op zondag 13 januari 2002 20:00 schreef odysseus het volgende:
[overigens ben ik er vrij vast van overtuigd dat het een unsigned int is: je zou anders wel vreemde effecten krijgen als hij over de 2GB gaat: dan is je traffic niet nul, maar -2GB ]

Nee, dan zou de kernel hem zelf wel resetten naar 0 (hoop ik dan toch).
Vergeet niet dat unsigned getallen maar erg weinig gebruikt worden. PIDs en FDs zijn *ook* signed.

[PanMan]

jah, die ifconfig zou een goede oplossing zijn, ware het niet dat de ifconfig versie die in die coyote zit geen bytes weergeeft, alleen packets. Nieuwere ifconfigs geven inderdaad wel bytes.
Om zoiets te upgraden moet je een hele nieuwe kernel maken, toch?
(ik weet niet heel erg veel van linux. Ik kan er mee uit de voeten, maar gebruik niet voor niets een standaard disk )

[odysseus]

Op zondag 13 januari 2002 20:22 schreef deadinspace het volgende:

[..]

Nee, dan zou de kernel hem zelf wel resetten naar 0 (hoop ik dan toch).
Vergeet niet dat unsigned getallen maar erg weinig gebruikt worden. PIDs en FDs zijn *ook* signed.

Hmm, en die kernel maar wachten tot dat ding aan zijn maximum zit en dan op nul zetten? Waarom dan niet een unsigned int die zichzelf op nul zet, dat is toch veel eenvoudiger en efficienter? Overigens heb ik het idee dat PID's ook unsigned zijn:

code:

odysseus:/win/kernel_drivers# grep -ri pid fs/proc/* | grep int | grep signed
fs/proc/base.c: unsigned int fd, pid, ino;
fs/proc/base.c: unsigned int pid, c;
fs/proc/base.c:static int get_pid_list(int index, unsigned int *pids)
fs/proc/base.c: unsigned int pid_array[PROC_MAXPIDS];
fs/proc/base.c: unsigned int nr_pids, i;
odysseus:/win/kernel_drivers# setterm -file /termdump -dump

Ik heb ook geen idee waarom dat soort vars signed zouden moeten zijn, maar ik kan dan ook geen fatsoenlijk C-programma schrijven , ik moet die taal nog altijd eens leren...

[deadinspace]

Op zondag 13 januari 2002 20:38 schreef odysseus het volgende:
Overigens heb ik het idee dat PID's ook unsigned zijn:

code:

odysseus:/win/kernel_drivers# grep -ri pid fs/proc/* | grep int | grep signed
fs/proc/base.c: unsigned int fd, pid, ino;
fs/proc/base.c: unsigned int pid, c;
fs/proc/base.c:static int get_pid_list(int index, unsigned int *pids)
fs/proc/base.c: unsigned int pid_array[PROC_MAXPIDS];
fs/proc/base.c: unsigned int nr_pids, i;
odysseus:/win/kernel_drivers# setterm -file /termdump -dump

code:

[marcelm@nothing include]$ grep -r pid_t * 2> /dev/null | grep typedef | grep int | grep -v ipc
asm/posix_types.h:typedef int        __kernel_pid_t;
bits/types.h:typedef int __pid_t;                /* Type of process identifications.  */
glib-1.2/glib.h:typedef int pid_t;

Vreemd. Dan zouden ze in de kernel een ander type voor PIDs handhaven dan in userspace processes? Lijkt me nogal inefficient...

Ik heb ook geen idee waarom dat soort vars signed zouden moeten zijn, maar ik kan dan ook geen fatsoenlijk C-programma schrijven , ik moet die taal nog altijd eens leren...

Een goede reden is dat functies dan ook negatieve waarden kunnen returnen voor bijvoorbeeld PIDs en FDs. Dit wordt vaak gebruikt om een error aan te duiden.

[jeroen|IA]

Bij mij roteert de output van ifconfig na ook 4GB (2.4 kernel). en dat kan ook goed kloppen, want als we ifconfig stracen zien we o.a. de volgende regel:

code:

open("/proc/net/dev", O_RDONLY)    = 9

"Even" een int die in de kernel zit omturnen naar een 64bits waarde kan ook niet. Al was het maar omdat een heleboel programma's (zoals ifconfig) geen rekening houden met een int die groter is dan 32bits. De enige echte oplossing is dus (zoals al gezegd) de waarde op gezette tijden uitlezen, en in een andere variabele parkeren die van willekeurige lengte kan zijn. Enige probleem is dan inderdaad om bij te houden of de teller ondertussen gereset is, maar dat is dus vrij simpel na te gaan door te kijken of de nieuwe waarde lager is dan de vorige.

[Kees]

4G is inderdaad de limiet van /proc/net/dev.
Maar dat is toch geen probleem?
ik bedoel; nu heb je eens in de zoveel dagen dat voor ong 5 minuten het aantal getransferde bytes niet klopt, mrtg pikt dat prima op

Het omzetten naar een 64bits getal zou ik niet weten hoe dat gaat zou er iig niet aan beginnen

Maar als je je "totale" trafic wilt weten, maak dan een scriptje die in mysql/een file de laatste waarde bijhoud en dan ongeveer zo rekent:
IF (laatste waarde > huidige waarde) totale waarde += (4G-laatse waarde) + huidige waarde
ELSE totale waarde += huidige waarde - laatste waarde.

moet makkelijk te doen zijn

[igmar]

[
Vreemd. Dan zouden ze in de kernel een ander type voor PIDs handhaven dan in userspace processes? Lijkt me nogal inefficient...

De reden waarom PID signed is : -1 is een error.

[odysseus]

Op maandag 14 januari 2002 13:12 schreef igmar het volgende:
De reden waarom PID signed is : -1 is een error.

Maar met een unsigned int zou je toch kunnen afspreken dat 0 een error is? Of anders NULL, omdat 0 vaak als getal wordt gebruikt voor een succesvolle return...

* odysseus neemt tenminste aan dat een unsigned int op 0 begint - zoals gezegd is mijn kennis van C vrij minimaal te noemen

[Oezie Woezie]

Waarom doe je het op z'n manier, als je het toch met MRTG doet kan je het misschien beter gelijk met SNMP doen.

interfaces.ifTable.ifEntry.ifInOctets.1 = Counter32: 1768730
interfaces.ifTable.ifEntry.ifInOctets.2 = Counter32: 4292256868
interfaces.ifTable.ifEntry.ifOutOctets.1 = Counter32: 1768730
interfaces.ifTable.ifEntry.ifOutOctets.2 = Counter32: 1668433561

[Verwijderd]

Op maandag 14 januari 2002 15:29 schreef odysseus het volgende:

[..]

Maar met een unsigned int zou je toch kunnen afspreken dat 0 een error is? Of anders NULL, omdat 0 vaak als getal wordt gebruikt voor een succesvolle return...

Zoals al vermeld: -1 = error

Ook snap ik niet waarom je een unsigned int nodig zou hebben voor pid's? Lijkt me sterk dat iemand meer dan 2 miljoen processes draaiend heeft op zijn computertje

INT_MAX : 2147483647 (Linux 2.4, GCC 2.95, zie limits.h)

[deadinspace]

Op maandag 14 januari 2002 13:12 schreef igmar het volgende:
De reden waarom PID signed is : -1 is een error.

Lees dan aub mijn hele post...

Op maandag 14 januari 2002 15:29 schreef odysseus het volgende:
Maar met een unsigned int zou je toch kunnen afspreken dat 0 een error is? Of anders NULL, omdat 0 vaak als getal wordt gebruikt voor een succesvolle return...

NULL is 0. (je mag er niet vanuit gaan dat die gelijk zijn nee, maar in de praktijk zijn ze dat ongeveer 100% van de gevallen).

* odysseus neemt tenminste aan dat een unsigned int op 0 begint - zoals gezegd is mijn kennis van C vrij minimaal te noemen

Ja zeg... int is int hoor, integers werken in elke taal op dezelfde manier

Op maandag 14 januari 2002 16:21 schreef cr33p het volgende:
Ook snap ik niet waarom je een unsigned int nodig zou hebben voor pid's? Lijkt me sterk dat iemand meer dan 2 miljoen processes draaiend heeft op zijn computertje
INT_MAX : 2147483647 (Linux 2.4, GCC 2.95, zie limits.h)

True. Merk op dat int niet op alle OSsen/platformen 32 bits zijn.

[odysseus]

Op maandag 14 januari 2002 17:07 schreef deadinspace het volgende:
NULL is 0. (je mag er niet vanuit gaan dat die gelijk zijn nee, maar in de praktijk zijn ze dat ongeveer 100% van de gevallen).

Hmm, ik kan me vergissen hoor, maar of je nu een pointer naar een var hebt die 0 is of een pointer naar een die NULL is, dat is toch wel een verschil? But then, ik heb er geen ervaring mee .

Ja zeg... int is int hoor, integers werken in elke taal op dezelfde manier
[..]

Hmm, en perl dan? Die heeft alleen intern dergelijke datatypen, voor de programmeur is het gewoon 'my $var = waarde', waarbij waarde zowel een string als een int of een short of een boolean kan zijn...en perl is zeker een echte taal .

[deadinspace]

Op maandag 14 januari 2002 17:20 schreef odysseus het volgende:
Hmm, ik kan me vergissen hoor, maar of je nu een pointer naar een var hebt die 0 is of een pointer naar een die NULL is, dat is toch wel een verschil? But then, ik heb er geen ervaring mee .

Een pointer met waarde NULL is een ongeldige pointer.
In de praktijk geldt: NULL = 0, dus een pointer dat naar geheugenadres 0 wijst (aka de eerste byte van je ram) is ongeldig.

Dus het gebruik van NULL zou je niet helpen in die PID-situatie.
Het gebruik van NULL zou je sowieso niet helpen, omdat NULL van het type pointer is en een PID van het type pid_t trouwens.
Wat jij ergens anders voorstelde: PID 0 is ongeldig (en indiceert dus een error), alle andere waarden zijn wel geldig (en dan een unsigned int nemen) is wel te realiseren.
Maar zoals iemand anders al opmerkte: meer dan 2 miljard processes heb je toch niet nodig op jouw PC.
Sterker nog: je PC /kan/ dat absoluut met geen mogelijkheid.

Computers die wel meer dan 2 miljard processes aan zouden kunnen zouden dan een pid_t van 64 bits nodig hebben, en dat is op zo'n apparaat waarschijnlijk wel het geval.

Hmm, en perl dan? Die heeft alleen intern dergelijke datatypen, voor de programmeur is het gewoon 'my $var = waarde', waarbij waarde zowel een string als een int of een short of een boolean kan zijn...en perl is zeker een echte taal .

Mja, dus hanteert perl naar de programmeur toe geen ints.

Maar integers omvatten doorgaans een gehele getallen range van x tot y, waarbij x =< 0 < y, in welke taal je ook werkt. Dat bedoelde ik.

[jeroen|IA]

Op maandag 14 januari 2002 15:56 schreef Oezie Woezie het volgende:

Waarom doe je het op z'n manier, als je het toch met MRTG doet kan je het misschien beter gelijk met SNMP doen.



interfaces.ifTable.ifEntry.ifInOctets.1 = Counter32: 1768730

interfaces.ifTable.ifEntry.ifInOctets.2 = Counter32: 4292256868

interfaces.ifTable.ifEntry.ifOutOctets.1 = Counter32: 1768730

interfaces.ifTable.ifEntry.ifOutOctets.2 = Counter32: 1668433561

Ook de waarden die je via snmp terug krijgt zullen een keer roteren; dat kun je zien aan de "Counter32" die ervoor staat. Zijn dus ook gewoon ints van max ~4GB. De waarde van interfaces.ifTable.ifEntry.ifInOctets.2 zit daar zelfs al vrij dichtbij, nog maar 2710428 bytes te gaan

[Verwijderd]

Op maandag 14 januari 2002 17:07 schreef deadinspace het volgende:
Ja zeg... int is int hoor, integers werken in elke taal op dezelfde manier
[..]

neuh een int is zelfs niet altijd 32 bits

[deadinspace]

Op dinsdag 15 januari 2002 00:01 schreef trifling het volgende:
neuh een int is zelfs niet altijd 32 bits

So? Heeft dat iets met het principe van een int te maken? Ik schreef ook al, om mijzelf te verduidelijken:

Op maandag 14 januari 2002 18:59 schreef deadinspace het volgende:
Maar integers omvatten doorgaans een gehele getallen range van x tot y, waarbij x =< 0 < y, in welke taal je ook werkt. Dat bedoelde ik.

Verder schreef ik ergens:

Op maandag 14 januari 2002 17:07 schreef deadinspace het volgende:
Merk op dat int niet op alle OSsen/platformen 32 bits zijn.

[Verwijderd]

Op dinsdag 15 januari 2002 00:26 schreef deadinspace het volgende:

[..]

So? Heeft dat iets met het principe van een int te maken? Ik schreef ook al, om mijzelf te verduidelijken:
[..]

Verder schreef ik ergens:
[..]

jij hebt gelijk als je zegt dat ik met mijn slechte oog gelezen heb

maar ik heb gelijk dat je niet te snel moet roepen dat "een int een int is"

kost je drie offtopic post om jezelf te verduidelijken

[deadinspace]

Op dinsdag 15 januari 2002 06:47 schreef trifling het volgende:
maar ik heb gelijk dat je niet te snel moet roepen dat "een int een int is"

kost je drie offtopic post om jezelf te verduidelijken

Hehe, point taken...