[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] Re: (Possible) Inaccurate accounting in Xen's bandwidth control


  • To: xen-api@xxxxxxxxxxxxxxxxxxx
  • From: Luwei Cheng <chengluwei@xxxxxxxxx>
  • Date: Sat, 12 Mar 2011 16:00:17 +0800
  • Delivery-date: Sat, 12 Mar 2011 00:01:11 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=U1j7e9GqJDG53whIXEHIr/qnnk8W14cNDQ0v0SciJK/m7I8gH9lfZ6dFIqukl9FWH1 mwTpB/dYGIXJtFfMWOCVw2Ch4H0P1zye5GliRVzHYWIvCdmoUpCw7QiVuryGvt6Kw5pZ Pxxbj+H5+K90yydvNbihFKCliyy3vCzYQqZa4=
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>

BTW, I have forwarded the email to xen-devel@xxxxxxxxxxxxxxxxxxx.
Sorry for the trouble caused if the email should not be sent to "xen-api" maillist:-)

Best Regards,
Luwei Cheng

On Sat, Mar 12, 2011 at 3:47 PM, Luwei Cheng <chengluwei@xxxxxxxxx> wrote:
Hi,

These days I use netperf to evaluate Xen's network bandwidth control.
I found that somehow the bandwidth is always inaccurate (slightly less than the promised bandwidth) 

After reading the source code of Linux-2.6.3** (domain 0), I am a bit curious about the following algorithm.
file: /linux-main-dir/drivers/xen/netback/netback.c
=============================================================
static void tx_add_credit(netif_t *netif)
{
        unsigned long max_burst, max_credit;

        /*
         * Allow a burst big enough to transmit a jumbo packet of up to 128kB.
         * Otherwise the interface can seize up due to insufficient credit.
         */
        max_burst = RING_GET_REQUEST(&netif->tx, netif->tx.req_cons)->size;
        max_burst = min(max_burst, 131072UL);
        max_burst = max(max_burst, netif->credit_bytes);

        /* Take care that adding a new chunk of credit doesn't wrap to zero. */
        max_credit = netif->remaining_credit + netif->credit_bytes;
        if (max_credit < netif->remaining_credit)
                max_credit = ULONG_MAX; /* wrapped: clamp to ULONG_MAX */

        netif->remaining_credit = min(max_credit, max_burst);
}
=============================================================


Setting: rate=512Kb/s@30ms, Then,
-----------------------
"netif->credit_bytes" will be 1,920
"netif->credit_usecs" will be 30,000
=============================================================
Suppose that at some moment:
-----------------------
"request size" is 1514
"netif->remaining_credit" is 406
-----------------------
Since there's not enough credits for transmitting, the netif
will be delayed for 30,000 usecs to refill credits (using timer).
=============================================================
Question:
After the timer wakes up, should the netif get (406+1920) credits, or (1920) credits?  
=============================================================
In my mind, I think it should be fair to let the netif get (406+1920) credits.
However, the above algorithm will eventually give only (1920) credits.

Just wonder whether there's some undocumented consideration to control in this way
(only give 1920 credits)?

Kindly please correct me if my analysis is incorrect.

Thanks for your attention.

Best Regards,
Luwei Cheng

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.