I found a better speed test for satellite internet

[grohgreg]

Naw, this is a waste of time. I'm done here.

//greg//

 

[tobifelinis]

Ok something else that may be throwing glitches in the test.

My current Ip is 97.73.68.124.

but look i can make the test show different. These two test were made just minutes apart. But one has Turbo page enabled and one has it off.

The first one shows my current IP.

The second one shows the proxy server at the NOC. It thinks my IP is 97.73.64.145

And my tps Ip has changed this many times today.

Well the chart won't paste here. But it is ten times already.

 

[Bandwidth]

Did youchange something on the Route Performance test? Yesterday it was showing the NOC firewall and today it does not but is showing something that i make as the proxy server.

Nope but that's an interesting twist. No changes are being made to the tests currently on the site with the exception I changed the voip codec. By the weekend there will be a new menu option called satellite tools and those tests will be custom just for you guys.

 

[Bandwidth]

Ok something else that may be throwing glitches in the test.

My current Ip is 97.73.68.124.

but look i can make the test show different. These two test were made just minutes apart. But one has Turbo page enabled and one has it off.

The first one shows my current IP.

The second one shows the proxy server at the NOC. It thinks my IP is 97.73.64.145

And my tps Ip has changed this many times today.

Well the chart won't paste here. But it is ten times already.

The portion of PEP that Hughes calls Turbopage is nothing more than a prefetch technology based on what little I know about it so I can't think of any reason why your route would change significantly. PEP also is responsible for several other network management functions but for this discussion we'll limit it to what you described above. Maybe an actual expert in this area could answer that question.

I want to play a little late tonight with the information you provided. One thing, we didn't change any parameters on the trace function at all.

 

[Bandwidth]

Here's the skype data I was able to scrounge

The codec is named SILK. Compared to its predecessor, SVOPC, the new codec gives the same or better audio response at half the bit-rate for wideband, and a super wideband mode. SVOPC is a 16kHz sample rate, 8kHz audio bandwidth. The new codec has that mode as well, but it also has a 24 kHz sample rate, 12 kHz audio bandwidth mode. Skype also supports G.729.

My question to everyone here is who has attempted to use skype, on what bird and what were the results (latency "delay" to be another discussion).

Next question is what other similar products have been used and what were the results? Reason I'm asking is we can make custom tests for each product and then you can decide which solution you might go with.

Nobody said this would be a perfect conversation. It's prob be as bad or slightly worse than old ship to shore (for those of us who remember such).
But when you're in a jam and you need phone or communication it's a blessing.

 

[Bandwidth]

Finishing up the Satellite based tests tonight and tomorrow. You should be able to test them starting VERY late tonight.

 

[bwporker]

Hi

I'll be in Colorado from May 27 to June 1 and can't wait to test the new tools on wildblue. I never expected your site to react so fast or even at all so thanks for noticing and all I can say is it so very cool of you to take so much heat over stupid me. I see the tcp quality test is running now under the satellite tests icon, can we use it now?

 

[tobifelinis]

Well I ran all of the new satellite test. Can't tell if they are better or worse than other test. They sure are pretty.

Here is the trace route thingy test. It sure would be confusing to someone not familiar with Hughes and the way they do things.

The chart and map have my path going back and forth cross the US which is not the way it really is. My NOC is in Las Vegas and thats where all of the last four or 5 Ip's are. But it indicates that it goes back to Va and then to German Town.

Now I and most knowable Hughes users know that ain't true.

It happens because Hughes does not hesitate to move server Ip's where ever they need or want them and they don't bother to change the designated location. Don't know if they are just lazy or do it on purpose just to confuse the issue.

 

[Bandwidth]

Ok something else that may be throwing glitches in the test.

My current Ip is 97.73.68.124.

but look i can make the test show different. These two test were made just minutes apart. But one has Turbo page enabled and one has it off.

The first one shows my current IP.

The second one shows the proxy server at the NOC. It thinks my IP is 97.73.64.145

And my tps Ip has changed this many times today.

Well the chart won't paste here. But it is ten times already.

The satellite configured route test is now working. I'm curious to see how it handles satellite now. Unsure how many if any have tested it so far so feel free.

 

[Bandwidth]

Well I ran all of the new satellite test. Can't tell if they are better or worse than other test. They sure are pretty.

