OpenWRT is wonderful and elegant, but the wireless performance is ruined by excessive retransmission requests and perhaps 10% of what it could be (show as frame errors on eth1 interface).
In the mean time, besides OpenWRT, also tried Sveasoft and DD-WRT and all suffer from this issue.
Found on the net some indication that this problem did not exist with an older Linux kernel (2.4.20).
Would like to give it a try. How difficult is it, if you have the current HEAD toolchain installed and operational, to give an old kernel a try, or are there fundamental problems ?

Well, except for the latest alpha of DD-WRT, all the other firmwares use 2.4.20 as well, so it can't be the kernel version. Try stuff like erasing your nvram. This is particularly helpful after flashing other Linksys-based firmware like Sveasoft, which add a huge load of crap to the nvram.

Thanks nbd for your reaction. Of couse have made sure that nvram is not causing this.
Kernel now used is 2.4.30 , not 2.4.20, so that's why I am asking.
Is it complex to change back to an older one ???
With wired ethernet connections this phenomenon is caused when there is a communication conflict between two sides, one half-dupllex and the other full duplex or automatic. Perhaps the wireless interface just doesn't get properly hooked to the later kernel. As I have found no other suggestions would like to give it a try if reasonably doable. It's a pity that the system, that otherwise functions really beautifully, doesn't provide the radio bandwidth.
We have a 4 Mbps ADSL connection that is shared with a number of people but after the radio link only 600-700 k is left of it.

Why do you want to change back to the older kernel, when the other firmware that you've tried IS based on it and doesn't work either? I don't think it would help at all...

You are right about 2.4.20 in DD-WRT. Sorry for not having noticed that right away. So that eliminates that approach and saves time of trying.
Any other ideas where to look for the origin of this ?? Where is the decision made to ask for a retransmission, in the proprietary Broadcom radio drivers or somewhere in OpenWRT/Busybox/kernel software that the developers have access to ?
Even allowing for lots of overhead a 54 Mbps radio link should be able to do better than the 700 kbps effective transfer speed we see here at most.
Exhausted playing with a variety of radio settings. It improved from 500k to 700 kbps as result of gmode_cts collision protection and frameburst, but that's as good as it gets in effective bandwidth, even when experimenting only between two boxes sitting next to each other without anything special.

All the retransmission stuff is only in the proprietary driver. Maybe your hardware is faulty....

Yeah, that's a possibility but it must be a systematic error then because have tried 4 boxes now (2 pcs v2 and 2pcs v2.2). Noticed in the documentation section of the buildtree, where some ifconfig outputs are listed for various hardware flavours that there these frame errors also show, so it's not just my hardware.
Example from v2.2 documentation
eth1      Link encap:Ethernet  HWaddr 00:12:17:CC:CD:26
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:3083
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:50 (50.0 B)
          Interrupt:4 Base address:0x1000

So even without any effective communication frame errors already get reported.

If you do a wireless file transfer between two WRT54g units with strong signals, what effective speed do you see ?
Have tried this using sftp which is on all my boxes and have measured sending some files back and forth of several megabytes.

I haven't tried transfers between several WRTs, but if I transfer between my Powerbook (which also has Broadcom stuff) and my PC (through my WRT as LAN/WiFi bridge), I get 3.3-3.4MB/s performance using scp.
I'm going to do some more tests when I'm at home again...