bug-hurd
[Top][All Lists]
Advanced

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

benchmarking of user-level pcnet32 driver


From: Da Zheng
Subject: benchmarking of user-level pcnet32 driver
Date: Fri, 13 Nov 2009 10:57:06 +0800
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)

Hello,

I finished porting pcnet32 driver from Mach to the user space and here is the 
brief report of performance measurement.
It was just a rough performance measurement. The Hurd runs in a VMWare virtual 
machine and it only receives data. The data sender is in the host machine, 
which runs Mac OS X. The processor of my machine is 2.4 GHz Intel Core 2 Duo. 
Of course, I am aware that the data sender shouldn't run on the same physical 
machine as the Hurd and that it's better to test it when the Hurd runs in a 
physical machine. But the purpose of the experiment is to prove that the 
user-level driver still has fairly good performance compared with the in-kernel 
driver, instead of measuring its performance accurately.

I measured its performance using TCP and UDP packets. There are 2 experiments 
and each one runs 3 times. All data shown below is average values. I compare 
its performance with the in-kernel pcnet32 driver.
Experiment 1: sending 100MB data from the host machine to the Hurd with TCP. I 
only calculate data transferring rate (i.e., excluding the size of packet 
headers).
                in-kernel                       user-level
average rate:   2.3MB/s                         2.4MB/s
peak rate:      3.9MB/s                         2.6MB/s

Experiment 2: sending 1,000,000 UDP packets of minimum size (60 bytes including 
packet headers) within 30 seconds
                        in-kernel               user-level
nb of received packets: 46,959                  68,174

As we see, both have quite bad performance in Experiment 2, but the result is 
still really unexpected. But I think it can be explain as follows:
The in-kernel driver puts received packets in a queue so the software interrupt 
can handle it and deliver it to the user space. But if the queue is full, 
received packets are simply dropped. In the case that a large number of packets 
rush to the Ethernet card in a very short time, most of CPU time is used by the 
interrupt handler to get the packet from the card but the interrupt handler 
fails to put packets in the queue for further delivery. As a result, most of 
CPU is wasted.
My user-level driver doesn't put received packets in the queue, but instead it 
calls mach_msg() to deliver messages to pfinet directly. It's true that the 
user-level interrupt handler fails to get all packets from the card and most 
packets are discarded by the card directly. But as long as a packet is received 
by the driver, it's very likely that the packet will be delivered to pfinet. 
Thus, CPU isn't much wasted (I have another implementation that the user-level 
driver puts received packets in a queue first before delivering them to pfinet 
and the implementation has extremely bad performance in the case that lots of 
packets rush in).

Anyway, the informal benchmarking shows us that the user-level pcnet32 driver 
does have relatively good performance compared with the in-kernel driver.

Best regards,
Zheng Da




reply via email to

[Prev in Thread] Current Thread [Next in Thread]