My second GNU/Linux receiver using a TBS-6925 V23 is now up and running.
Writing up the results so far on my little page (still a work in progress)
I came accross a question that might be of interest to the list. If nobody
can answer here, the GEO symposium might be the place to ask. At least
Rob Alblas will understand the question very well as he wrote "ecast_cfg"
a tool that deals with the problem under GNU/Linux. As usual I must
admit I never setup an EUMETCast receiver under Windows and hopefully
never will have to. That said even before I went into this TBS-6925 V23
adventure I studied the manuals of both routers SR1 and S300E. What hit
me was the difference GNU/Linux and (I think?) Windows is managing the
multicast traffic. At least from what I read back in January 2014 this
difference is also present between the two routers an might influence my
choice if (and only if) I get nowhere with the TBS-6925 PCIe V23 card.
The problem is this (and as stated I may be wrong on the Windows side):
Using a PCI, PCIe, or USB receiver the TelliCast client is listening at an
internal interface and does handle the multicast traffic very differently:
For every channel (within a certain PID) we have to setup one static multicast
route that is maintained by a daemon called "smcroute". Normally the whole
traffic is routed to the interface "dummy0" the TelliCast client is listening
at. This is started by scripts provided by EUMETSAT. Whatever channel the client
tc-recv is asking to subscribe or unsubscribe at runtime using IGMP is ignored
by "smcroute". Rob Alblas "ecast_cfg" solves the problem in a semi static way.
From what I (think to?) understand under Windows channels are subscribed
dynamically using IGMP. EUMETSAT in the trouble shooting guide even describes
a problem with "Coordinator lost" that has been tracked down to this behaviour.
Whether this is the case can easily be tested by commenting out all channels that
use PID 510 (that amounts to almost 50% of the traffic) in recv-channels.ini
(there must be no default * directory for unknown cannels/services though!). Of
course the EKU must also allow for those channels. The TelliCast client periodically
rereads the file recv-channels.ini and does subscribe or unsubscribe channels
(you do not have to reboot to do the test, but first backup recv-channels.ini).
If IGMP works the traffic on interface TelliCast is listening at should be
reduced dramatically without the channels within PID 510 (I am not talking about
filtering PID 510!). In GNU/Linux this has no impact on the interface "dummy0".
The router SR1
I did not find the word IGMP in the SR1 manual. It seem to me that this
piece does route everything within an allowed PID to the network. This is
pretty much like GNU/Linux but now the traffic goes over a real network.
We could possibly blank out the High Volume Service by PID but there might
be little choice for the rest. Maybe something like "ecast_cfg" will work?
Of course it has a GigaBit interface and does SNMP for parameter graphing.
The router S300E
Does mention in it's Manual full support for IGMP (EUMETSAT seems not to use it).
This might reduce the traffic on the network to what we really are interested in.
That is the way (I think?) Windows has managed the internal IP interface so far.
We might have to use switches with "IGMP snooping" (common) for best results ...
A 100Mbit NIC will do and instead of SNMP we can use CMCS for parameter graphing.
This command line tool was offered for GNU/Linux first but now also for Windows.
CMCS and it's manual can be downloaded here http://novra.com/support/#cmcs
I hope to start an interesting thread, have a nice evening