[hpsdr] Heterodyne to Metis Throughput via multi-hop wireless link
Jeremy McDermond
mcdermj at xenotropic.com
Thu Jan 19 20:11:16 PST 2012
On Jan 19, 2012, at 4:08 PM, Mark Leone wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> As I mentioned in a previous post, I have Heterodyne connected to Metis via a two-hop wireless link. In this configuration, Heterodyne seems to work well at 48,000 sps. At either of the two higher rates, the audio is mostly unintelligible. This surprised me, as the theoretical bandwidth of the link (27 Mbps) is far above what should be required to handle a single Metis stream even at the highest sample rate. (The routers are each rated at 54 MBps, but one of them is splitting its bandwidth as it receives Metis packets and forwards them to the MacBook laptop).
802.11g hardly ever achieves anywhere near 54Mbps. That's a very theoretical number and is a major reason why everybody wanted 802.11n. It comes much much closer to theoretical maximums due to a better over the air protocol. Practical 802.11g data rates are more near 20Mbps. If you're splitting this because you're bringing the packets in and retransmitting both over the wireless, you're getting nearer 10Mbps. As you can see by the figures below, this could be congesting your network.
> I took a look at the Metis protocol description, and came up with a rough estimate of max throughput for each sample rate. I assumed one I&Q stream at the selected sample rate, with 24 bits/sample. I also factored in a band scope stream at 4096 sps with 16 bits per sample. I added 1.5% overhead for HPSDR protocol (based on header sizes, but ignoring padding), and 6% overhead for Ethernet/IP/TCP|UDP, which is a standard benchmark estimate (although perhaps it should be a bit higher for wifi Ethernet). Based on these assumptions, I get the throughput estimates shown below. I’ve also added a column indicating the actual bandwidth utilization measured by my router for each sample rate.
>
> Sample Rate Estimated Throughput rate Measured bandwidth (Mbps)
>
> 48,000 1.3 Mbps ~3 Mbps
>
> 96,000 2.5 Mbps ~4 Mbps
>
> 192,000 5.0 Mbps ~6 Mbps
Each Metis packet includes two HPSDR packets. Each HPSDR packet contains 63 full samples and is 512 bytes large. That means a Metis packet contains 126 samples. The Metis header is 8 bytes. That means:
Payload: 1024 bytes
Metis Header: 8 bytes
UDP Header: 8 bytes
IP Header: 12 bytes
----------------------------------------
Total: 1052 bytes
Since each packet contains 126 samples, that means that at 192ksps you'll need 1524 pps to attain that datarate. 1523 pps * 1052 bytes per packet = 1603248 bytes per second. That's 12825984 bits per second or 12.8 Mbps.
For 96k, that's 762pps, 801524 Bps and 6.4Mbps.
For 48k, that's 381pps, 400761 Bps and 3.2 Mbps.
> So the utilized bandwidth was twice the value expected at 48,000 sps, and significantly higher (but at a lower ratio) for the other sample rates. I’d like to know why the measured values are so much higher than the predicted values?
Not knowing how you're measuring the bandwidth, I can't tell you very much. I haven't measured bandwidth on Metis.
> Is there something wrong in my assumptions and/or calculations? I’d also like to know why the audio was unusable at the higher sample rates. Clearly the router is capable of higher bandwidth, so perhaps the buffer sizes need to be adjusted. However that doesn’t appear to be possible with Heterodyne; at least there is no preference setting for it.
There is no preference for input buffering because there is no input buffer. I used to have one but after some extensive testing and instrumentation, there was no need for it. On every machine I've worked with, the problem hasn't been overrun, but underrun. Underrun in the entire architecture isn't solved very well by just adding a huge buffer. What ends up happening is the machine just falls further and further behind and the buffer fills. Not to mention that the thing creeps more and more out of real time. This doesn't work well for a transceiver where people expect that you'll respond to their transmissions in a timely fashion.
> I also looked inside the app bundle, and I see only plist files for setting defaults of the properties that can be configured in the UI.
There are absolutely no secret plist settings. What you see in the UI is what you get. The settings are purposely few. The intent is explicitly not to show every setting, knob and dial for every edge case possible.
> Another curious thing is that the router showed a packet stream at ~2.8Mbps from the MacBook to Metis whenever Heterodyne was operating. Sounds like audio incoming to Metis, but I never had Heterodyne in transmit mode because there doesn’t appear to be a transmit mode.
A full datastream is always flowing to Metis, per protocol. When it's not transmitting, the output is zeroed by setting all samples to zero, and the MOX bit in the header is set to false. The protocol will use the same exact bandwidth whether you're listening or transmitting.
> I see some preferences related to TX, but no controls to actually transmit.
Transmit is only currently supported on SSB by using the microphone input on Penelope. No transmit is supported from CoreAudio devices on the computer itself, and there's no "tune" or "MOX" controls. CW is not supported.
> Mark – K4XML
--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com
1327032676.0
More information about the Hpsdr
mailing list