[time-nuts] Timelab, two SR620s and losing samples
magnus at rubidium.dyndns.org
Sun Jan 17 08:01:27 EST 2016
On 01/17/2016 01:45 PM, Poul-Henning Kamp wrote:
> In message <569B8B2E.5070604 at rubidium.dyndns.org>, Magnus Danielson writes:
>>>> I think you should develop that line of thought, to detail why it helps
>>>> on GPIB and why not on serial.
>>> It's really very simple: RS-232 sends blind, you don't even need to
>>> know if there is a receiver or what it does. If the receiver cannot
>>> keep op, data is simply lost.
>>> GPIB handshakes every byte, so the actions of the receiving end affects
>>> the transmitting end - in particular if the receiver cannot keep up.
>> OK, you where thinking about the flow-control.
>> You can have RS-232 wired up to do flow-control (hardware-flow-control),
> But the important point is you don't have to do that, all you need
> is two wires: GND-GND and TXD->RXD
> With GPIB that option does not exist, sender and receiver are always
> in lock-step.
> Therefore, talk-only mode is a big advantage in terms of decoupling
> on RS-232 and makes almost no difference on GPIB.
If we can assume the consumption is fast enough to keep track, yes.
If it's not, flow control for this situation helps the border case
somewhat, but if you are too slow, you are screwed anyway.
In the case that Attila describes, the flow-control helps over the
various borders, especially as scheduling plays tricks with us. Running
virtual applications like that does not help to get a grip of control
over how data is transfered and when. If it where only to get it
straight into an app really talking to the serial ports, sure, but I do
not trust the virtualization to handle it all to well.
Not that hardware flow-control would in itself help much, but anyway.
Regardless, if the TimeLab needs to send commands back to the counter
over the virtualization border, then getting things scheduled properly
in time isn't really guaranteed.
More information about the time-nuts