On Wed, Nov 08, 2017 at 02:44:47PM -0700, stan wrote: > On Tue, 7 Nov 2017 16:09:07 -0800 > Rick Stevens <ricks@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx ----------------------------- The Lord detests the way of the wicked but he loves those who pursue righteousness. ----------------------------- Proverbs 15:9 (niv) ----------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx