3:25 p.m.
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
5:51 p.m.
On Tue, 7 Nov 2017 08:25:32 +1100
Stephen Morris <samorris(a)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.
https://fast.com/
7:25 p.m.
On Mon, Nov 06, 2017 at 04:51:33PM -0700, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100
Stephen Morris <samorris(a)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.
https://fast.com/
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.
--
-------------------------------------------------------------------------------
.---- Fred Smith /
( /__ ,__. __ __ / __ : /
/ / / /__) / / /__) .+' Home: fredex(a)fcshome.stoneham.ma.us
/ / (__ (___ (__(_ (___ / :__ 781-438-5471
-------------------------------- Jude 1:24,25 ---------------------------------
8:01 p.m.
On Mon, 6 Nov 2017 20:25:43 -0500
Fred Smith <fredex(a)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(a)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.
>
> https://fast.com/
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.
3:09 a.m.
On 07/11/2017 13:01, stan wrote:
On Mon, 6 Nov 2017 20:25:43 -0500
Fred Smith <fredex(a)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(a)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.
>>
>> https://fast.com/
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
1:45 p.m.
On Tue, 7 Nov 2017 20:09:40 +1100
Stephen Morris <samorris(a)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.
6:09 p.m.
On 11/07/2017 11:45 AM, stan wrote:
On Tue, 7 Nov 2017 20:09:40 +1100
Stephen Morris <samorris(a)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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Fear is finding a ".vbs" script in your Inbox -
----------------------------------------------------------------------
3:44 p.m.
On Tue, 7 Nov 2017 16:09:07 -0800
Rick Stevens <ricks(a)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?
5:10 p.m.
On 11/08/2017 01:44 PM, stan wrote:
On Tue, 7 Nov 2017 16:09:07 -0800
Rick Stevens <ricks(a)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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- We are born naked, wet and hungry. Then things get worse. -
----------------------------------------------------------------------
7:04 p.m.
On Wed, Nov 08, 2017 at 02:44:47PM -0700, stan wrote:
On Tue, 7 Nov 2017 16:09:07 -0800
Rick Stevens <ricks(a)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
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
The Lord detests the way of the wicked
but he loves those who pursue righteousness.
----------------------------- Proverbs 15:9 (niv) -----------------------------
8:40 p.m.
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.
4:16 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 4.13.10-200.fc26.x86_64 #1 SMP Fri Oct 27 15:34:40 UTC 2017 x86_64
Boilerplate: All mail to my mailbox is automatically deleted.
There is no point trying to privately email me, I only get to see
the messages posted to the mailing list.
A positive attitude is worth the effort if it annoys enough people.
7:40 p.m.
On 8 November 2017 at 17:44, stan <stanl-fedorauser(a)vfemail.net> wrote:
On Tue, 7 Nov 2017 16:09:07 -0800
Rick Stevens <ricks(a)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.
--
George N. White III <aa056(a)chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
2:58 a.m.
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(a)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.
>
> https://fast.com/
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
>
2:53 a.m.
On 07/11/2017 10:51, stan wrote:
On Tue, 7 Nov 2017 08:25:32 +1100
Stephen Morris <samorris(a)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.
https://fast.com/
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(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
5:53 a.m.
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(a)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.
>
> https://fast.com/
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
1:43 p.m.
On Tue, 7 Nov 2017 19:53:18 +1100
Stephen Morris <samorris(a)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.
2360
days inactive
2363
days old
17 comments
8 participants
participants (8)
-
Fred Smith -
George N. White III -
Patrick O'Callaghan -
Rick Stevens -
Samuel Sieb -
stan -
Stephen Morris -
Tim