Processor | Graphics | Discs | Parts Index |
Network | Power & Thermal | Other | Intro |
Wireless Network | 802.11b and g (Intel Pro/Wireless 2200BG) |
Wired Ethernet | 10/100baseT (Broadcom 440x) |
PCMCIA | One slot (Xircom wired NIC) |
Modem | 56kbaud v.90 (Conexant D110 MDC winmodem) |
Intel Pro/Wireless 2200BG. The Linux driver is ibw2200.ko; its development is sponsored by Intel. According to the documentation it also supports the 2915 wireless chip, which I don't have, and there's a different driver from the same people that supports the 1350. SuSE v9.2 provides v0.12 of this driver. It is fairly complete and useable. It can associate with both 802.11b (11 MHz) and 802.11g (54 MHz) access points and can change access points when you move out of range. Scanning works, and the card can report foreign access points even when already homed to a specific net. However, v0.12 has an annoying behavior of occasionally refusing to associate with your desired access point, and there's a debug message involving scanning. The latest driver version, 1.0.1, cures these problems. Get it, including the matching version of the required firmware, from ipw2200.sourceforge.net. To compile the driver you will need also to install the kernel sources from your distro. See here for the installation procedure.
The wireless antenna is in the upper portion of the lid, away from the user's lap and hands and from steel tables. This is a welcome improvement over the Inspiron 4100, whose antennae were in the speakers and hence were easily blocked. The driver claims higher signal-to-noise ratios than in the 4100, implying a better radio, though I don't have equipment to verify the claim independently.
These data rates, and those in subsequent paragraphs, are in bytes
per second, using scp
to copy a large compressed file (60 MB).
Percentages are the fraction of theoretical bandwidth (11 or 54 MHz)
that were actually achieved. In no case was CPU power the limiting
factor. I've seen a report on the web that implied that 802.11g is
substantially slowed down if any 802.11b devices are within range, and
that may explain the low data rates found for 802.11g.
Protocol | Dir'n | MHz | Windows | Linux |
---|---|---|---|---|
802.11b | Send | 11 | 3.73e5 (27%) | 5.80e5 (42%) |
802.11b | Recv | 11 | 6.10e5 (44%) | 4.18e5 (30%) |
802.11g | Send | 54 | 3.61e5 (5%) | 8.42e5 (12%) |
802.11g | Recv | 54 | 7.98e5 (12%) | 1.03e6 (15%) |
In Linux the kill switch
on Fn-F2 is honored by the driver; the
radio is turned off and packets are just dropped. But the driver will not
load if the kill switch is on. The panel LED for wi-fi
is not
turned on in any case.
There is one type IIIa mini-PCI slot which is occupied by the wireless NIC. This is not routed through PCMCIA as on older models; it's directly on the PCI bus.
Broadcom BCM-440x. The driver is b44.ko. Data rates in bytes per second. Percentages are the fraction of theoretical bandwidth (10 or 100 MHz) that were actually achieved.
Protocol | Dir'n | MHz | Windows | Linux |
---|---|---|---|---|
802.3 | Send | 10 | 6.78e5 (55%) | 8.42e5 (67%) |
802.3 | Recv | 10 | 1.05e6 (85%) | 1.01e6 (81%) |
802.3u | Send | 100 | 1.85e6 (15%) | 6.4e6 (51%) |
802.3u | Recv | 100 | 4.06e6 (33%) | 6.0e6 (48%) |
It appears that the Broadcom chip doesn't come up right away, so at least with Linux, the initial DHCP exchange will fail, but after a timeout of generally 60 secs it will get an address from DHCP. Cisco boxes show similar behavior: 30 secs from the time the partner's NIC turns on until packets can be accepted.
With most NICs, Cisco equipment will autonegotiate the best speed and duplex, and the Broadcom NIC claims to be able to autonegotiate itself. However, talking to a Cisco 6000 48 port 10/100 module (good, not flaky), this NIC botches the autonegotiation. The symptom is extremely low data rates and much packet loss, when 100 MHz was expected. Here's how to make it right (manually), setting 100 MHz full duplex:
Configurebutton for the NIC card; Advanced tab; Speed & Duplex; in the drop-down box select
100 MB Full, or
autoin an environment where autonegotiation is working.
The data rates seem a little low, but the file size was 60 MB and I repeated the tests two or three times with identical timings. It's inherently harder to make full use of the 100 MHz bandwidth unless you jack up the packet size, and then your router will probably give you a MTU quench.
There is one PCMCIA slot on the right side. When not using it, keep the dummy card in it, to exclude dust and insects. The eject button confused me. The complete cycle goes like this: Push the button in, then release it so it sticks out. Press it in again to eject the card. If you push it in all the way, the button will latch; if you miss, push it in again and it should latch. Now insert the new card.
I tested it with my old Xircom wired NIC. The driver is xircom_cb.ko. Data rates in bytes per second. Percentages are the fraction of theoretical bandwidth (10 MHz) that were actually achieved.
Protocol | Dir'n | MHz | Windows | Linux |
---|---|---|---|---|
802.3 | Send | 10 | 7.79e5 (63%) | 1.09e6 (87%) |
802.3 | Recv | 10 | 1.08e6 (87%) | 1.02e6 (82%) |
Conexant D110 MDC, 56 kbaud, v.90. Not tested in Windows but probably works. Linux kernel 2.6.8 et seq has the snd_intel8x0m driver for the generic AC'97 winmodem controller which frequently accompanies Intel integrated sound. However, the version in kernel 2.6.8 does not recognize the ICH6 chipset's PCI id. 2.6.11.5 has it, and I've seen a comment that it started in 2.6.9. Fortunately, snd_intel8x0m will not actually be needed.
That isn't all you need to make a winmodem work. See the linmodem site for a
starting point and some free drivers (for modems other than mine). I ran their
scanModem script (gunzip it, it's not a tar.gz file) and found out what
I suspected: Use the hsfmodem software from http://www.linuxant.com to support this
Conexant subsystem soft modem.
I've hacked up my kernel to deal with other issues, so from LinuxAnt's
download area for HSF modems I snarfed the RPM for unsupported kernels.
Without a license the driver connects at up to 14.4 Kbaud, whereas if you
pay for it you get (up to) 56 Kbaud and fax v1.0. When you install it, an
internal init script builds the modules, installs them, and installs a rc
script /etc/init.d/hsf that gets them loaded on every boot-up. As stated
in the instructions, the modem's device inode is created as /dev/ttySHSF0.
I used YaST2 to create a modem configuration for my ISP. YaST2 will
configure smpppd, a daemon front end to pppd. In SuSE 10.1,
/etc/init.d/network start modem0 -o manual
will now do the
whole work of starting daemons to manage the modem's PPP connection,
including soliciting the password on the ISP. Obviously this has to be
done manually, unless you have the security consciousness of a planaria
and put your password in the configuration file.
In older versions (or probably also in v10.1) you could use cinternet
(command line, see man page), kinternet (for KDE) or qinternet (for Gnome)
to tell smpppd to dial the ISP's number and set up the connection.
It actually works, surprisingly hassle-free. Uploading a file of 7.09e5 bytes took 7.5 minutes, or 1.7 Kbyte/sec (13.6 Kbaud) for the data portion, compared to 44 seconds or 16.1 Kbyte/sec (128 Kbaud) for uploading via DSL, or 8 seconds, 86.5 Kbyte/sec (692 Kbaud) for downloading.
Since I have wireless and DSL, the modem is not exactly a high priority item for me, so I'm not going to actually buy LinuxAnt. But I hope this discussion helps modem-bound people to get started. And I was torqued that the winmodem on the Inspiron 4100 was useless, so I was motivated to see it work on the Inspiron 6000d.
Processor | Graphics | Discs | Parts Index |
Network | Power & Thermal | Other | Intro |