[time-nuts] Timelab, two SR620s and losing samples

[Magnus Danielson]

Poul-Henning,

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.

Cheers,
Magnus