Viteza aia e rata de transfer intr-un anumit interval
(biti_traficati/secunda). Cu cit intervalul ales e mai mic cu atit poti
sustine mai cu tarie ca aia e o rata instantanee de transfer. In viata
reala insa nu putem lucra cu instantanee super instantanee, drept urmare
mergem pe ideea mediilor pe intervale.
vezi de ce sunt bune transmisiile sincrone de date?
de timp. dar eu nu sunt convins ca functia F (care o implementezi cu un
snmpget pe modem de cablu sau cu o comanda pe cmts sau pe shaper) imi va
intoarce o valoare reala, mai ales ca pot sa prind apeluri de F ce prinde
transmisia la mijlocul pachetului.
Pentru un numar suficient de mare de intervale abarerea aia va tinde
ideal spre 0, ea fiind cind negativa cind pozitiva. Ma rog, la
s/tinde/cu altceva/
"altceva", eventual ca din definita aritmetica a probabilitatii
treaba asta cu snmpget pe care voia s-o faca cel ce a lansat threadul e
posibil sa obtina numai un anume tip de abateri (doar pozitive) pentru ca
el desi a setat intervalul la o secunda nu s-a chinuit niciodata, sau cel
putin nu initial, sa vada cit e el de fapt real (latenta retelei si timpul
de executie al lui snmpget jucind un rol important aici, pentru ca
intervalul e mic).
si in plus, care e momentul evaluarii timestamp-ului relativ la apelul de
snmpget. adica ce ziceam eu de functia F
ps: inca nu am beut berea si nici nu m-am uitat pe gugle cu privire la
subiect.
Nu te mai uita, considera-l inchis, sau macar pina vineri (adica miine).
ciuciu, am inceput-o de 1 sfert de ora :D
t.
_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug
