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

[Adrian Godwin]

If you have RS232 connections, won't you have one for each device ? Whereas
with GPIB, you'll (probably) only have one bus. The GPIB bus will arbitrate
and avoid both instruments talking at the same time (this might not be true
in talk-only mode since there's no target address involved) but it doesn't
provide two completely separate channels.


On Sun, Jan 17, 2016 at 1:01 PM, Magnus Danielson <
magnus at rubidium.dyndns.org> wrote:

> 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
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>