Ok, I'm pretty sure that latency hasn't an effect in async but bang mode, only in sync bit bang mode. So your problem might be something else.
I have written a small exe that you can use to test read/write timing to see if latency is what slows it down. Also, if it's not latency, this exe is about the simplest test so if you still see timing discrepancies between computers you might want to contact ftdi directly. In my experience when contacting (US) FTDI support they responded immediately. Just make sure you describe the problem completely including referencing the code (probably referencing the c code, since they might not help you with LabVIEW code) so that they take you seriously.
Now back to the exe, it's 32 bit release version and was built against version .14 of the driver. To run it, first name the exe filename with the device description followed by ".exe"; we'll use the filename to open the device by description. So if the device description is "a device", the filename should be "a device.exe". Then just run it.
On the screen it'll write 100 bytes followed by 124 bytes followed by a read of 100 bytes and 124 bytes. For each stage it'll repeat 20 times and then print how long an average read/write took. When writing/reading the same number of bytes as the transfer size (actually transfer_size/64*62) and if the transfer size is a multiple of 64 (we set it to 128), latency never comes into play. If latency comes into play, the 100 bytes read/write should take much longer than the 124 counterpart (Latency was set to 200ms, so if it has an effect it will be very obvious).
Either way, you can run it on multiple computers and compare for example each read/write between computers.
At the moment I'm away so I cannot test the code, but I have mutated it of some of the testing I do on FTDI devices so it should work. Let me know if you have any issues and of the results.
Matt
P.S. I'm also attaching the code used to make the exe.
