New IT forum
27 June 2022, 06:52:00 pm *
Welcome, %1$s. Please login or register.

: GertDuino now in stock.
 
Pages: [1]

Author Topic: Slow download rate  (Read 3581 times)

sheevaplugger

  • Newbie
  • *
  • Posts: 3
Slow download rate
« on: 08 December 2013, 09:04:35 pm »

Hello,

I have a new mirabox with a fresh ARCHLINUXARM installation. I detected problems with the network interface. The upload from a pc to the mirabox is fine. But the download from mirabox to a pc is very slow.

Upload (from a pc to mirabox) ok: ~5-6 MBit/s

Download (from mirabox to pc) NOT OK: ~ 270 kBit/s

The same problem:
on eth0 and eth1.
with different lan cables.
with different protocolls (dlna, samba, tvheadend dvb video streaming).

Could it be a software problem or a hardware defect?

Best regards

David
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: Slow download rate
« Reply #1 on: 09 December 2013, 09:23:55 pm »

This can be a symptom of mixed interface modes\speeds, for example, one end using full duplex and the other using half.
Test by either forcing the interface modes of both to be identical (force both to half-duplex) or change the interconnecting switch\hub to one that only supports half-duplex.

If the above test works (proving the theory correct), you can experiment forcing higher transfer modes until you reach optimum.
Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

sheevaplugger

  • Newbie
  • *
  • Posts: 3
Re: Slow download rate
« Reply #2 on: 09 December 2013, 09:49:46 pm »

I found the bug; it should be fixed with kernel version 3.10.12.

My linux distro is: archlinuxarm

I had "linux-mvebu-mirabox 3.12.3-1" installed. But i find it strange that the package "linux-mvebu 3.12.3-1" is installed two. Is that right?

And when the kernel 3.10.12 fixes the problem, why kernel 3.12.3 shows the bug again?

commit 4c54b9db01842eb0f4eb54af6949b7606ea39e7a
Author: Thomas Petazzoni <[email protected]>
Date:   Wed Sep 4 16:21:18 2013 +0200

    net: mvneta: properly disable HW PHY polling and ensure adjust_link() works
   
    [ Upstream commit 714086029116b6b0a34e67ba1dd2f0d1cf26770c ]
   
    This commit fixes a long-standing bug that has been reported by many
    users: on some Armada 370 platforms, only the network interface that
    has been used in U-Boot to tftp the kernel works properly in
    Linux. The other network interfaces can see a 'link up', but are
    unable to transmit data. The reports were generally made on the Armada
    370-based Mirabox, but have also been given on the Armada 370-RD
    board.
   
    The network MAC in the Armada 370/XP (supported by the mvneta driver
    in Linux) has a functionality that allows it to continuously poll the
    PHY and directly update the MAC configuration accordingly (speed,
    duplex, etc.). The very first versions of the driver submitted for
    review were using this hardware mechanism, but due to this, the driver
    was not integrated with the kernel phylib. Following reviews, the
    driver was changed to use the phylib, and therefore a software based
    polling. In software based polling, Linux regularly talks to the PHY
    over the MDIO bus, and sees if the link status has changed. If it's
    the case then the adjust_link() callback of the driver is called to
    update the MAC configuration accordingly.
   
    However, it turns out that the adjust_link() callback was not
    configuring the hardware in a completely correct way: while it was
    setting the speed and duplex bits correctly, it wasn't telling the
    hardware to actually take into account those bits rather than what the
    hardware-based PHY polling mechanism has concluded. So, in fact the
    adjust_link() callback was basically a no-op.
   
    However, the network happened to be working because on the network
    interfaces used by U-Boot for tftp on Armada 370 platforms because the
    hardware PHY polling was enabled by the bootloader, and left enabled
    by Linux. However, the second network interface not used for tftp (or
    both network interfaces if the kernel is loaded from USB, NAND or SD
    card) didn't had the hardware PHY polling enabled.
   
    This patch fixes this situation by:
   
     (1) Making sure that the hardware PHY polling is disabled by clearing
         the MVNETA_PHY_POLLING_ENABLE bit in the MVNETA_UNIT_CONTROL
         register in the driver ->probe() function.
   
     (2) Making sure that the duplex and speed selections made by the
         adjust_link() callback are taken into account by clearing the
         MVNETA_GMAC_AN_SPEED_EN and MVNETA_GMAC_AN_DUPLEX_EN bits in the
         MVNETA_GMAC_AUTONEG_CONFIG register.
   
    This patch has been tested on Armada 370 Mirabox, and now both network
    interfaces are usable after boot.
   
    [ Problem introduced by commit c5aff18 ("net: mvneta: driver for
      Marvell Armada 370/XP network unit") ]
Logged

sheevaplugger

  • Newbie
  • *
  • Posts: 3
Re: Slow download rate
« Reply #3 on: 20 December 2013, 04:17:36 pm »

Problem is solved with the new kernel version (provided by ARCHLINUXARM)     ;D
Logged
Pages: [1]
 
 

Powered by MySQL Powered by PHP SMF 2.0.10 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!