Hughes DW7700 versus HN 9000 series problem resolution?

[thibodet]

We currently have a remote site using the Hughes Net DW7700 satellite system to provide internet connectivity. The system is used to send UDP packets from the distant end to several sites in the states. We monitor the distant end with network software (OP Manager), using the ping to monitor connectivity of an 1841 router and SNMP to monitor router specific characteristics. We use very little of the available bandwidth. We also connect remotely from the states to a processor on the remote end via the satellite shot. The connection is a TCP connection. Using the ping and tracert command, we have noticed a significant amount of delay on the last hop. This is the connection from the earth station to the satellite to the remote end. This delay typically anywhere from 900 msec to 2500 msec is preventing us from connecting to the remote processor via TCP connection. The connection times out. The SNMP feature of the OP Manger also times out. On a few occasions early in the morning when the delay was approximately 800 msec we had partial SNMP capability. Is the HN9000 series system susceptible to the same delays using the DW7700? We are looking at the KA band instead of the KU band on the HN9000 system. We would also go with the 4 watt transmitter in stead of the 2 watt. This is an expensive option to try just to see if the delay is reduced enough to allow a TCP connection and SNMP capability. Hughes has not been able to provide us with concrete information. Any experts that can provide the answers would greatly be appreciated.

[wad]

We currently have a remote site using the Hughes Net DW7700 satellite system to provide internet connectivity. The system is used to send UDP packets from the distant end to several sites in the states. We monitor the distant end with network software (OP Manager), using the ping to monitor connectivity of an 1841 router and SNMP to monitor router specific characteristics. We use very little of the available bandwidth. We also connect remotely from the states to a processor on the remote end via the satellite shot. The connection is a TCP connection. Using the ping and tracert command, we have noticed a significant amount of delay on the last hop. This is the connection from the earth station to the satellite to the remote end. This delay typically anywhere from 900 msec to 2500 msec is preventing us from connecting to the remote processor via TCP connection. The connection times out. The SNMP feature of the OP Manger also times out. On a few occasions early in the morning when the delay was approximately 800 msec we had partial SNMP capability. Is the HN9000 series system susceptible to the same delays using the DW7700? We are looking at the KA band instead of the KU band on the HN9000 system. We would also go with the 4 watt transmitter in stead of the 2 watt. This is an expensive option to try just to see if the delay is reduced enough to allow a TCP connection and SNMP capability. Hughes has not been able to provide us with concrete information. Any experts that can provide the answers would greatly be appreciated.

alot of us in here are techs.....as in we make what you ordered work, weather it be 6k, 7k, 9k, 1w, 2w, 4w, 10w, whatever, at this were great! what your asking, at least to me, is something that would need to be answered by an engineer at hns, not just the salesperson at the other end of your call.

[CommCtr]

What you are reporting is a wide range of delay times through the satellite link. If you took many tests and graphed the delay vs. time, you may find the delay is less between late night and early morning. If this is the case, you are on an over loaded transponder. If you are not paying for the top level of service, try upgrading to see if you get some priority for your data.

Remember, they only offer service "up to" a certain speed. There is no guarantee on the low end or what typical results might be. The screen shot attached is download speed tests as a function of time taken over four weeks time. We were paying for the lowest package.

[bajadudes]

satellite delay is an unavoidable phenomena. However ping times on most consumer level and even small office packages with any provider are going to vary tremendously depending on how congested the network is at any given moment.

The only way to get consistent ping times in the 650 - under 800 millisec range is to pay for a low contention commercial service with guaranteed service levels and minimum assured speeds.

The only company that I know of that will give a minimum assured speed and even guarantee average network speeds is Spacenet. And by guarantee I mean they will refund your money if they do not meet the targets for your particular plan.

Their performance series plan guarantees average network speeds of 80% of rated. if it falls between 70 - 80 they refund 10%, between 60 - 70 refund 20%, between 50 - 60% refund 30%. If it falls below 50% of rated you get a full refund.
Contention ratio on that plan is 10 to 1.

by contrast consumer and small office plans with Starband, HN and WB run about 125 to one

If anyone knows of any other company that does this please let us know.

[wad]

What you are reporting is a wide range of delay times through the satellite link. If you took many tests and graphed the delay vs. time, you may find the delay is less between late night and early morning. If this is the case, you are on an over loaded transponder. If you are not paying for the top level of service, try upgrading to see if you get some priority for your data.

