Hi Branden,
There are no known limits in Scream to the number of stations that it can handle, so I am surprised that you have found such a dramatic change in behaviour from adding a few stations.
Do you know how many stations you had before, which worked fine, and how many you added that caused the issues?
Can you please say what connection types you have to your stations (serial/UDP/TCP etc) ?
Because Scream imposes very few limitations in its design, there are occasionally ways that you can find the OS limits (memory, thread count, file handles, etc) that can cause adverse behaviour. To try to understand if you have found one of these, I need to know the above information.
If you can email your network topology and scream.ini config file to sup...@guralp.com, we can look into this in detail.
Best regards,
Murray McGowan
- Author of Scream.
ps. I don't know of a "SeedLink plugin for Scream" ?
pps. I will be at the IASPEI meeting in Bogota. All are welcome to drop in for a chat.
Do you know how many stations you had before, which worked fine, and how many you added that caused the issues?
Can you please say what connection types you have to your stations (serial/UDP/TCP etc) ?
ps. I don't know of a "SeedLink plugin for Scream" ?
Branden,
I think I see the problem here. If you look in the scream.ini file, the [NetServers] section is very large, and probably growing continuously.
This section is used internally by Scream to keep track of the sequence numbers from the various data sources that it receives data from. A data source is identified by the IP:Port combination.
You say "The new, fifteenth station does not appear in scream.ini because the data from this station are pushed to the Scream server."
I think this may be where the problem is. I can see that there are several IP addresses in the same range, and a large number of ports listed for each IP address. I'm guessing that this station is behind a NAT firewall, that is on a dynamic IP address? So, every time the IP address changes, your Scream "sees" this as a new server. Equally, each time the NAT firewall maps the data to a different port, Scream sees this as yet another client.
Each time Scream receives a network packet, it must look up the expected packet number from this list, which is now over 3500 entries.
To run a connection in this configuration, you need to change a few things.
1) use a hostname for the data source (e.g. dyndns)
2) Set Scream to pull from this hostname
3) use a port forward on the firewall at the source to ensure the port number is fixed.
To clear out this list of sequence numbers, you should
1) stop Scream
2) edit the INI file, and delete the entire [NetServers] section
3) re-start Scream.
If you don't fix the source of the problem, however, the list will grow again.
Alternatively, we do supply dedicated Network Appliance Modules (NAMs) which are designed for just the sort of network concentrator functionality that you are wanting, and can work with EAM-enabled equipment that is behind firewalls. This would replace your Scream PC, and offers more options for the data feed into Earthworm. It has seedlink support, and even an export_generic implementation, so you can go straight into EW. You can still use Scream for monitoring and SoH functions, as the NAM would act as a Scream server as well.
Murray.
--
--
You received this message because you are subscribed to the Google
Groups "Earthworm Community Forum" group.
To post to this group, send an email to earthwo...@googlegroups.com
To unsubscribe from this group, send an email to
earthworm_for...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/earthworm_forum?hl=en
---
You received this message because you are subscribed to the Google Groups "Earthworm Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to earthworm_for...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.