This is by design at present due to the way network test traffic is processed on touch and baby.  The limit is restricted because you will end up testing the cpu performance of touch/baby if it goes much higher - i.e it will show less than 100% due to running out of cpu rather than network congestion.  (touch could probably go higher but not by double)

What's needed is a rewrite of the software which processes the test messages to make it more efficient.

Thanks, do you perhaps now how fast the Touch can do wifi (best case) ?
Where is the bottleneck wifi chip ? driver ? SqueezeOS, Squeezeplay ?

Otherwise it's seems to be better than the SB3 on wifi it reports solid 100% from the same position so I expect it to be better.

Bottle neck is the code - its written in lua on Squeezeplay using string manuipluation which is not designed for handling large streams of data and hence is slow.  It really needs to be moved to C which should be much faster.  I would also move it to the streaming connection rather than the control connection if I did this as it would be more representative of real streaming.

*** This bug has been confirmed by popular vote. ***

I created a keyword to track bugs in multiple areas related to touch firmware performance.