Wireless network driver beta version released

[Ami603]

@Thread:
Hope you lot like it and find useful:

[fx]

Hi!

I'm posting this from my A1200 using this driver and a Lucent Technologies card rebranded as a HP card. It works fine and was real easy to set up!

Here are some ttcp results I got:
Amiga -> PC (TCP)
5.Ram Disk:> ttcp -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 40.56 real seconds = 403.97 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 20.28, calls/sec = 50.50
ttcp-t: 0:40real

AMIGA -> PC (UDP)
5.Ram Disk:> ttcp -u -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  udp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: 16777216 bytes in 43.69 real seconds = 375.04 KB/sec +++
ttcp-t: 2383 I/O calls, msec/call = 18.77, calls/sec = 54.55
ttcp-t: 0:43real

PC -> AMIGA (TCP)
5.Ram Disk:> ttcp -s -r
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.0.1
ttcp-r: 16777216 bytes in 37.46 real seconds = 437.43 KB/sec +++
ttcp-r: 2350 I/O calls, msec/call = 16.32, calls/sec = 62.74
ttcp-r: 0:37real

This A1200 is equipped with a Blizzard 1230-IV 50MHz and is running Kick/WB 3.1 and AmiTCP 4.3.

[patrik]

@fx:

Couldnt keep myself from trying this out on my A1200.

I have done a comparision between the prism2.device and cnet.device. The cards used were the same Lucent Technologies Wireless card as fx used and the famous CNet CN40BC 10MBit ethernet card. The computer used was an A1200 with a Blizzard1260 accelerator running OS3.1/WB3.1 and AmiTCP 4.3.

I did two different tests, first I measured the raw tcp and udp performance with ttcp and then I did a more realistic test to reflect the performance you can get "in real life" by measuring the speed of a remote samba share mounted with smbfs by using DiskSpeed 4.2.


-------- ttcp test with prism2.device --------
Amiga->PC(TCP):
8.SYSTEM3.1:> ttcp -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 28.15 real seconds = 582.07 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 14.07, calls/sec = 72.76
ttcp-t: 0:28real

Amiga->PC(UDP):
8.SYSTEM3.1:> ttcp -u -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  udp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: 16777216 bytes in 26.81 real seconds = 611.07 KB/sec +++
ttcp-t: 2637 I/O calls, msec/call = 10.41, calls/sec = 98.35
ttcp-t: 0:26real

PC->Amiga(TCP):
8.SYSTEM3.1:> ttcp -s -r
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.0.1
ttcp-r: 16777216 bytes in 25.37 real seconds = 645.71 KB/sec +++
ttcp-r: 10372 I/O calls, msec/call = 2.51, calls/sec = 408.77
ttcp-r: 0:25real

Notes:
The PC->Amiga(UDP) ttcp test cant be completeted as there is no delivery guarantee with the UDP-protocol and the PC will spew out all the packages at a higher rate than the Amiga can cope with.


-------- ttcp test with cnet.device --------
Amiga->PC(TCP):
8.SYSTEM3.1:> ttcp -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 24.21 real seconds = 676.79 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 12.10, calls/sec = 84.60
ttcp-t: 0:24real

Amiga->PC(UDP):
8.SYSTEM3.1:> ttcp -u -s -t 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  udp  -> 192.168.0.1
ttcp-t: socket
ttcp-t: 16777216 bytes in 29.55 real seconds = 554.46 KB/sec +++
ttcp-t: 3039 I/O calls, msec/call = 9.96, calls/sec = 102.84
ttcp-t: 0:29real

PC->Amiga(UDP):
8.SYSTEM3.1:> ttcp -s -r
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.0.1
ttcp-r: 16777216 bytes in 17.63 real seconds = 929.47 KB/sec +++
ttcp-r: 6653 I/O calls, msec/call = 2.71, calls/sec = 377.43
ttcp-r: 0:17real

Notes:
Regarding the missing PC->Amiga(UDP) ttcp test, see the above note. The cnet.device gives a very wierd result in the Amiga->PC(UDP) test, the result should be higher than the Amiga->PC(TCP) test, not lower. I think the cnet.device is capable of maxing out the 10MBit line in the PC->Amiga(UDP) test with this hardware/software configuration, but the reason for not quite getting there is probably the fact that it generates quite frequent collisions.


------ DiskSpeed test of smbfs with prism2.device ------
MKSoft DiskSpeed 4.2  Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68040  AmigaOS Version: 40.68  Normal Video DMA
Device:  SMBFS0:    Buffers: 170
Comments: smbfs with prism2.device

CPU Calibration shows that CPU availability tests
would be inaccurate in the current system state.
No CPU Speed Rating -- CPU % not available.

Testing directory manipulation speed.
File Create:           18 files/sec
File Open:            262 files/sec
Directory Scan:       582 files/sec
File Delete:           78 files/sec

Seek/Read:            145 seeks/sec

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       120865 bytes/sec
Write to file:     118419 bytes/sec
Read from file:    133389 bytes/sec

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file:        72477 bytes/sec
Write to file:      77407 bytes/sec
Read from file:    432719 bytes/sec

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       260128 bytes/sec
Write to file:     302650 bytes/sec
Read from file:    610583 bytes/sec

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       323994 bytes/sec
Write to file:     343283 bytes/sec
Read from file:    609637 bytes/sec


------ DiskSpeed test of smbfs with cnet.device ------
MKSoft DiskSpeed 4.2  Copyright © 1989-92 MKSoft Development
------------------------------------------------------------
CPU: 68040  AmigaOS Version: 40.68  Normal Video DMA
Device:  SMBFS0:    Buffers: 170
Comments: smbfs with cnet.device