Here is the trace route thingy test. It sure would be confusing to someone not familiar with Hughes and the way they do things.

The chart and map have my path going back and forth cross the US which is not the way it really is. My NOC is in Las Vegas and thats where all of the last four or 5 Ip's are. But it indicates that it goes back to Va and then to German Town.

Now I and most knowable Hughes users know that ain't true.

It happens because Hughes does not hesitate to move server Ip's where ever they need or want them and they don't bother to change the designated location. Don't know if they are just lazy or do it on purpose just to confuse the issue.

Actually routing is many times will change. I'm assuming you are talking about PRIOR to satellite hop. Traffic management will route as needed to keep loads at a respectable level so it's wouldn't surprise me at all that they change. The company I work for may change routing several times per day depending on a number of factors, in our case it's whatever keeps service level at acceptable levels.

 

[grohgreg]

I'm assuming you are talking about after the satellite hop.

I wasn't going to waste any more time on this, but I think Tobi deserves a little help in deciphering your spin.

You claim to be a NAT expert, but I'm not seeing it. The ISPGeeks trace never even GETS as far as the satellite hop. Based upon what he posted, it terminates at his NAT. You're simply tracing the route from YOUR (test) server to Tobi's NAT server. All I saw was terrestrial numbers. If his satellite hop was actually tested, the associated lag would add something in excess of an additional 250ms (45,000 mile path plus mechanical delays). But you can't do that, because Tobi himself doesn't actually HAVE an IP address.

I thought I could extend an olive branch by running a few Sam Spade tests (over my Hughes connection) to your test server, demonstrating with some graphics what the entire path looks like. But you've apparently set 174.34.146.20 not to respond.

FWIW, the inroute speed disparity between the other two (satellite) tests is even worse now. Two out of three attempts at the Speed/Cap test failed, and the three TCP tests seemed to think I was connected via dialup

//greg//

 

[Bandwidth]

You still don't get it. Your trace never GETS as far as the satellite hop. It terminates at the NAT server. You're tracing the route from YOUR (test) server to Tobi's NAT server - only. Your trace stops there. If his satellite hop was actually tested, the associated lag would add something in excess of an additional 250ms (45,000 mile path plus mechanical delays).

I intended to do you a favor and Spade from me to your test server, demonstrating what the entire path looks like. But you've apparently set 174.34.146.20 not to respond.

FWIW, the inroute speed disparity between the other two tests is even worse now. Two out of three attempts at the Speed/Cap test failed, and the three TCP tests seemed to think I was connected via dialup

//greg//

Ah yes - in his true combative form "Greg" speaks. My apologies for making a mistake, I meant PRIOR to and this has now been corrected. Still looking for that Holy Grail slip up eh Greg. Get over yourself Greg and why not participate in a way that people won't think you are an a$$. So much for "I'm done..this is a waste of time".

 

[grohgreg]

It was my intent to protect Tobi from the spin. But I'll ignore the insults and move right along here. Just so we're clear for the world to see here - you're saying that I'm wrong and your tests are in fact accurate? Would it be too much to ask that you address the actual specifics of my last post?
//greg//

 

[Bandwidth]

I thought I could extend an olive branch by running a few Sam Spade tests (over my Hughes connection) to your test server, demonstrating with some graphics what the entire path looks like. But you've apparently set 174.34.146.20 not to respond.

FWIW, the inroute speed disparity between the other two (satellite) tests is even worse now. Two out of three attempts at the Speed/Cap test failed, and the three TCP tests seemed to think I was connected via dialup

//greg//

Feel free to use 174.34.146.18 to run your test, they go to the same box. YOU seem to not get it. The TCP test measures connection quality only and the connections ability to maintain a steady stream of data while engaged in a SINGLE TCP SESSION. It does provide a "basic" measurement of expected bandwidth but can't be relied upon for that ***we clearly state this*** and exactly what test to use for available bandwidth testing which btw is the SPEED/CAP Test. That's all it does. Why not read the instructions below the test that CLEARLY explain this.

On flip side the Speed/Cap Test measures your bandwidth capacity, takes into account acceleration and caching and such and should be used like a conventional speed test (but far more accurate).

Now what part did you not understand Greg?

 

[Bandwidth]

