Hi JDB and all,
> I've never written a single line of C++ in my life. As for the
> ReceiveData() function, that line can be directly replaced with your
> recvfrom() call (I just was too lazy too look up recvfrom() when I
> wrote that example).
Well, if you care to write the full code you will find that
this statement is not quite what it looks like.
ReceiveData returns a pointer. recvfrom fills data into a buffer that
the user passes to the function. It does make a difference.
> I don't see that having a header in front of the
> package needs more copy calls than one after the package;
Just compare the code I supplied with the code you will have to write
to make ReceiveData operational.
> even if it
> did, it matters very little on modern CPUs (packets this size will
> remain entirely within the CPU cache).
Linrad is intended to run on elderly computers and it is also
intended to run at much higher bandwidths on modern ones.
You suggest that the data is put into a buffer to which a
pointer is returned by ReceiveData. The next step would be to
store the payload into a circular buffer. This will cause the data
to become written into memory twice. Processing of the data is
in another thread that require hundreds of packages in the circular
buffer. It will fetch its input from memory because other
threads have been using the cash in the meantime.
> Zero-copy architectures make
> sense for hi-speed packet switching on slow computers; as soon as you
> add any processing on the data, that single extra copy gets lost in
> the noise. Cache line/block alignment is much more important for
> performance.
Actually this is not in agreement with my observations. It does depend
on how efficcien "processing" is done.
> I was assuming that the multicast connection would be used for
> distributing raw data only. Re-reading your earlier posts it looks
> like you want to be able to send both raw *and* cooked (processed)
> data. Why ? Do you expect the slaves to be much slower than the
> master ?
Yes.
The most demanding task is the full bandwidth, full dynamic
range FFT. It would be identical in all computers and it does
not make any sense to do it in more than one computer.
> Do you want to have an exact, synchronized display on
> multiple machines ?
This would be the case also if raw data were used.
> Looking at other network protocols (especially streaming), it has
> historically been a bad idea to combine multiple modes into one
> protocol, for reasons of maintainability, performance and clarity.
> Linrad is your code, and it's completely up to you, but might I
> suggest you consider either splitting the transmission modes in raw
> and cooked, or (better) multicasting only raw, unprocessed data and
> sending all filter parameters over a separate channel ?
???????????
There are two classes of multicasted data that Linrad will send.
1) Time domain data.
2) Frequency domain data.
Raw data is a special and pretty un-interesting case. I am providing
it because it might be useful for experimentation that others may
want to do. The normal operating mode will be "cooked data". It might
be in the time domain or it might be in the frequency domain.
The "innocent" slave does not have to know that a data stream is
"cooked". It can be processed as if it were raw data, but a clever
slave can make use of complex information that it might want to
as for. If you want to compute the noise floor power density
you want to know what percentage of samples that were blanked
out because of noise pulses for example. Normally one would not care
at all.
> > > [about an ADC-to-Ethernet]
> >Probably it would be better to connect it to a socket on a
> >dedicated ethernet port on one computer, the one which has
> >the controls for the radio hardware connected to this soundcard.
> >The master wants 100% reliable data because I assume you do not
> >want to put the master system clock on the audio-to-Ethernet
> >converter.
>
> Why not ? It has a GPS-controlled OCXO to synchronize all sampling
> clocks and to keep time, isn't that sufficient ?
Oooh! Then it would be a suitable master clock - you would just
have to make it count 24 hours and provide a way to set it correctly.
> Pretty much what I described above: header with header length, data
> length, number of channels, sample size, sample rate, timestamp and a
> few descriptive fields (with a version field, so that -- if truly
> necessary -- upgrades are possible). Nothing that isn't strictly
> required: less is more.
>
> It's what everybody else does. I know that that's not much of an
> argument ('50 million Elvis fans can't be wrong'), but in 15 years of
> working on network protocols, this is pretty much the only way that
> I've seen working reliably for successful sampled AV or radio
> projects (I've seen a similar system used on an antenna array for
> MIMO trials). Conversely, I have never ever seen a combined
> raw/cooked protocol that worked, or better: that remained working. Or
> it evolved into something like WAV: a historical accident that
> everyone loves to hate.
OK. Some day you will see an exception. Linrad needs a protocol
for cooked data and raw data is just an add-on which I will do
in the same protocol. I will take your advice to not use
floats when not needed and I will add a time stamp.
By the way, when reading with recvfrom I can ask for a very large
record. Then the function will return the record size and I can
put the header as the last byte equally well as the first byte.
On the other hand, If I read just two bytes to get the record size,
I can not read again to get the rest of the same packet. It means that
the information about the packet length is used just once
when setting up the receive routine. There is no need to get it from
the header....
73
Leif / SM5BSZ
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
