WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] (Possible) Inaccurate accounting in Xen's bandwidth control

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] (Possible) Inaccurate accounting in Xen's bandwidth control
From: Luwei Cheng <chengluwei@xxxxxxxxx>
Date: Sat, 12 Mar 2011 15:59:01 +0800
Delivery-date: Sat, 12 Mar 2011 07:23:08 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=mA5HzMqtGPKcteB3TBdZvZ7fIqZOh8zI/KuineCFDac=; b=V4FXEiAFykLf6u568IZ8l35t/A58mcRJ4CMYmSLXuLtBcLxmTv9bbCOzO3E1IajDGT 1zTIL+eCbbjr3qGPuK83hgCbLQJ+iZx6UiOwUp7+7gQrQOSBZK0VE2sT4PnZc2aQ3t1c Wg3Puh/uEH5l4PUSJBkEW4vgDWSX6NcHkBmBo=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=pod5zhnvCvNdWXgTpBiunFoWKHWj3iSDbODvtnj/zXVTmmaKyxbLGags4JqG/jemYj P8DIyKbntEPEIJ9K/YWShhi+TAyCslOtJ7XpenoRbIneVOoDPMvay7MLdxGJuq97sQVF fk5BbktZGvoee4XaxTFc+GiJihbZzNNdji08Y=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
----
Department of Computer Science
The University of Hong Kong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>