Intel Putting Wi-Fi into Future Chipsets
Ridgelift writes "Wired's got the story on Intel's plan to incorporate Wi-Fi into the motherboard chipset. "The chipset, however, will not include an actual Wi-Fi radio, so users will still need a wireless add-on card. Intel has said it eventually intends build a Wi-Fi radio into its microprocessors." This would make setting up a wireless network a lot simpler."
The reason why Intel probably don't want to integrate the Micoprocessor with the actual WiFi transmitter and receiver is quite simple. If they add it inside the IC, they will have to go through radio use approval for every different potential market in the world, before they sell a single component. By letting the motherboard/add on card manufacturer's do this instead, they can concentrate on developing better microprocessors.
As somebody in the know, I do worry that these new WiFi enabled equipment could be the next mobile phone when it come to interference of avionic systems; especially as many modern microprocessors are prone to soft faults at altitude due to the effects of the upper atmosphere.
This is to make it so that an average desktop computer can function as a router for WiFi traffic in the home or office. The card is needed NMW, in order to grab that traffic. A poster above mentioned using a software radio, but it seems that that would only be useful if things were reversed: the software radio *interprets* the signal, and *generates* one to return to the WiFi device in question, but ultimately it is a radio device which transmits that signal into the air. The problem Intel will face is explaining this in terms that a PHB who *signs* the check to buy this stuff.
Emacs: for people who just never know when to
I'm all for WiFi everywhere, but it sounds like a pretty big backdoor to me, I don't think I'd want to have a WiFi connection built onto my board that I couldn't disable with anything mroe then software. Next thing you would know Microsooft is using it to send DRM related information or usage stastics without you knowing.
I realize that it would probably able to be disabled in BIOS, but it wouldn't take much that if M$ wanted to take control they could do it with a few sentences in the EULA.
Improbable, but possible.
This just is another step in Intel's ploy to rule the wireless market through cheap and underhanded business practices. Not many people know this, or at least I didn't till I started shopping for a laptop 2 days ago, but all new laptops carrying the Centrino designation have to come with an Intel miniPCI WLAN card preinstalled or they cannot be called Centrino. Which is great except that Intel refuses to support Linux on their stinkin' card. (Yes I could go elsewhere, but for the price, speed, and power consumption, Centrino is far and away the best on the market right now.) If you want to monopolize an entire hardware sector, fine--good luck trying. But don't chain me to a stupid Wintel platform because of it. If Intel had their way they'd be the only supplier of WiFi cards within a few short years--then WTF do we do if we're not on Windows?
I think there is a world market for maybe five personal web logs.
Driverloader is working perfectly for my intel 2100 in my laptop. 2 minute install, and then I have another eth* device, use the standard iwconfig and I'm on the 'net. DriverLoader is well worth the 20 bucks.
Intel are not forthcoming with documentation about NIC and crypto. Here is what OpenBSD has to say about this :
OpenBSD experience with Intel
Much like Intel does for all their networking division components, and completely unlike most other vendors, Intel steadfastly refuses to provide us with documentation. We have talked to about five technical people who are involved in the development of those products. They all want us to have documentation. They commend us on what we have done. But their hands are tied by management who does not perceive a benefit to themselves for providing documentation. Forget about Intel. (If you want to buy gigabit ethernet hardware, we recommend anything else... for the same reason: most drivers we have for Intel networking hardware were written without documentation).
Not sure if asx100 and acx100 are the same thing, but if so, have you tried this?
Jesus was all right but his disciples were thick and ordinary. -John Lennon
If AutoCAD or UT2003 aren't part of the design spec, motherboard integration makes a great deal of sense.
Um, I know Dell sells them. There was a 802.11b MiniPCI card from Dell on sale for $29 the other week. Check Techbargains for it. Also, if you're desperate, you can generally rip apart a consumer AP or "router" and yank out it's MiniPCI card, too.
1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
I agree that we should not sacrifice modularity for all-in-one disposability, but for all the applications you list (IDE, NIC, video) you can put in a modular card and override the integrated stuff. Personally, I think ubiquitous integrated mobo NICs are one of the handiest hardware improvements of the last five years.
Internet protocols were designed around wires and it shows when you go to wifi meshes. Meshes are critical due to the fact that meshes scale. If you are going to have a wifi node in every consumer device, as seems potentially viable, then you need to continually discover new routes and do so on nearly every packet. Route-flap is what you get, even with damping protocols, with current internet standards. You can end up waiting minutes for a route to stablize.
Here's an algorithm for a mesh node that seems to work simply:
Just keep a table of destination IP addresses in memory with a counter that decays exponentially with time.
When the counter decays below some threshold, clip its IP address from the list. An IP address with no counter is considered to have a value of 0.
Every time a packet acknowledgement comes through for a given destination IP address, add one to the counter for that IP address.
Whenever a packet (not already awaiting acknowledgement) is 'heard' destined for an IP address, queue it for rebroadcast according to a priority established by the IP address's counter.
Let packets that fall off the end of the queue due to low priority do so without further consideration.
More complex algorithms are required for transmission power optimization, but even this simple algorithm shows how far off-base current internet protocols are for wifi.
Seastead this.
It will probably be easy for mobo makers to make use of this as an optional feature, much like SATA, USB 2.0, etc. Then you just need to have an antenna lead from the mobo, and enable it in the BIOS: it will work just like parallel/serial ports.
Manipulate the moderator system! Mod someone as "overrated" today.
I know you said retail, but I bought a lucent orinoco minipci card off Ebay a little while ago. $35 for the minipci card attached to a real pci card - removed two screws, popped it out of the socket and replaced my Intel pro/2100 (piece of crap), and have been happy ever since!
It uses the Orinoco cardbus drivers, since the orinoco minipci card is essentially a PCI card with a TI 1410 PCI/CardBus bridge and a CardBus orinoco card all in a minipci form factor. Cool stuff.
http://slashdot.org/articles/99/11/25/094246.shtml
Actually, they already tried that. However, their Israel design team had it almost finished when they pulled the plug, and they were PISSED. Ah, well, they were happy when they got the Pentium M project - what the P4 shoulda been!
BTW, have you played with a Cyrix MediaGX? If so, then you should be modded funny. If not, they need to make a mod for stupid - Cyrix's implementation SUCKED - 44-50MHz CPU speed was lost, and the video was worse than i810.
First of all, the section above is listed under the header called "Intel Ipsec Cards" and more specifically refers to the Intel Encryption Coprocessor on the card.
Further, Intel has written and released a free, GPL ethernet driver for their EEPro 100, 1000, and 10000 ethernet cards. I shall transcribe for your benefit the top few lines from linux/drivers/net/e100/e100_main.c:
That driver is a GPL implementation meaning that the OpenBSD developers are more than welcome to port it at their leisure.
Oh, you want real documentation too. Take a look at developer.intel.com:
Intel 82551ER Fast Ethernet Controller Networking Silicon Datasheet
Intel 82559ER Fast Ethernet Controller Networking Silicon Datasheet
Intel 82559ER EEPROM Map and Programming information
True, Those are for their FastEthernet chipsets, not the Gigabit chipsets that, "Intel steadfastly refuses to provide us with documentation"
Well, what about these?
Intel(R) 82541ER Gigabit Ethernet Controller Networking Silicon Datasheet
Intel(R) 82547GI(EI)/82541ER EEPROM Map and Programming Information Guide
Ok, so the IPSEC chip on the NIC isn't supported nor is there any data on that chip forthcoming. However, there are a number of papers that show that IPSEC and TCP offloading (not to be confused with TCP fragmentation/checksumming) are not efficient. Specifically, the "hardware" IPSEC is done by firmware downloaded to a small embedded processor on the NIC. This small, embedded NIC is not very fast, in fact, its rather slow.
Result:
Processor utilization drops marginally (modern processors can encrypt 10 megabytes/s trivially)
Latency shoots up (It takes the embedded processor longer to encrypt a packet than the host processor would.)
There are a number of papers corroborating that latency has a huge effect on maximum bandwidth.
[I think the paper regarding TCP offloading not being worthwhile is by Mudge. The IPSEC offloading not being worthwhile is my hypothesis, untested, but I feel logically founded.]
My point is that IPSEC offloading is not an advantage - it probably was in 200MHz K6 days, but it certainly is not in 2.0 ghz K7 days.
Other notables, for example, the 3Com 3CR990 still doesn't have IPSEC offloading, despite promises from either the openbsd txp driver or the linux typhoon driver.
Frankly, as far as Gigabit
fnord.