Tried the same on a 34465A. My analysis is twofold:
1) use a lower chunk size
2) The DMM does indeed not seem to be keeping up at 50kSa/s (it might keep up when writing to file, read that somewhere, cannot find it now).
(and it may be better to also use v34465A.write("DISP OFF"), as that lowers the DMM's CPU load)
About chunk size:
When using the chunk size you gave, the communication breaks with a IO error within the minute in my setup.
When I lower the `chunk_size` (20480 is default), the communication holds out pretty well (I stopped testing after 30 minutes).
What query_binary_values() does, is send repeated VXI DEVICE_READ commands with length = `chunk_size`. However, VXI DEVICE_READ length cannot be above 65536. So 20000000 as `chunk_size` seems wrong to me for starters, although it does not complain and does work for some time.
Please note that `query_binary_values()` does not have a predetermined processing time: It returns only after the DMM's buffer is emptied. So at 50kSa/s that is rather irregular at start, and can get very long later on, as you found. But at lower sample speeds it is still very irregular.
You cannot use `data_points` (it is ignored), because you use the ieee header (so does the DMM, so don't change that). As a result, it just keeps on sending VXI DEVICE_READ commands until it decides that all is well. And that can be after a very long time: over a minute. Hence: you can get large response buffers, creating spikes in PC CPU time, thus creating irregular intervals between the end of the read and the next "R?" command, thus making the DMM's buffer load irregular and increasing the risk of data loss. If you want to do a more streaming approach to spread out the load, you might try going lower level than `query_binary_values()`, like `read_bytes()`.
About the "keeping up at 50kSa/s":
The average time between samples varies a lot, when set to 20usecs, and a lot of samples get lost. It starts to become stable at around 50usecs in my setup, and that is with almost no processing between calls to `query_binary_values()`. Check with `time.monotonic_ns()` for example. So yes, Python + this DMM over LAN is not fast enough for 50kSa/s.
Other remark: Please note that you tell the DMM to make 1M samples repeatedly. I might be wrong here, but that seems to me that you will miss out on some samples every 1M samples, when the DMM restarts the loop.
EDIT:
see
https://download.tek.com/document/1KW-61357-0_DMM6500_Datalogging_Application_Note_080318.pdf, appendix A for a streaming approach. It is another device, uses TSP script and lua (instead of SCPI), but the idea is identical to what could be achieved with ":R?" and lower level communication on the KS34465A. (DMM6500 does not have ":R?" by the way)
There is also an interesting phrase in there: " You can expect about 60,000 readings/second with this script, but this speed is limited by the Ethernet
cable of the LAN connection. Higher streaming speeds are possible by using a faster data bus such as a USB connection with PyVISA."
That device has 10/100BT and USB2.0 full speed, as does the KS34465A so that limitation is likely to apply to the KS as well. (rant: why no 1000?)
To be tested.....