These are chat archives for got-lambda/expression

17th
Nov 2016
Magnus Therning
@magthe
Nov 17 2016 12:47
so, a test question for you, you find some explanation and the question itself here: http://lpaste.net/340457
All help is much appreciated
Marco Zocca
@ocramz
Nov 17 2016 12:57
@magthe I think COORD should be aware of the state of TUT
as in, TUT should like ping COORD when it has acquired the test data
possible?
what are the delays due to? network timeouts?
Magnus Therning
@magthe
Nov 17 2016 13:00
@ocramz, well, TUT is a part of the product, so it doesn't really know it's being tested
I'm guessing it's just scheduling, these are three separate processes
actually, I'm pretty sure it is scheduling, all procsesses run on the same machine and all network traffic is to/from 127.0.0.1
Marco Zocca
@ocramz
Nov 17 2016 13:04
if TUT can't signal back, perhaps delaying the execution of Step 2 is the only way
Magnus Therning
@magthe
Nov 17 2016 13:04
yes, I suspect it is... but then it all feels so arbitrary, "sleeping for half a second seems to work" sort of :(
Marco Zocca
@ocramz
Nov 17 2016 13:05
can you measure how are the delays distributed? to establish a sleep threshold that will guarantee a decent correctness
Magnus Therning
@magthe
Nov 17 2016 13:08
it's a bit more complicated than that, we run the tests as part of our CI, so they run in a docker instance, on a VM, that has its disk on NFS... there are SO many factors to consider so it'll have to be a finger-in-the-air at best I'm afraid
Marco Zocca
@ocramz
Nov 17 2016 13:10
ew
Magnus Therning
@magthe
Nov 17 2016 13:11
it's just so yuckie... and this ought to be a problem that's come up before in integration testing ;)
so I was hoping for some enlightenment from the wise people in here :)
Marco Zocca
@ocramz
Nov 17 2016 13:13
but surely you can install e.g. WireShark in the test container and record all interprocess traffic
ok I haven't used it in many years but I'm quite positive it should work
Magnus Therning
@magthe
Nov 17 2016 13:16
maybe not Wireshark, but I get what you mean... I'd have to monitor DBus, which is doable, but then I'd only see that the signals are sent out by MOCK, I don't actually see that TUT has received and acted on those signals yet
it would narrow down the window though :)
Marco Zocca
@ocramz
Nov 17 2016 13:18
but what is TUT? is it like a shiny black monolith on an asteroid many light years away? or does it have some measurable state?
maybe the CPU spikes a little when TUT starts working on the test data, maybe the container uses a bit more memory
or can you simply buffer the TCP traffic from TUT to something which can then relay it synchronously to COORD?
Marco Zocca
@ocramz
Nov 17 2016 13:26
"simply"
Magnus Therning
@magthe
Nov 17 2016 13:43
TUT is a process that listens for DBus signals, and then exposes the data in those signals on Modbus/TCP, nothing complicated at all
reading the registers via Modbus/TCP is to read the state of TUT
Marco Zocca
@ocramz
Nov 17 2016 13:43
yes the question is when to do it
Magnus Therning
@magthe
Nov 17 2016 13:45
yupp
I've added some CPU yielding and set the priority of COORD to be significantly lower than TUT & MOCK
if that doesn't work I'll have to add a way for TUT to signal the world that it has received a signal and acted on it
I'm just loath to add functionality purely for testing
Marco Zocca
@ocramz
Nov 17 2016 14:47
OR, you can just rewrite everything using distributed-process
"just"