Hi,
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
regards,
Steve
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
On Mon, Nov 06, 2017 at 04:51:33PM -0700, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
Is one of them reporting in "MB", and the other in "Mb" ?? the former is megaBYTES, the latter is megaBITS. They differ by roughly a factor of ten.
On Mon, 6 Nov 2017 20:25:43 -0500 Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Mon, Nov 06, 2017 at 04:51:33PM -0700, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
Is one of them reporting in "MB", and the other in "Mb" ?? the former is megaBYTES, the latter is megaBITS. They differ by roughly a factor of ten.
It could be something like that, except the math doesn't work. Stephen is saying that he gets 450 Mb/sec at 2.4 GHz in W10, and 252 Mb/sec at 2.4 GHz in F26(?). That's only a factor of ~2.
And the 5 GHz is 450 Mb/sec in F26, but 1.3 Mb/sec (Gb/sec?) in W10. If it's GHz, ~3.
These are all reported / theoretical speeds rather than measured speeds. What matters is how fast the bits move when doing a real task.
I don't know where he lives (Australia?), but I think 1300 Mb/sec is faster than most real world networks support, though Japan and Korea might be approaching that. Even 450 Mb/ sec is a respectable speed. The average speed in the US, last article I saw, was around 250 Mb/sec, though high speed connections are available at around 1000 Mb/sec.
On 07/11/2017 13:01, stan wrote:
On Mon, 6 Nov 2017 20:25:43 -0500 Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Mon, Nov 06, 2017 at 04:51:33PM -0700, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
Is one of them reporting in "MB", and the other in "Mb" ?? the former is megaBYTES, the latter is megaBITS. They differ by roughly a factor of ten.
It could be something like that, except the math doesn't work. Stephen is saying that he gets 450 Mb/sec at 2.4 GHz in W10, and 252 Mb/sec at 2.4 GHz in F26(?). That's only a factor of ~2.
And the 5 GHz is 450 Mb/sec in F26, but 1.3 Mb/sec (Gb/sec?) in W10. If it's GHz, ~3.
Sorry, I did mistype the speed, it was actually 1.3 Gb/sec under windows.
These are all reported / theoretical speeds rather than measured speeds. What matters is how fast the bits move when doing a real task.
I don't know where he lives (Australia?), but I think 1300 Mb/sec is faster than most real world networks support, though Japan and Korea might be approaching that. Even 450 Mb/ sec is a respectable speed. The average speed in the US, last article I saw, was around 250 Mb/sec, though high speed connections are available at around 1000 Mb/sec.
The connection speed being reported is the speed between the pc and the router over the wireless interface.
I am in Australia. The router is rated at 600 Mb/s on the 2.4 GHz interface and 1300 Mb/s on the 5 GHz interface to give it the connection speed of 1900 Mb/s AC. As I mentioned above under Windows I get 452 Mb/s and 1300 Mb/s respectively so I was expecting similar connection speeds under Linux.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Tue, 7 Nov 2017 20:09:40 +1100 Stephen Morris samorris@netspace.net.au wrote:
I am in Australia. The router is rated at 600 Mb/s on the 2.4 GHz interface and 1300 Mb/s on the 5 GHz interface to give it the connection speed of 1900 Mb/s AC. As I mentioned above under Windows I get 452 Mb/s and 1300 Mb/s respectively so I was expecting similar connection speeds under Linux.
Which is reasonable. If this is an open spec, I would expect linux to be at least as good as the windows results.
On 11/07/2017 11:45 AM, stan wrote:
On Tue, 7 Nov 2017 20:09:40 +1100 Stephen Morris samorris@netspace.net.au wrote:
I am in Australia. The router is rated at 600 Mb/s on the 2.4 GHz interface and 1300 Mb/s on the 5 GHz interface to give it the connection speed of 1900 Mb/s AC. As I mentioned above under Windows I get 452 Mb/s and 1300 Mb/s respectively so I was expecting similar connection speeds under Linux.
Which is reasonable. If this is an open spec, I would expect linux to be at least as good as the windows results.
Specs (open or not) often have little to do with it. It's more trying to figure out how the bloody hardware works. If you don't know which bits to fiddle on the chip, you may never get the speeds the thing supposedly advertises. Most Windows drivers are produced with the assistance of the manufacturer of the hardware because M$ funds it. On the flip side, I'd bet the majority of Linux drivers are reversed engineered and in some cases, the manufacturers actively try to hinder development (Texas Instruments was notorious for this 8-10 years ago).
Take any info that the Windows drivers report with a large grain of salt (perhaps even an entire salt lick). They've been known to, uhm, "fudge" the actual performance numbers. Even ignoring that, my machine is hardwired to another machine over a 1Gbps wire. I know I should get 1Gbps between the two, but in reality I get 850Mbps at best. That's the nature of the beast...there's a certain amount of overhead in TCP/IP you'll never, ever get past (on copper/glass links, 10-15%, on wifi it's higher).
The only way to accurately measure things is to transfer a big file across the wifi network from one wireless node to another on the same wireless segment (make sure both nodes have attached to the same wireless access point so you're not adding the router's latencies into it) and actually time the transfer. Make sure the network is quiet and that you use the same file transfer technique in each test (e.g. if you use FTP on Linux, use it on Windows, too) for an apples-to-apples comparison. Do multiple tests as well and average the results.
Don't do the tests using some native NAS-type thing (e.g. NFS on Linux and CIFS on Windows) since now you're adding yet another network protocol layer on top of the rest. You should also keep in mind that no matter which transfer technique you use, some implementations will be better than others (there's performance differences between FTP servers such as VSFTPd and ProFTPd and differences in the clients, as well). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Fear is finding a ".vbs" script in your Inbox - ----------------------------------------------------------------------
On Tue, 7 Nov 2017 16:09:07 -0800 Rick Stevens ricks@alldigital.com wrote:
Specs (open or not) often have little to do with it. It's more trying to figure out how the bloody hardware works. If you don't know which bits to fiddle on the chip, you may never get the speeds the thing supposedly advertises. Most Windows drivers are produced with the assistance of the manufacturer of the hardware because M$ funds it. On the flip side, I'd bet the majority of Linux drivers are reversed engineered and in some cases, the manufacturers actively try to hinder development (Texas Instruments was notorious for this 8-10 years ago).
I interpret this as meaning that the wireless standard isn't really *standard*. That is, that there can be extras above and beyond the standard that allow a manufacturer to enhance their offering with their own driver, yet allow generic drivers to work with their device at reduced throughput. Would that be a correct interpretation?
Take any info that the Windows drivers report with a large grain of salt (perhaps even an entire salt lick). They've been known to, uhm, "fudge" the actual performance numbers. Even ignoring that, my machine is hardwired to another machine over a 1Gbps wire. I know I should get 1Gbps between the two, but in reality I get 850Mbps at best. That's the nature of the beast...there's a certain amount of overhead in TCP/IP you'll never, ever get past (on copper/glass links, 10-15%, on wifi it's higher).
Thus, the ~10 bits per byte of transferred data that fred mentioned as his ballpark conversion for TCP. True?
On 11/08/2017 01:44 PM, stan wrote:
On Tue, 7 Nov 2017 16:09:07 -0800 Rick Stevens ricks@alldigital.com wrote:
Specs (open or not) often have little to do with it. It's more trying to figure out how the bloody hardware works. If you don't know which bits to fiddle on the chip, you may never get the speeds the thing supposedly advertises. Most Windows drivers are produced with the assistance of the manufacturer of the hardware because M$ funds it. On the flip side, I'd bet the majority of Linux drivers are reversed engineered and in some cases, the manufacturers actively try to hinder development (Texas Instruments was notorious for this 8-10 years ago).
I interpret this as meaning that the wireless standard isn't really *standard*. That is, that there can be extras above and beyond the standard that allow a manufacturer to enhance their offering with their own driver, yet allow generic drivers to work with their device at reduced throughput. Would that be a correct interpretation?
You can think of a standard as a list of minimums one must meet to be compliant. The standard can also specify maximums (such as the number of channels or bandwidth available). So long as you meet the minimums and don't exceed the maximums, you're compliant with the standard. In the case of networks, how much of the maximum you can push out determines your "goodness".
Take any info that the Windows drivers report with a large grain of salt (perhaps even an entire salt lick). They've been known to, uhm, "fudge" the actual performance numbers. Even ignoring that, my machine is hardwired to another machine over a 1Gbps wire. I know I should get 1Gbps between the two, but in reality I get 850Mbps at best. That's the nature of the beast...there's a certain amount of overhead in TCP/IP you'll never, ever get past (on copper/glass links, 10-15%, on wifi it's higher).
Thus, the ~10 bits per byte of transferred data that fred mentioned as his ballpark conversion for TCP. True?
Well, no. There is overhead on TCP/IP as there is on any network. For example, there's a 56-byte header present on all TCP/IP packets. So, for a standard MTU (maximum transfer unit) of 1500 bytes, only 1444 bytes are available for payload data. Add in the rest of whatever protocol you're using's overhead (which eats into that 1444 bytes) and the amount of payload shrinks even more.
Keep in mind that when you measure the throughput of a network connection, you're really only measuring the amount of payload that's being transferred--not the actual link speed. As a general rule, you can sort of count on 10-12% overhead for common wired xxxxxBaseT networks (the ones that use RJ45-type cables), a bit more for older coax systems like 10Base5 (thicknet) and 10Base2 (thinnet), and a bit more than that for wireless (with the ESSID broadcasts, retransmits, encryption, collision detection/backoff, etc.). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - We are born naked, wet and hungry. Then things get worse. - ----------------------------------------------------------------------
On Wed, Nov 08, 2017 at 02:44:47PM -0700, stan wrote:
On Tue, 7 Nov 2017 16:09:07 -0800 Rick Stevens ricks@alldigital.com wrote:
Specs (open or not) often have little to do with it. It's more trying to figure out how the bloody hardware works. If you don't know which bits to fiddle on the chip, you may never get the speeds the thing supposedly advertises. Most Windows drivers are produced with the assistance of the manufacturer of the hardware because M$ funds it. On the flip side, I'd bet the majority of Linux drivers are reversed engineered and in some cases, the manufacturers actively try to hinder development (Texas Instruments was notorious for this 8-10 years ago).
I interpret this as meaning that the wireless standard isn't really *standard*. That is, that there can be extras above and beyond the standard that allow a manufacturer to enhance their offering with their own driver, yet allow generic drivers to work with their device at reduced throughput. Would that be a correct interpretation?
Take any info that the Windows drivers report with a large grain of salt (perhaps even an entire salt lick). They've been known to, uhm, "fudge" the actual performance numbers. Even ignoring that, my machine is hardwired to another machine over a 1Gbps wire. I know I should get 1Gbps between the two, but in reality I get 850Mbps at best. That's the nature of the beast...there's a certain amount of overhead in TCP/IP you'll never, ever get past (on copper/glass links, 10-15%, on wifi it's higher).
Thus, the ~10 bits per byte of transferred data that fred mentioned as his ballpark conversion for TCP. True?
Not really. The reason you can't get 1 GBps on a 1GBps network is that there is always "other stuff" happening on the network that you don't see, that uses up some of the theoretical bandwidth.
the TL;DR part: ( the 10 bits per byte I mentioned was just the difference in the measurement units: 1GB is a gigaBYTE, but one Gb is a gigaBIT. And the factor of 10 is rough, suitable for off-the-top-o-me-head computations. Bytes are generally 8 Bits, so 10 isn't exact, but 10 also fudges for the various overheads in packaging up each packet for transmission.)
Just for example, the faster you pour packets down the pipe, the more likely that one of 'em is going to "collide" with a packet from some other system/process that also wants to use the network. When collisions occur, both systems that are sending stop, back off for a more or less random amount of time then try again. In general, this allows one of 'em to get finished before the other one tries again.
and there's the similar situation where the computer you're trying to use to send a big file (for a speed test, e.g.) goes to send one of its packets and finds someone else already using the wire. so it, again. has to back off for some more-or-less random amount of time and try again later.
Systems will listen on the wire to see if it is in use and if not will start sending. if two systems do that at the same time, that's where collisions come from.
the more computers/devices on the network the more likely that your file transfer will be repeatedly interrupted by finding the network in use by someone else.
those are normal things that happen, and the network hardware knows how to negotiate its way thru them. but they do mean you won't ever get a 1GBps file transfer on a 1GBps network.
and if you have wireless links in there somewhere its even worse, because there might be 20 local wireless APs all trying to transmit or receive on the same channel. and nearby microwave ovens, etc., etc., etc., ad nauseum.
Fred
On 11/08/2017 05:04 PM, Fred Smith wrote:
Just for example, the faster you pour packets down the pipe, the more likely that one of 'em is going to "collide" with a packet from some other system/process that also wants to use the network. When collisions occur, both systems that are sending stop, back off for a more or less random amount of time then try again. In general, this allows one of 'em to get finished before the other one tries again.
and there's the similar situation where the computer you're trying to use to send a big file (for a speed test, e.g.) goes to send one of its packets and finds someone else already using the wire. so it, again. has to back off for some more-or-less random amount of time and try again later.
Systems will listen on the wire to see if it is in use and if not will start sending. if two systems do that at the same time, that's where collisions come from.
This is what happens with wireless, but not on Ethernet any longer. Ethernet is all point-to-point, full-duplex. A switch passes the packets around between the links, but it has buffering so you don't lose the packets when you get multiple links sending to the same port. I suppose it's possible if you have multiple links sending lots of data through one other link that the switch could run out of buffer space. But in that case you're already over your bandwidth limit and transfer speeds will have to be throttled anyway.
Allegedly, on or about 8 November 2017, Fred Smith sent:
the TL;DR part: ( the 10 bits per byte I mentioned was just the difference in the measurement units: 1GB is a gigaBYTE, but one Gb is a gigaBIT. And the factor of 10 is rough, suitable for off-the-top-o-me-head computations. Bytes are generally 8 Bits, so 10 isn't exact, but 10 also fudges for the various overheads in packaging up each packet for transmission.)
You also have the confusions where some things report large numbers in SI units k=1000, etc, or binary power-of-two multipliers, k=1024, etc.
And, just to make figuring out what you ought to have more difficult, you have manufacturers who may round-up/down advertised figures to look nicer. e.g. Would they sell a device as a 497 MB or 500 MB thing?
Measuring wireless speeds can also strike unexpected (by most people) snags: Some wireless equipment doesn't work very well when the transmitter and receiver are very close to each other. And moving equipment by just a couple of centimetres can be enough to change reception problems caused by reflections/standing-waves.
On 8 November 2017 at 17:44, stan stanl-fedorauser@vfemail.net wrote:
On Tue, 7 Nov 2017 16:09:07 -0800 Rick Stevens ricks@alldigital.com wrote:
Specs (open or not) often have little to do with it. It's more trying to figure out how the bloody hardware works. If you don't know which bits to fiddle on the chip, you may never get the speeds the thing supposedly advertises. Most Windows drivers are produced with the assistance of the manufacturer of the hardware because M$ funds it. On the flip side, I'd bet the majority of Linux drivers are reversed engineered and in some cases, the manufacturers actively try to hinder development (Texas Instruments was notorious for this 8-10 years ago).
I interpret this as meaning that the wireless standard isn't really *standard*. That is, that there can be extras above and beyond the standard that allow a manufacturer to enhance their offering with their own driver, yet allow generic drivers to work with their device at reduced throughput. Would that be a correct interpretation?
Not really. As Rick notes, "standards" leave a lot of room for different quality of the implementation. In practice, there will be some maximum thruput that can be achieved following the standard under ideal conditions Vendors of consumer gear use the cheapest possible hardware, so need well designed and implemented drivers to approach the maximum thruput. Big vendors like Dell, HP, Lenovo won't use hardware that doesn't have good drivers for Windows. Linux drivers often build on earlier drivers for older hardware, with the priority on correct operation over thruput, so it should be no surprise that some Linux drivers don't have the thruput you get running the same hardware with Windows.
What really matters is how well a system works in practice. I've had many years of experience running I/O intensive linux apps on older Windows "enterprise class" desktops and laptops from major vendors. Some lower spec systems had a good linux network stack and outperformed newer, higher spec kit. This probably reflects the benefits of tweaks to the linux drivers over time, or, put another way -- lack of maturity for linux drivers on recently introduced hardware. The differences are generally greater for wifi than ethernet.
On 07/11/2017 12:25, Fred Smith wrote:
On Mon, Nov 06, 2017 at 04:51:33PM -0700, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
Is one of them reporting in "MB", and the other in "Mb" ?? the former is megaBYTES, the latter is megaBITS. They differ by roughly a factor of ten.
I've just checked Gnome again on the 5 GHz link and it is showing the connection speed as 450 Mb/s, which is in Megabits, if it was megabytes then that would equate to 3600 Megabits/sec, which the router is not capable of.
regards,
Steve
On 07/11/2017 10:51, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Github that now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?
I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
I couldn't access the site above but I could use the speedtest.net link it linked to, which gave me a result of 12ms ping, 125.62 Mbps download and 35.51 Mbps upload, but I'm not sure how that relates to the connect speed between my machine and my router? I'm also not sure how I can get 125.62 Mbps download speed on a 100 Mbps cable connection.
regards,
Steve
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Tue, 2017-11-07 at 19:53 +1100, Stephen Morris wrote:
On 07/11/2017 10:51, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100 Stephen Morris samorris@netspace.net.au wrote:
Having downloaded an updated version of the driver from Githubthat now compiles and runs with the 4.13 kernel I have looked at the wifi properties under Gnome and they tell me the connection speed is 450Mb/sec which is about the connection speed I get under Windows 10 with the 2.4 GHz interface. Under Windows 10 the 5 GHz interface connects at the documented speed of 1.3 Mb/sec. If I use the 2.4 GHz interface for the device gnome tells me the connection speed is 252 Mb/sec.
Why are the connection speeds in Fedora so degraded?I don't have an answer to your question, just a suggestion. What speed do you actually get when you test it? If the real life speed rather than the reported speed is different, then it is time to investigate why. If there is a real life discrepancy, then it could be that the firmware in linux is reverse engineered versus the custom tuned firmware for windows written by the manufacturer.
Not sure if this will work for you, but there should be one you can use somewhere on the web.
I couldn't access the site above but I could use the speedtest.net link it linked to, which gave me a result of 12ms ping, 125.62 Mbps download and 35.51 Mbps upload, but I'm not sure how that relates to the connect speed between my machine and my router? I'm also not sure how I can get 125.62 Mbps download speed on a 100 Mbps cable connection.
You can't, which means these numbers should be taken with a pinch of salt. Furthermore, I thought your concern was about your Wifi speed, in which measuring your Internet speed with a Speedtest link isn't telling you anything useful. You need to measure the actual transfer rate between two hosts on your local network, e.g. by timing a large (multi- gigabyte) file copy. If there is a significant difference between Linux and Windows when doing this, then it's time to investigate further. If possible, try both Windows-Windows and Linux-Linux, and make sure the rest of the network is quiescent during the test.
poc
On Tue, 7 Nov 2017 19:53:18 +1100 Stephen Morris samorris@netspace.net.au wrote:
I couldn't access the site above but I could use the speedtest.net link it linked to, which gave me a result of 12ms ping, 125.62 Mbps download and 35.51 Mbps upload, but I'm not sure how that relates to the connect speed between my machine and my router? I'm also not sure how I can get 125.62 Mbps download speed on a 100 Mbps cable connection.
It tells you that the router speeds aren't limiting your internet speeds. The slowest wireless speed (250 Mbps) is twice as fast as your internet connection. As far as the speed goes, I was recently speaking with an ISP tech, and he said that when the links aren't loaded, bandwidth is borrowed from unused links and lent to active links. I see that happen, where I get bursts of speed above the rate I am paying for. Though not to the extent that you are (I get about a 10 to 20 % boost).
Patrick has the right of it, though. If you want to test the wireless only, you have to do something that uses only the wireless link, and pushes it to the max.
-
Fred Smith -
George N. White III -
Patrick O'Callaghan -
Rick Stevens -
Samuel Sieb -
stan -
Stephen Morris -
Tim