It is a little bit faster.
Three runs for each OS. The scope's "SINGLE" button was pressed once before each run:
rogeorge@debian80:~/Downloads/v5 - interleaved request$ ./ds1054z 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 22.061 sec.
rogeorge@debian80:~/Downloads/v5 - interleaved request$ ./ds1054z 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 22.162 sec.
rogeorge@debian80:~/Downloads/v5 - interleaved request$ ./ds1054z 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 21.973 sec.
rogeorge@debian80:~/Downloads/v5 - interleaved request$
==========================
C:\v5 - interleaved request>ds1054z.exe 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 22.078 sec.
C:\v5 - interleaved request>ds1054z.exe 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 22.203 sec.
C:\v5 - interleaved request>ds1054z.exe 192.168.1.3
Version 5
Connected
Received 24001152 bytes in 22.171 sec.
C:\v5 - interleaved request>
The data request was indeed interleaved. All test results available at:
http://s.go.ro/hcy7ogyq | password: 763674
Other options might be:
- make multiple requests at once, like 3-4 of 250 000 consecutive requests separated with semicolon.
- make single interleaved request but for 1 000 000 points instead of 250 000. Depending on how much free memory the scope might have at that moment, sometimes it can serve up to 1 700 000 points at once. If the response starts with a number after #9000 that is not equal with the expected length, then the request was too big. 1 mil points is usually safe for a single trace and no other scope functions activated.
- open a new socket for each request of a new datapoints batch, etc
but I suppose there will be no spectacular increase in transfer speed because, looking at the charts, it seems most of the time is spent waiting for the scope to prepare the next batch of datapoints to be sent.
Some charts for v5 results: