Re: InBPS rate statistics wrong? (for fwmark service)

To: " users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: InBPS rate statistics wrong? (for fwmark service)
From: Roberto Nibali <ratz@xxxxxxxxxxxx>
Date: Tue, 21 Feb 2006 11:00:08 +0100

Ok, this should not be a problem.

iptables -t mangle -xnvL has shown a constant of 103 packets having hit
the rule for hours... Yet ipvsadm -L -f 10 --rate shows:

Prot LocalAddress:Port     CPS    InPPS   OutPPS    InBPS   OutBPS
  -> RemoteAddress:Port
FWM  10                      0        3        0      182        0
  -> cns3:domain             0        0        0       30        0
  -> cns2:domain             0        0        0        0        0
  -> cns1:domain             0        1        0       53        0
  -> cns0:domain             0        2        0       98        0

If no packets have been marked for hours how can this be?
Could you zero the stats counters and wait again for a while? For now I
don't know what would cause this.

At the time of my origional post the fwmark based service was not the only
service. There were also udp/tcp services that could matched the same
traffic. (Is it defined which service has precedence in that case?)

Aehm ........................................ brain starvation .............. I honestly don't know. I would assume the first entered service gets the packets since it's first in the linked list. However cache coherence issues could garble the order of the list on SMP for example; this is highly speculative. Also the counters are not list-aware, so this could explain it. If you're interested, you could re-run the test and we could document that case.

After a complete and succesfull test with the fwmark based service I
removed the old services. (Which was the intent of this excersize;
replacing 9vips x 2(tcp/udp) services with 1 fwmark based one.)

I understand.

And ever since the tcp/udp based services the rate seems to be acurrate
again. Could there be some interferance, things accounted in the wrong
place, or something?


I no longer have the setup to reproduce right now but
if someone suspects the might realy be a BUG()

:) Not that bad I hope.

I could run some more
test... ? I think, even though it might be undefined if a marked packet
matches a fwmark service or an appropriate tcp/udp based service if also
present, it does seem weird that the rate did not go down to zero when NO
packets where beeing marked....

Clueless so far. We have never tested this.

Roberto Nibali, ratz
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

<Prev in Thread] Current Thread [Next in Thread>