[vbox-dev] NAT/slirp low outbound speed from guest's to remote hosts

[Jakob Simon-Gaarde]

Hi

 

I was wondering if any vbox-developers would like to comment on this issue. Most importantly: is there going to be a fix at all?

 

Best regards

Jakob Simon-Gaarde, Mikro Værkstedet A/S

 

________________________________

Fra: vbox-dev-bounces at virtualbox.org [mailto:vbox-dev-bounces at virtualbox.org] På vegne af Jakob Simon-Gaarde
Sendt: 17. marts 2008 13:50
Til: vbox-dev at virtualbox.org
Emne: [vbox-dev] NAT/slirp low outbound speed from guest's to remote hosts

 

Regarding the low speed NAT problem I have been trying to fix on VirtualBox and based on some vbox developers information (that I should compare VirtualBox and qemu regarding slirp) I have spent some time this week-end compiling qemu in different versions testing it's performance:

1. the developers at qemu appearently did something between 0.8.0 and 0.8.1 (which is also menchoned in the ChangeLog: "slirp fixes (Ed Swierk et al.)") that boosted NAT performance to near LAN speeds in both directions. Unfortunately it seems like these fixes are already adopted into VirtualBox - so that didn't give me much to go on. It would therfore seem like the problem is located either in the alterations made in slirp by VirtualBox since then or in the way slirp is utilized.

2. Top speeds on qemu require kqemu enabled and RAM "enough" preallocated - on VirtualBox it makes no difference how much Base memory I give the virtual machine.

 

As you mayby recall I have already been trying to debug the problem - but with no luck. It has been diagnosed as a scheduling problem by the vbox developers I just can't understand why It isn't possible to up-prioritize the thread responsible for pushing packets to the host interface - also I would like to add to the record the hack I made where I opened a file for output and closed it again (se below) in DevPCNet.cpp (func: pcnetAsyncSendThread())which boosted the outbound speed approx 10x

 

The problem is at least related to Linux and Windows hosts, but I must admit I have done most testing on Windows as this is the target host system for my task.

 

PS. I have reported this as a "major" bug - but when I saw what other people regard as a major bug (network icon blinking when no interface is attached - really is that a major bug...) I realized that I should probably have registered it as "Critical" ;-)

 

 

The hack in DevPCNet.cpp:

 

static DECLCALLBACK(int) pcnetAsyncSendThread(PPDMDEVINS pDevIns, PPDMTHREAD pThread)

{

    PCNetState *pThis = PDMINS2DATA(pDevIns, PCNetState *);

 

    /*

     * We can enter this function in two states, initializing or resuming.

     *

     * The idea about the initializing bit is that we can do per-thread

     * initialization while the creator thread can still pick up errors.

     * At present, there is nothing to init, or at least nothing that

     * need initing in the thread.

     */

           if (pThread->enmState == PDMTHREADSTATE_INITIALIZING)

                      return VINF_SUCCESS;

 

    /*

     * Stay in the run-loop until we're supposed to leave the

     * running state. If something really bad happens, we'll

     * quit the loop while in the running state and return

     * an error status to PDM and let it terminate the thread.

     */

    while (pThread->enmState == PDMTHREADSTATE_RUNNING)

    {

        /*

         * Block until we've got something to send or is supposed

         * to leave the running state.

         */

        int rc = RTSemEventWait(pThis->hSendEventSem, RT_INDEFINITE_WAIT);

        AssertRCReturn(rc, rc);

        if (RT_UNLIKELY(pThread->enmState != PDMTHREADSTATE_RUNNING))

            break;

 

        /*

         * Perform async send. Mind that we might be requested to

         * suspended while waiting for the critical section.

         */

        rc = PDMCritSectEnter(&pThis->CritSect, VERR_SEM_BUSY);

        AssertReleaseRCReturn(rc, rc);

 

        if (pThread->enmState == PDMTHREADSTATE_RUNNING)

        {

unsigned int Start = clock();

            rc = pcnetAsyncTransmit(pThis);

unsigned int End = clock();

FILE * pFile;

pFile = fopen ("c:\\temp\\timing.txt","a+");

fprintf (pFile, "Elapapsed time: %d\n",End-Start);

fclose (pFile);

            AssertReleaseRC(rc);

        }

 

        PDMCritSectLeave(&pThis->CritSect);

    }

 

    /* The thread is being suspended or terminated. */

    return VINF_SUCCESS;

}

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20080402/7339ba90/attachment.html>