CPU Calibration shows that CPU availability tests
would be inaccurate in the current system state.
No CPU Speed Rating -- CPU % not available.

Testing directory manipulation speed.
File Create:           21 files/sec
File Open:            452 files/sec
Directory Scan:       666 files/sec
File Delete:          278 files/sec

Seek/Read:            312 seeks/sec

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       199886 bytes/sec
Write to file:     224263 bytes/sec
Read from file:    236706 bytes/sec

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file:        81367 bytes/sec
Write to file:      84685 bytes/sec
Read from file:    664064 bytes/sec

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       295462 bytes/sec
Write to file:     349981 bytes/sec
Read from file:    908176 bytes/sec

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       430753 bytes/sec
Write to file:     545464 bytes/sec
Read from file:    927094 bytes/sec


I would say that the prism2.device gives quite good performance, especially if you consider the facts that its a beta driver and wireless networks in real life never comes close to reaching the raw maximum bandwidth set in the specification. In this case the maximum raw bandwidth would be 11MBit/sec.


/Patrik

[spirantho]

What about the Prism GT chipset? Is that supported?

Nice work BTW!

[Edit: Just bought myself what I think is a Prism GT network card on eBay to go with the Prism2 one I just bought... if it doesn't work, well then I'll just have to make it work. ]

[createcoms]

Prism GT isnt coming up for PCMCIA, only cardbus :-(

Fair enough though, I guess that crappy PCMCIA bus cant hack 54Mbps+



Also, any chances of an OS4 version of this?  Just for warm fuzziness.........

[ncafferkey]

@createcoms

As mentioned in the news post, there's already a version for PCI cards under OS4 (well, I said AmigaOne, but you knew I didn't mean Linux) :-) There'll be OS4 support for PCMCIA when OS4 runs on machines with PCMCIA.

@fx

Funny, I've got a similar machine to you (40Mhz 030), and I get less than half that speed with ftp.

@spirantho

I haven't looked at the Prism GT, but I'm under the impression that it's quite different.

[patrik]

@ncafferkey:

Comparing the prism2.device performance on your machine and fx's machine like this doesnt really say much. There are just too many factors affecting the results that is or might be different.

Your measurement will basically be a combination of the performance of prism2.device and your TCP/IP-stack, ftp-client and disk i/o. Factors that also plays a significant role is the performance of your cpu, memory, possibly harddrive and kickstart-version. Fx's measurement will basically be a combination of the performance of prism2.device and his TCP/IP-stack. Factors that also plays a significant role in his case is the performance of his cpu, memory and kickstart-version.

What ttcp measures is how fast data can be sent/recieved from/to memory using TCP or UDP packets - alas it measures the raw TCP or UDP performance on a software+hardware configuration without any added protocol-overhead after the top layer in the TCP/IP-stack. This is the reason why I didnt include ttcp as a factor in fx's measurement, but added the ftp-client as a factor in your measurement as it does first of all add a protocol-overhead in form of the ftp-protocol. Also, in an ftp-client, data will be downloaded/uploaded to/from disk of some kind, even if it is to the ramdisk it will add an overhead which will impact on the cpu and memory performance in a non-negligable way. This is the reason why I also added disk i/o as a factor in your measurement. The reason for adding the kickstart-version as a factor is that the card.resource found in kickstart 2.05/3.0 for some reason didnt give anywhere near as good performance with prism2.device as the card.resource found in kickstart 3.1. I suspect it might have something to do with better interrupt-handling in the latter card.resource.

When comparing performance in general, one should remove as much unnecessary overhead as possible and try to keep the remaining factors that shouldnt differentiate as similar as possible.

When measuring the performance of prism2.device on a 030-system you should definately remove as much unecessary overhead as possible as the hardware aint fast enough to max out the prism-card, atleast not with prism2.device in combination with AmiTCP 4.3/Genesis which is the most efficient TCP/IP stack available right now. This you can see as the 060 gives better results with ttcp than the 030. The results with the 060 is actually about as good as you can get with a 802.11b card. The bottom line of this is that any added overhead on say your 030-system will decrease the performance of the driver plus TCP/IP-stack combination (the raw TCP/UDP performance).

As a sidenote, network-performance on classic Amigas usually tends to be bound to the performance of the cpu and memory and not bound to the performance of the network-hardware as the cpu and memory in classic Amigas often aint fast enough to max out the hardware with the workload induced by the driver, TCP/IP-stack and application.


/Patrik

[djbase]

It works on my A1200 with a Netgear MA401 PCMCIA but only with WEP disabled. Anyone get this working? If so, how about some hints.

Did you get it working with WEP? Or anyone can confirm that the Netgear MA401 is full working?

[Furvert]

Is this still being developed? Finding cards is
proving difficult as most stores have `latest' HW revisisions. Maybe adding SSF?

Furvert

[golem]

Neil helped me get this card working. Thanks Neil. Only one more in stock at moment though.
http://uk.insight.com/apps/productpresentation/index.php?product_id=ALTNA03IVL&nbs_search=C%3D109%26S%3D101311%26P%3D%26search_type%3D%26K%3D%26M%3DALT%26AM%3D

[skipp604]

From my own experience I would like to just add, that it works flawlessly with a Linksys WPC11-WM (version 3) PCMCIA card. My setup includes Miami and Samba in Windows LAN (through a wireless router).

Great work, Neil!

[darksun9210]

nope. WEP seems to be broken on my netgear MA401 works fine without WEP... :-?