[gPXE-devel] [Etherboot-developers] [PATCH] forcedeth driver - very bad transfer rate / missing register update

[Marty Connor]

Nice work, Yann!  Thanks for contributing this patch.
We will apply it to gPXE.

/ Marty /

On 3/20/11 8:06 AM, Yann Cézard wrote:
> Hi (g/i)pxe developpers,
>
> Playing recently with a new toy with an MCP79 chipset (0x10DE, 0x0AB0) 
> in it and iSCSI, I found that the transfer rate were anormaly slow 
> (about 15 seconds to load about 15MB of kernel + initrd, on a Gb 
> network) in the (g/i)pxe phase, transfer rate were then OK (~50MB/s) 
> after the linux code has taken the control.
> After having test with TFTP and HTTP tranfer, I found that the problem 
> was the same, so it had to be in the forcedeth driver.
>
> Enabling debugging mode show me that the driver didn't stop calling
> forcedeth_link_status and as a consequence nv_update_linkspeed when 
> polling (and each time it just found that there is no link change, so 
> it was just a big waste of time).
> Same problem with gpxe and ipxe.
>
> After having a look at the linux forcedeth driver, I found that the 
> (g/i)pxe forcedeth driver code was missing a NVREG_MIISTAT_LINKCHANGE 
> register update, which made the poll method thinking that a link 
> change as occured every time it was called.
> Updating this register and testing it in forcedeth_link_status just 
> did the trick !
>
> Here are some tests that I have done :
> ####################################
> Embedded scripts used to test perfs :
> ===========
> #!gpxe
> dhcp net0
> time imgfetch http://192.168.1.10/some.iso
> ===========
> or :
> ===========
> #!ipxe
> dhcp net0
> time imgfetch http://192.168.1.10/some.iso
> ===========
>
> The image size (in bytes) is :
> 434065408 some.iso
>
> In every case :
> - 1st and 2nd run are done "the classic way"
> - 3rd run is done with an unplug/replug of the cable to test reconnection
>
> <--------  GPXE  ---------->
> Test1 : gpxe / no fix
> ======================
> 1st run : 253s / 1.64 MB/s
> 2nd run : 252s / 1.64 MB/s
> 3rd run : 260s - reconnection OK
>
> Test2 : gpxe / fix
> ===================
> 1st run : 13s / 31.84 MB/s
> 2nd run : 14s / 29.57 MB/s
> 3rd run : 18s - reconnection OK
>
> <--------  IPXE  ---------->
> Test3 : ipxe / no fix
> ======================
> 1st run : 250s / 1.66 MB/s
> 2nd run : 251s / 1.65 MB/s
> 3rd run : 257s - reconnection OK
>
> Test4 : ipxe / fix
> ===================
> 1st run : 10s / 41.40 MB/s
> 2nd run : 10s / 41.40 MB/s
> 3rd run : 17s - reconnection OK
> ####################################
>
> I am not a network driver hacker, nor a C hacker at all, so perhaps 
> the code is not at the better possible place, but you got the idea ;)
> Looking at how it is done in the linux kernel driver code, I don't 
> think that this will break other chipsets support.
>
> If you need further tests, just ask.
>
> Cheers,
>
> Yann
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
>
>
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://etherboot.org/pipermail/gpxe-devel/attachments/20110325/0f6c6c57/attachment.html>