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, ...).
I wonder why we would use such small buffers for sending data?
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.
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.
Maybe we should add the patch to our tree after all, and then poke Greg about including it, based on testing results.
(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.
(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.
I see that the patch is indeed referring to the option.c file.
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.
Is there any update on this?
Loosk like the fix is upstream now: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/usb/serial/option.c;hb=HEAD
Upstream patch is in 2.6.27.14-170.2.12.fc10
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
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.