We've got a long range wifi link running here. Computers which are hardwired into the network can use EvoERP quite quickly. Machines which have the wifi link in between are somewhat slow. I believe that the wifi link is running at about 48 megabits per second. This is 1/2 the speed of 100btx I know but EvoERP rarely uses anything even close to full network utilization...  Does anyone else have some experience with wifi connected computers?
 
I have some theories... The latency is higher across a wifi link (significantly) but I don't know how much that effects things... I'd like to try getting ethereal working on my vista laptop to check this a bit...
 
The use of btrieve necessitates a separate function call for each data access. IN-H, for example, needs three data accesses per inventory item. This data access pattern appears serial in nature.
 
So, going with my latency theory, if a wifi link has 30ms latency then the maximum throughput would be 11.1 items per second. At that rate it would take 7.5 minutes to report on 5000 parts. However, locally (on the lan) there are latencies of 1-3ms which would create a maximum throughput of at least 111 (and upwards of 333) items a second. This brings the report time to 0.75 minutes which is a LOT better. I'll have to try this out to be sure that my latency calculations are accurate and that the function calls proceed serially but I'm pretty sure it's right... If I'm right then the major bottleneck is network latency and not throughput.
 
I know that we've somewhat discussed this before and the general consensus was that remote networking kills performance in Evo and that VNC or terminal server is the best solution. I just still don't like that answer.   Is there nothing else I can do?

Oh sure, give me a common sense solution.
 
Just for reference, I did fire up Wireshark (formerly Ethereal) and did a frame capture of IN-H.
 
It is true that btrieve communication proceeds serially. Also, my pings are less than I thought, it appears it's only about 4-5ms even to the furthest reachs of our wifi network. Still, at 4MS there is a serial communication rate of 250 package exchanges a second. This limits reporting to 250 records a second. In the case of IN-H there are three record accesses per inventory item and thus the theoretical upper bound of performance is 83 parts a second.
 
I'm really starting to lean toward SQL based access at all costs. I realize that that is essentially what you are suggesting. But, I'd still like to see a gradual transition to all C# or C++ or even VB apps for Evo instead of TAS. It appears that there is no point in replacing Pervasive as it has a relational engine but TAS has to go...
 
Part of the problem here is that the the wifi link in question goes to the owner's house and they'd like to work from home. I could write up some web based stuff for reports but they'll still want to use Evo and it's really slow because of the higher package exchanging latency. If things were switched to SQL queries the query could be sent and the whole result set returned with minimal TCP synchronization. And, even though I hate TAS some versions of it do support SQL queries... Maybe not Addsum's though...

Yes, those would be good things to check. I don't make a habit of tweaking those things however. And they tend to all get set to sane values unless you go out of your way to mess with them.
 
Also, my slowness can directly be mathematically calculated, as I did in my initial post. I'm fairly confident that the latency is due to the actual link latency and not to a misconfigured setting on the router or  NIC. I've also wireshark'd the link while using evo and I do not see packet fragmentation or anything abnormal happening.