Slashdot Mirror


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."

16 of 216 comments (clear)

  1. There are other problems by plusser · · Score: 5, Informative

    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.

  2. To clarify: by HoldmyCauls · · Score: 2, Informative

    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 :q!
  3. DRM implementation by 4volt · · Score: 3, Informative

    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.

  4. Monopolistic BS by drix · · Score: 2, Informative

    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.
  5. Re:Intel linux support sucks by Anonymous Coward · · Score: 1, Informative

    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.

  6. Re:Intel linux support sucks by Homology · · Score: 5, Informative

    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).

  7. Re:Intel linux support sucks by gmhowell · · Score: 2, Informative

    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
  8. Re:Ack by antiMStroll · · Score: 2, Informative
    We use on-board ACL 650 sound for commercial use and it's fine, much better than being forced to load Creative's nasty software (circa Audigy 1, haven't tried the 2.) The motherboards we select use Intel integrated NICs, vastly superior to the typical Realtek-level junk found in so many machines. Modems, you have a point, integrated video however has its uses. The desktop demands in a corporate environment are typically meagre. Integrated handles the task fine and has the added benefits of reduced noise, heat and cost, plus increased reliability (no GPU fan) and generally better stability since the GPU and MB were designed as one.

    If AutoCAD or UT2003 aren't part of the design spec, motherboard integration makes a great deal of sense.

  9. Re:Intel linux support sucks by O · · Score: 2, Informative

    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.
  10. but... by sbma44 · · Score: 2, Informative
    you probably *could* have swapped in an ide controller board and just turned off the faulty integrated controller in the bios.

    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.

  11. The real problem is routing by Baldrson · · Score: 2, Informative
    Having set up a municipal mesh network it is pretty obvious the real problem to solve for WiFi isn't higher levels of integration so much as routing.

    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.

    1. Re:The real problem is routing by sploxx · · Score: 2, Informative

      In IPV4, you can't allocate space for WiFi meshes anymore. ACK.

      But this is not true for IPV6. In IPV6 you can allocate big classless spaces and use these for your mesh networks. A 10 million city with one IP per PC, washing mashine, toaster... no problem.

      What you describe at the most important problem in todays IP world is not the basic protocol, i.e. IP. You are criticizing the routing protocols, they do not match well with fluctuating mesh networks. Indeed. They are designed for wired networks. But most of the internet traffic still runs over wires, and this will probably stay so even with competion from wifi. You can't really put all that bandwidth through wifi.

      There are solutions that work on top of IP, in a very clean way, and these solutions work well in the lab. In the field, there are not yet enough studies which support this research.
      The proposed new network architectures consist mainly of new routing protocols adapted to mesh networks. I see no problem with IP as the underlying protocol. It works, it's relatively reliable and it's already there. And the research groups (Are you professionally working on this topic? - I'm not. But this doesn't invalidate my arguments, I think...) are using IP on the lower level...

      For more information, try google for "manet". There is already much information out there.

      I can't really talk about you routing algorithm because I haven't seen it in simulation or reality. To state that a particular routing algorithm is good by just drawing it onto paper is a good start, but not a proof of concept. Maybe it works, maybe not. But try it out and build devices which connect to a mesh network (Mesh networking is one of the things I consider to play around with next in my freetime) and show the world that it works. But I'm sure that the underlying packets can IPV6 instead of your custom protocol without any functional penalty.

  12. Mobo features by t0ny · · Score: 2, Informative

    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.

  13. Re:Intel linux support sucks by gordyf · · Score: 2, Informative

    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.

  14. Re:Wintel are both right. by bhtooefr · · Score: 2, Informative

    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.

  15. Re:Intel linux support sucks by megabeck42 · · Score: 2, Informative
    Frankly, this is taken out of context and is rather misleading. Sometimes I wish for a moderation option entitled "Wrong."

    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:

    Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved.

    This program is free software; you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by the Free
    Software Foundation; either version 2 of the License, or (at your option)
    any later version.

    This program is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
    more details.

    You should have received a copy of the GNU General Public License along with
    this program; if not, write to the Free Software Foundation, Inc., 59
    Temple Place - Suite 330, Boston, MA 02111-1307, USA.

    The full GNU General Public License is included in this distribution in the
    file called LICENSE.

    Contact Information:
    Linux NICS
    Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497

    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.