UnderGround Forums
 

ITGround >> Network Gurus try to help me please


6/8/11 8:57 PM
Ignore | Quote | Vote Down | Vote Up
hiptosser
Send Private Message Add Comment To Profile

Member Since: 9/19/07
Posts: 2509
 
My problem:
out of sequence packets from a NOAA satellite transmission
the sat's data is going to a windows box. Don't have the specs for the NIC at the moment.
There is a working fix for redhat:
Hello everyone,

The issue which is causing the 1 and 2 frame packet drops from NOAAport for Linux kernels is/was this...

http://www.linuxinsight.com/proc_sys_net_ipv4_ipfrag_max_dist.html

It's a dynamic kernel tuning parameter for the network stack. Here's the
specifics:

: *"Redhat noticed in our latest test that we had a number of fragments
: dropped after timeout. The number lost matched almost exactly with the
: number of frames reported lost by acq_stats. They gave us a new kernel
: parameter to try modifying: net.ipv4.ipfrag_max_dist. The default value
: is 64. I increased it to 4096 per Redhat's suggestions and the lost
: frames reported by acq_stats immediately stopped."*

But wait...I learned this morning that there's a way to get even better results tuning this parameter!

Put this in your Linux system /etc/sysctl.conf file (or wherever it is located in your system):

net.ipv4.ipfrag_max_dist = 0

And then type this as user root:

sysctl -w net.ipv4.ipfrag_max_dist=0

THAT solves everything. Big or small, the packets get through!
I am not losing ANY packets now. ZERO! Yippee!

Credit for this fix goes to Raytheon, RedHat, and NOAA for their collaborative effort. Now, if you are using another OS, you may need to fine-tune this parameter. Set it to zero, or in some cases, you may need to set it to 8192 if zero doesn't work for you. 4096 wasn't good enough for my CentOS/RHEL 2.6.18 kernel.
I still dropped a few of the largest data chunks being sent across when it was set at 4096.

The DVB-S2 issue isn't completely over yet. They still need to raise the power back up another 5-6 dB from the bird (SES-1) to get it to where it was before. For testing purposes, it was OK with a 3.7 meter dish.
Here, have a look at what happened when a 55 dBZ cell producing 3/4" hail passed over and south of our dish, directly in the path of the satellite, just before 8Z (3 AM CDT) this morning (the data for today will disappear at 0Z this evening):

http://noaaport.admin.niu.edu:8025

Also...for those of you running npstats, which makes those neat graphs and charts, author Jose Nieves is coming out with a fix shortly so that the signal strength will be seen if it drops below 60%.

What is good about all of this happening is that the signal from NOAA is clean as a whistle. Interference, and any uplink issues which you could get away with under a DVB-S broadcast, is gone. I lost about 30 packets of data in 12 hours after changing the parameter above to 4096, but again, now it's zero. And I anticipate, barring thunderstorms, sun outages, etc...that many days I will have perfect reception, as will many of you.
And with 5 days until the end of the original dual illumination was scheduled...if they really had to or wanted to...NOAA could dump the DVB-S broadcast and switch over to the new one.

Finally, do NOT forget to update the firmware on your Novra S-300!
I repeat...that's a must-do. Your reception, and most importantly, having the unit crash with subpar or no reception depends on you upgrading that immediately. Click here, and go to the bottom of the page to get the file...

http://www.novra.com/Website/Novra_Support.html

Also, for you Unix junkies, download and install CMCS on that same page, so you can administer it remotely. You'll be glad you did...

Gilbert

*******************************************************************************
Gilbert Sebenste ********
(My opinions only!) ******
Staff Meteorologist, Northern Illinois University ****
E-mail: sebenste@weather.admin.niu.edu ***
web: http://weather.admin.niu.edu **
*******************************************************************************

I am kinda of at a stand still any suggestions will be greatly appreciated
6/8/11 8:57 PM
Ignore | Quote | Vote Down | Vote Up
hiptosser
Send Private Message Add Comment To Profile

Member Since: 9/19/07
Posts: 2510
oh and sorry for frat
6/9/11 1:45 PM
Ignore | Quote | Vote Down | Vote Up
hiptosser
Send Private Message Add Comment To Profile

Member Since: 9/19/07
Posts: 2514
No ideas guys ?
The problem I think is finding something that does the same thing in windows net.ipv4.ipfrag_max_dist = 0.
6/9/11 7:42 PM
Ignore | Quote | Vote Down | Vote Up
poober
4 The total sum of your votes up and votes down Send Private Message Add Comment To Profile

Member Since: 3/11/07
Posts: 1508
What OS? Win 7 and 2008 are different than 2003 when it comes to things like this. I'm not sure if this would be any help, but playing with the recieve window size/scaling might be similar to what they are talking about.

http://msdn.microsoft.com/en-us/library/ms819736.aspx

6/9/11 8:50 PM
Ignore | Quote | Vote Down | Vote Up
Ho Kogan
Send Private Message Add Comment To Profile

Member Since: 11/2/10
Posts: 323
I don't know if the Windows TCP/IP stack has an equivalent of ipfrag_max_dist.

Why is the actual problem occurring? Is it related to fragmented packets getting dropped because they're hitting the reassembly timeout threshold?

If so, there's a Windows TCP/IP parameter called IpReassemblyTimeout that you can modify.

"IpReassemblyTimeout REG_DWORD Number of seconds
Default: 60 seconds

Determines how long IP accepts fragments when attempting to reassemble a previously fragmented packet. That is, if a packet is fragmented, all of the fragments must make it to the destination within this time limit; otherwise, the fragments will be discarded and the packet will be lost.
"

See: http://support.microsoft.com/kb/102973

Reply Post

You must log in to post a reply. Click here to login.