Remember, they only offer service "up to" a certain speed. There is no guarantee on the low end or what typical results might be. The screen shot attached is download speed tests as a function of time taken over four weeks time. We were paying for the lowest package.

yes, but this fella has a dw7700, enterprise modem. his service plan offerings are almost completely different that what is offered to the average consumer. also, i could almost guarantee (without actually looking it up in my "stuff") that the frequency he is on does not have any "non enterprise" traffic on it. so i would again have to say that hns engineering would be the only people to help him out.

[bajadudes]

yes, but this fella has a dw7700, enterprise modem. his service plan offerings are almost completely different that what is offered to the average consumer. also, i could almost guarantee (without actually looking it up in my "stuff") that the frequency he is on does not have any "non enterprise" traffic on it. so i would again have to say that hns engineering would be the only people to help him out.

Do those offerings include guaranteed service level agreements and minimum assured speeds?

Clean consistent ping times are only going to come from low contention service offerings. Even if there are no "non enterprise customers" on his transponder, if there is a lot of traffic, ping times will be jittery.

Of course there is also the possibility the equipment or install might not be up to par. Someone with more HN experience should talk them through checking the number of failed transmissions, what rate code he is achieving, does he fail his assigned rate code and get bumped down to a lower rate code, stuff like that. Hopefully HN TS would do that but we all know that sometimes TS overlooks serious troubleshooting...and HN is not the only company deficient in that regard. that's why it's a really good idea to buy from an experienced dealer that knows the equipment inside out and will back you up with TS when you have issues.

[wad]

Do those offerings include guaranteed service level agreements and minimum assured speeds?

Clean consistent ping times are only going to come from low contention service offerings. Even if there are no "non enterprise customers" on his transponder, if there is a lot of traffic, ping times will be jittery.

Of course there is also the possibility the equipment or install might not be up to par. Someone with more HN experience should talk them through checking the number of failed transmissions, what rate code he is achieving, does he fail his assigned rate code and get bumped down to a lower rate code, stuff like that. Hopefully HN TS would do that but we all know that sometimes TS overlooks serious troubleshooting...and HN is not the only company deficient in that regard. that's why it's a really good idea to buy from an experienced dealer that knows the equipment inside out and will back you up with TS when you have issues.

i would certainly assume that there is some kind of guaranteed level of service. i dont know for a fact, but considering what enterprise pays for service vs. consumer........but being an enterprise cx, the only people that should be "messing" with the equipment, should be tech support, besides the cx. in 8 yrs, ive obviously never dealt with enterprise CUSTOMER support. but again, for what they are paying, i would assume, that it would be at an appropriate level of support.

[bajadudes]

Well based on the first post, for enterprise service, their ping times suck so either the transponder or the gateway is overloaded or there is an ODU equipment issue.

[grohgreg]

I don't have an enterprise connection, yet my PING times are pretty consistently in the 700ms range. Before any complicated solutions are pursued, I think packet loss should be ruled out. If the distant terminal isn't unmanned (or if you can initiate remote testing) I'd recommend starting with a test string of 100 PING requests of a 3000ms duration. Do this several times a day, particularly during those times when you've experienced difficulties.

If you can narrow it down to packet loss, it could be as simple a matter as peaking up the pointing angles, or cleaning/tightening some connectors. Wouldn't hurt to monitor the transmission errors either (NACK/(ACK+NACK)*100=transmission error %. Above 5% could point to a failing BUC.

Can you remotely view the hourly Diagnostics Summary?

//greg//

[wad]

I don't have an enterprise connection, yet my PING times are pretty consistently in the 700ms range. Before any complicated solutions are pursued, I think packet loss should be ruled out. If the distant terminal isn't unmanned (or if you can initiate remote testing) I'd recommend starting with a test string of 100 PING requests of a 3000ms duration. Do this several times a day, particularly during those times when you've experienced difficulties.

If you can narrow it down to packet loss, it could be as simple a matter as peaking up the pointing angles, or cleaning/tightening some connectors. Wouldn't hurt to monitor the transmission errors either (NACK/(ACK+NACK)*100=transmission error %. Above 5% could point to a failing BUC.

Can you remotely view the hourly Diagnostics Summary?

//greg//

anything above 1% loss is not to spec. usually a result of improper/lack of grounding, or just a whooped transmitter.