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

[Jakob Simon-Gaarde]

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/20080317/d7d08433/attachment.html>