Hi Dirk,
On 2012-06-19 Dirk Zimoch wrote:
When I change from DOUBLE to FLOAT arrays, nothing changes.
Ok, so the issue is related to the TCP socket communications side, not the
conversion or storage into the waveform.
Making the CPU really busy does not change anything. It neither changes
the location of the breaks nor the time/element for anything> 16.
When I make the string longer, the break moves up.
"3,..."
size 1024 duration: 1169 time/element: 1.1
size 2048 duration: 2116 time/element: 1.0
size 4096 duration: 43596 time/element: 10.6
size 8192 duration: 47498 time/element: 5.8
size 16384 duration: 53602 time/element: 3.3
size 32768 duration: 30096 time/element: 0.9
...
"3.14159265359,..."
size 256 duration: 677 time/element: 2.6
size 512 duration: 40791 time/element: 79.7
size 1024 duration: 41654 time/element: 40.7
size 2048 duration: 42928 time/element: 21.0
size 4096 duration: 7013 time/element: 1.7
Server and IOC run on the same PC. When I change from localhost to the
IP address, nothing changes. To use other mechanisms than TCP will take
some time to implement....
That implies that it's to do with sending the data over the TCP socket. I'd
say that at some point during the transmission the OS decides that the server
process has filled its transmit queue enough and it switches to the IOC
process to read some data out of the socket. Once that happens before the
server has queued up all of its data the OS has introduced 2 extra context
switches into the operation, the scheduler might be making one or both
processes wait a whole time-slice before they get to run again, so 20ms each
might be reasonable for that.
The interesting thing is that going all the way up to 1 million elements
doesn't trigger a second bump. Maybe you could try adding spaces as well to
see if there is another bump without increasing the number of elements
Also you could try making the server run as a real-time process. I'm not sure
how to actually do that, but I think it might help.
- Andrew