Bug 473252 - Slow UMTS/3G upload rate
Slow UMTS/3G upload rate
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 480290
  Show dependency treegraph
 
Reported: 2008-11-27 07:04 EST by Roland Wolters
Modified: 2009-09-23 19:03 EDT (History)
9 users (show)

See Also:
Fixed In Version: 2.6.27.15-170.2.24.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-19 18:23:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for the described behaviour. (407 bytes, patch)
2008-11-27 07:04 EST, Roland Wolters
no flags Details | Diff

  None (edit)
Description Roland Wolters 2008-11-27 07:04:04 EST
Created attachment 324872 [details]
Patch for the described behaviour.

Description of problem:
The UMTS/3G upload rate under Linu is rather slow. Compared to MS Windows the upload rate is only half as large.

Version-Release number of selected component (if applicable):
The problem persists even with the current kernel tree.

How reproducible:
Start a Linux, plug in some UMTS/3G hardware (like Huawei EM770 used in the Asus eeePC, the Option GI0225 sold by T-Mobile in Germany, the Huawei E172 sold by Vodafone in Portugal, and so on), connect to the mobile network, upload a file, and watch the upload rate. It should be half as large as the upload rate under Windows XP.

Steps to Reproduce:
1. Start a Linux, plugin the hardware.
2. Connect to the mobile network.
3. Upload a file.
  
Actual results:
In our tests the upload rate was less tahn 600 kbit/s., Windows had more than 1200 kbit/s.

Expected results:
The upload rate should be equal.

Additional info:
I am in contact with two large international hardware vendors and one large mobile phone company. All three confirmed the problem in their labs. The attached patch fixes the problems, and that result was confirmed by the labs as well!

I'm not sure how to send a patch upstream to the Kernel list directly, so I use this way - after all, my Fedora is affected as well, although this problem also affects all distributions we tested (Debian/Ubuntu, Fedora, self built kernels, openwrt, ...).
Comment 1 Chuck Ebbert 2008-11-27 11:06:31 EST
I wonder why we would use such small buffers for sending data?
Comment 2 Roland Wolters 2008-11-28 07:32:18 EST
No idea - but even gkh suggested to switch the buffer size to a larger value:
http://article.gmane.org/gmane.linux.elitists/12515
I will ask him what he thinks about the patch and if there are any reasons why the value is so small currently.
Comment 3 Jeff Gustafson 2008-11-30 21:27:47 EST
I think option.ko is designed for this purpose.  I recall reading about this performance problem a while ago.  The solution was to load option.ko with the device ID of the UTMS/CDMA device.  The only problem with this approach is that it is a very manual process.
Comment 4 Pete Zaitcev 2008-11-30 21:47:46 EST
Maybe we should add the patch to our tree after all, and then poke Greg
about including it, based on testing results.
Comment 5 Peter Robinson 2008-12-01 03:49:03 EST
(In reply to comment #3)
> I think option.ko is designed for this purpose.  I recall reading about this
> performance problem a while ago.  The solution was to load option.ko with the
> device ID of the UTMS/CDMA device.  The only problem with this approach is that
> it is a very manual process.

No, option is for a specific brand of 3G card called Option. See http://www.option.com/ for their products.
Comment 6 Jeff Gustafson 2008-12-01 05:03:55 EST
(In reply to comment #5)
> (In reply to comment #3)

> No, option is for a specific brand of 3G card called Option. See
> http://www.option.com/ for their products.

From option.c:
  This driver exists because the "normal" serial driver doesn't work too well
  with GSM modems. Issues:
  - data loss -- one single Receive URB is not nearly enough
  - nonstandard flow (Option devices) control
  - controlling the baud rate doesn't make sense

  This driver is named "option" because the most common device it's
  used for is a PC-Card (with an internal OHCI-USB interface, behind
  which the GSM interface sits), made by Option Inc.

[...]

{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EVDO_2) }, /* Novatel EVDO product */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_HSPA_2) }, /* Novatel HSPA product */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_EMBEDDED_2) }, /* Novatel Embedded product */
{ USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_GLOBAL_2) }, /* Novatel Global product */

[...]

{ USB_DEVICE(DELL_VENDOR_ID, 0x8136) }, /* Dell Wireless HSDPA 5520 == Novatel Expedite EU860D */
{ USB_DEVICE(DELL_VENDOR_ID, 0x8137) }, /* Dell Wireless HSDPA 5520 */
{ USB_DEVICE(DELL_VENDOR_ID, 0x8138) }, /* Dell Wireless 5520 Voda I Mobile Broadband (3G HSDPA) Minicard */

---------------

I know Option makes cards and sells them under their own name, but as the source code shows, the interface has found itself in many brands of WAN modems.  Just look at the list in option.c.  According to what I've read on the 'Net, if you are having trouble with your WAN modem with usbserial, try option and see if it works better.  Apparently the 'option' interface is amazingly similar to usbserial devices, BUT they are dumber.
Comment 7 Jeff Gustafson 2008-12-01 11:57:55 EST
I see that the patch is indeed referring to the option.c file.
Comment 8 Roland Wolters 2008-12-01 17:10:23 EST
GKH answered me that he will see to bring that into the kernel. As soon as there is something done he will CC me and I will add a comment here.

comment #4:
That would first of all require someone to test it. And as I said, we run quite some hardware tests here and they were all positive.
Comment 9 Peter Robinson 2009-02-02 12:00:52 EST
Is there any update on this?
Comment 11 Chuck Ebbert 2009-02-02 18:51:02 EST
Upstream patch is in 2.6.27.14-170.2.12.fc10
Comment 12 Robert Townley 2009-02-25 15:39:56 EST
i hope to test if this fixes 480290 tonight.
Bug 480290-rndis downloads are awesome, but upload does not work or very slow.
https://bugzilla.redhat.com/show_bug.cgi?id=480290
Comment 13 Robert Townley 2009-09-23 18:31:44 EDT
How does one turn on the above patch?  insmod option didn't increase speed.

i missed this bug entry and was following 480290.

With FC11 2.6.30.5-43.fc11.i586, uploading is non existent.  Same with FC10 earlier this summer.  

Would ethtool or something similar tell me what is set for N_OUT_URB and OUT_BUFLEN?  Would it be somewhere in /proc/?

https://bugzilla.redhat.com/show_bug.cgi?id=480290

i did yum install kernel-devel, but option.h has file size 0.

/usr/src/kernels/2.6.30.5-43.fc11.i586/include/config/usb/serial/option.h has file size 0.

Isn't there a way for yum to find and download drivers/usb/serial/option.c 
because i don't see that at all.

Note You need to log in before you can comment on or make changes to this bug.