On Sat, 2010-12-18 at 14:17 -0600, Gerald Youngblood wrote: > Ken, > > Actually, 800 Mbps would not buy us anything because 400 Mbps is plenty fast > for our application. FireWire can run a lot of channels on 400 Mbps.
Firewire pipes are certainly big enough, no matter what version. But with all the concern about latency, I'm wondering how much the Firewire part of the data path contributes to the overall delay. While 400 or 800 Mbps seems plenty big enough to carry the data, Firewire is a bit-serial protocol, which means that the latency through the system depends on the data rate - it takes twice as long to send a bit at 400 than at 800, and since you usually send bytes, frames, packets, or something larger than a bit, the serialization delays can add up. Also, IIRC, Firewire 400 is half-duplex, while 800 is full-duplex, so for any data processing that involves handshakes, it would seem that latency through a 400-based path might be much higher than the latency through an 800-based path, especially if "turning the line around" requires action by some high-level software, and waiting for a "long" data transmission in the other direction to finish - e.g., during a CW operation trying to do full break-in. I don't have any idea what the framing or handshaking protocols look like across the Firewire in a Flex configuration, but I'm wondering if Firewire 800 would help with problems like the latency in CW. Or perhaps the effect from the Firewire delay is in the noise compared to FFT processing etc. 73, /Jack _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using beta versions of the software.