It was my intent to protect Tobi from the spin. But I'll ignore the insults and move right along here. Just so we're clear for the world to see here - you're saying that I'm wrong and your tests are in fact accurate? Would it be too much to ask that you address the actual specifics of my last post?
//greg//

Tobi can protect himself and I'm sure he can speak for himself. Nobody was misleading him anyway. I made a simple mistake and corrected it (it didn't take you long at all to make it an issue now did it Greg).

 

[grohgreg]

Ok - if that's really how you want to play this. Yours is the reputation at stake for looking like a jerk - not mine

//greg//

 

[Bandwidth]

Greg did you come back to offer constructive feedback or continue with nonsense? I'm not going to tolerate you polluting this thread with your nonsense any longer. You have single handedly have made this thread almost toxic for whatever reason and I'm done with you (we've contact the site admin).

A considerable amount of time was spent this week trying to accommodate satellite based users (something we had not even considered prior to this thread), we certainly appreciate the feedback from anyone so any improvements can be made and that includes you Greg but I'm not about to let you dominate this thread as you have done in the past.

 

[grohgreg]

I'm not about to let you dominate this thread as you have done in the past.

Interesting claim, considering your membership started a week ago. You may feel that feigned outrage works, but I can't see where it's otherwise supporting any attempts to explain your work.

Nonetheless, I guess since both 174.34.146.18 and 174.34.146.20 are in Atlanta (and you're in Florida?), a trace to any responding server will demonstrate the same thing. In the graphic below, the OSRI is my router. The "no response" is from my modem (set that way on purpose). Note the long first hop is from my modem to my Hughes NOC. THAT sir, is the satellite hop. After returning to earth, the trace returns sorta level out like those displayed by your own test. The one that doesn't include the satellite hop.

But when I attempted to run it in the reverse direction, your site now responds with "Not Licensed for 174.34.146.18". One possible explanation is that you have it down again for some more "tweaking".

Who's playing games now?

//greg//

 

[Bandwidth]

Interesting claim, considering your membership started a week ago. You may feel that feigned outrage works, but I can't see where it's otherwise supporting any attempts to explain your work.

Nonetheless, I guess since both 174.34.146.18 and 174.34.146.20 are in Atlanta (and you're in Florida?), a trace to any responding server will demonstrate the same thing. In the graphic below, the OSRI is my router. The "no response" is from my modem (set that way on purpose). Note the long first hop is from my modem to my Hughes NOC. THAT sir, is the satellite hop. After returning to earth, the trace returns sorta level out like those displayed by your own test. The one that doesn't include the satellite hop.

But when I attempted to run it in the reverse direction, your site now responds with "Not Licensed for 174.34.146.18". One possible explanation is that you have it down again for some more "tweaking".

Who's playing games now?

//greg//

Actually the server detect your activity as a port scan and you were denied access by our firewall...

lfd on server3.ispgeeks.com: 66.82.187.152 (US/United States/dpc6682187152.direcpc.com) blocked for port scanning

Time: Sun May 17 14:23:05 2009 -0400
IP: 66.82.187.152 (US/United States/dpc6682187152.direcpc.com)
Hits: 11
Blocked: temporarily for 3600 seconds
Sample of block hits:
May 17 14:22:52 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=15384 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:22:53 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=18325 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:22:54 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=21096 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:22:55 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=23335 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:22:56 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=25663 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:22:57 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=28613 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:23:00 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=37519 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:23:01 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=40390 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:23:02 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=43306 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:23:03 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=45564 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0
May 17 14:23:04 server3 kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=00:21:9b:fb:b5:b0:00:14:1c:b6:41:45:08:00 SRC=66.82.187.152 DST=174.34.146.18 LEN=44 TOS=0x00 PREC=0x00 TTL=245 ID=48439 DF PROTO=TCP SPT=11304 DPT=79 WINDOW=16000 RES=0x00 SYN URGP=0

As for the message you received about not being licensed...where did you see that message and what were you doing (be specific).

 

[grohgreg]

Nothing more complicated than clicking on ISPgeeks.com Satellite ISP Network Trace Route, Testing and Analysis .

But you're the one who told me to run a trace to that specific IP address. So what's with the firewall? I suggested several days ago that you had bigger problems with that site. Or is this going to be my fault now too?

//greg//