On 11/08/2017 01:44 PM, 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? 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@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - We are born naked, wet and hungry. Then things get worse. - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
