Electronics > Projects, Designs, and Technical Stuff
syncronise multiple ADCs over an Ethernet network?
<< < (4/9) > >>
rstofer:

--- Quote from: Yansi on December 09, 2019, 04:31:03 pm ---
--- Quote from: rstofer on December 09, 2019, 04:00:07 pm ---
--- Quote from: FenTiger on December 09, 2019, 08:40:19 am ---Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

--- End quote ---

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.

--- End quote ---

TCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.

--- End quote ---

If you let the protocol sort out the packets, they will be presented in order but there may be a delay while the sender gets notified of and resends missed packets.  In terms of ethernet itself, you can just grab the raw packet and deal with it but you can count on data appearing out of order.  It pays to read the documentation because one stack, uIP, only allows one packet in flight.  This doesn't help throughput.

I wouldn't use UDP for much of anything where I cared about the data.  Oddly, there are a lot of applications where dropping a packet doesn't really matter much.
Yansi:

--- Quote from: rstofer on December 09, 2019, 04:46:28 pm ---
--- Quote from: Yansi on December 09, 2019, 04:31:03 pm ---
--- Quote from: rstofer on December 09, 2019, 04:00:07 pm ---
--- Quote from: FenTiger on December 09, 2019, 08:40:19 am ---Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

--- End quote ---

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.

--- End quote ---

TCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.

--- End quote ---

If you let the protocol sort out the packets, they will be presented in order but there may be a delay while the sender gets notified of and resends missed packets.  In terms of ethernet itself, you can just grab the raw packet and deal with it but you can count on data appearing out of order.  It pays to read the documentation because one stack, uIP, only allows one packet in flight.  This doesn't help throughput.

I wouldn't use UDP for much of anything where I cared about the data.  Oddly, there are a lot of applications where dropping a packet doesn't really matter much.

--- End quote ---

No, you seem to get quite confused. TCP stack, or to say the TCP protocol, is what deals with packet loss and reordering for you. If you talk about TCP, these function are assumed. (Or just I don't understand your wording. There is no such "if you let it". TCP does it by itself)

UDP is what IS used for transporting real time media.  As exactly this is where you trade low latency for an occasional dropout.
mansaxel:

--- Quote from: Yansi on December 09, 2019, 04:52:44 pm ---
No, you seem to get quite confused. TCP stack, or to say the TCP protocol, is what deals with packet loss and reordering for you. If you talk about TCP, these function are assumed. (Or just I don't understand your wording. There is no such "if you let it". TCP does it by itself)

UDP is what IS used for transporting real time media.  As exactly this is where you trade low latency for an occasional dropout.

--- End quote ---

There are, and here we're off on a tangent wrt the original subject, but there is something of value in here, so bear with me. If we're going to continue using the RTP model to discuss our sample transmission system, there are bits and pieces in place to handle packet reordering, to an extent.

When packets arrive, they are put in a buffer. You need to buffer ptime as a minumum; you in addition to that also need to buffer  PDVmax, that is the max packet delay variation you have.  When packets have arrived in the buffer, they are examined for time stamp and / or sequence number, depending whether you're doing AES67 or simply EBU Tech 3326, to take two examples. If a sequence of packets can be reassembled without gaps, the samples are played out. If a packet is missing, the time lost is known and skipped, more or less audibly, to keep the pace. A late packet is the most common case, where a packet arrives so late that it can't be played back but must be skipped. Longer reassembly buffers will help, but at the same time of course increase latency.

--- Quote from: mansaxel ---    Today's story from the trenches: We're making a TV show of a little party in the town hall here tomorrow evening, with a bunch of scientists and a king, his family, plus lots of other people. We have two different AES 67 sender boxes for two microphones that are going to be used close together for interviews, and, we've normally run the receiving end in "syntonized" mode, where we trust the sample frequency to be right but not bother with the absolute time stamp, instead playing the sound back as soon as it arrives. That does not work well with several senders transmitting the same sound; there will be time delay comb filters and whatnot.  Adjusting the receive end to "synchronized" mode fixed the problem instantly: Now the receiver looks for the departure time and makes sure to playback the sounds synchronized according to time stamp and not as soon as possible.

And yes, a little bandwidth brag is in order:

--- Code: ---sto-remhub-ro1>sh inte po49
Port-Channel49 is up, line protocol is up (connected)
  Hardware is Port-Channel, address is 985d.8299.da0e
  Description: REMOTE-CONNECTION
  Ethernet MTU 9214 bytes , BW 200000000 kbit
  Full-duplex, 200Gb/s
  Active members in this channel: 2
  ... Ethernet49/1 , Full-duplex, 100Gb/s
  ... Ethernet50/1 , Full-duplex, 100Gb/s

--- End code ---
)
 8)

--- End quote ---

So, to get back on-topic; we can reconstruct the sample train in several ways, both using UDP and TCP, and as usual, there will be tradeoffs with both approaches, and none will be as straightforward as synchronous serial transmission is. But they have so many other advantages that going back to serial-only is rarely considered.
max_torque:
wow, that's a lot ot take in!  Thanks all!  I shall read and "Google" myself silly for a bit   :-DD


It's looking like the phaff from having a seperate hardware clock line to each sample might actually be a lot easier than trying to do something clever over ethernet!  Each slave could easily have a "clock in" and  "clock out" BMC connector and i could just daisy chain the clock down the line (the minor time delays due to different lengths of clock line shouldn't be an issue at just 10 KHz sampling)

mansaxel:

--- Quote from: max_torque on December 09, 2019, 09:39:44 pm ---wow, that's a lot ot take in!  Thanks all!  I shall read and "Google" myself silly for a bit   :-DD


--- End quote ---
It indeed is! Especially when starting anew from scratch. Once you're in the middle of it, it sort of becomes natural.


--- Quote from: max_torque on December 09, 2019, 09:39:44 pm ---It's looking like the phaff from having a separate hardware clock line to each sample might actually be a lot easier than trying to do something clever over ethernet!  Each slave could easily have a "clock in" and  "clock out" BMC connector and i could just daisy chain the clock down the line (the minor time delays due to different lengths of clock line shouldn't be an issue at just 10 KHz sampling)

--- End quote ---

The 200Gbit link i bragged about above is perhaps 15 kilometers, mostly from not going the straight route across town (there are two dark fibre pairs routed separate paths to keep redundancy against fiber cuts). Stringing along a hardware clock is suddenly less simple, not that we haven't wished we could a few times when PTP wasn't playing along...  :-DD

I'd be very cautious to take the plunge if it is a lab with everything within, say, 100 metres cable radius. Anything above that, separate hardware for sync transmission becomes very messy and expensive, and an integrated approach should be considered.

/Måns, did this trick over 600km WDM last week.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod