LabVIEW
Serial write takes unexpectedly long when more than 7 bytes are written
Where are you getting these times from? Regardless, coming from a Windows machine it is really hard to believe numbers down in the us range.
Out of curiousity, what happens if you remove the setting of the IO Buffer?
There is quite a bit of overhead in any function call and VISA is no exception there. In fact the data has to go through several driver layers before it arrives at the port. So your example is likely to give you almost the same time independent if you write 9 bytes or quite a bit a larger string. This is because there is an inherent overhead in calling all kinds of layers. But the solution to this is not to go and write a single layer system, even if that would could down the overhead a bit, it will not give you magnitudes of performance gain, at the cost of a totally inflexible, unmodular and unmanageable interface.
You might have to investigate other sollutions if you really want to have that high speed control, such as going FPGA. Or change your approach and write bigger blocks at once to the serial port.
As a thumb of rule you can get timiing accuracy to a few 100 ms under desktop OSes, (only soft not hard, meaning Windows will be happy to do this in 99.9 % of the cases but can always have outliers in the second range), down to maybe 100 us to 1 ms on realtime system and anything faster than that you have to look at hardware based solutions such as FPGA control.
The driver might for a lot of reasons not want to or even can't fill up the 8 byte hardware FIFO buffer entirely. This could be for instance since it has to work around some bugs in certain hardware. It might not be necessary for the specific hardware revision in your system but that driver has to work for many different hardware systems.
The magnitude of timing control you try to achieve is simply beyond a software system if you require reliable and hard timings. It may be possible to achieve on a simpler but still powerful embedded system with custom made software drivers and RT OS but not on a more general purpose RT OS even if the hardware is pretty powerful. But such more custom made solutions would be more than a few magnitudes more expensive to develop.
You can keep barking up this tree but it is unlikely that NI can do much about it without redesigning parts of the RT system, which is pretty much out of question as they simply license it from Ardence/IntervalZero and only adapt it where it is strictly necessary to work with their hardware. Most likely their license doesn't even allow them to customize it at will in any other way than is strictly necessary to get it to work on their own hardware.
Your options are as far as I can see, to either rethink the timing requirements or adapt the software in such a way that the bigger delay won't be a problem or to go with a hardware solution based on an FPGA board or similar.
As to the difference of asynchronous write and synchronous that is mostly about what VISA API is called underneath. The LabVIEW function remains blocking for as long as is necessary to pass the data to the OS driver. In synchonous mode the LABVIEW VI calls the synchronous VISA API once and that simply waits until VISA returns from the function. For the asynchronous case LabVIEW calls the asynchonous VISA function and then keeps looping inside its own cooperative multithreading layer until VISA indicates that the asynchonous function has been performed. This is mostly for historical reasons when LabVIEW didn't have OS supported multithreading and all the multithreading happened in the cooperative LabVIEW code scheduler. Nowadays asynchonous VISA mode has almost no benefits anymore but genearlly will cause significantly more CPU load.
