Hello all,
I've recently gotten online with Tooway and would like to optimize the networking settings of my computers (Windows XP) for the Tooway connection.  I've read a few Internet posts on dslreports.com, one topic on satsig.net, and a few other sites, but I don't find anything consistent with regard to recommendations. I don't see any specific recommendations in the Tooway installation manual either, but I know the default TCP settings in Windows are not optimal for Tooway, so I'm hoping to reach someone with some experience tweaking TCP settings, such as the ones below that can be modified with DRTCP (my current modified settings in parentheses):
Receive Window (112180)
Window Scaling (Yes)
Time Stamping (No)
Selective Acks (Yes)
Path MTU Discovery (Yes)
Black Hole Detection (No)
Max. Duplicate Acks (3)
TTL (64)
MTU (1472 - on the Ethernet adapter)

Currently, I don't have any router/switch devices between the laptop and the Tooway modem, as I'm first trying to optimize the connection with this setup.  Before making changes, the satellite service was barely usable.  After the changes, most pages appear, and download speeds are faster than my mobile/cellular Internet service, but I get many multiples more 'page cannot be displayed errors' on Tooway than on the mobile Internet connection.  The settings shown above give me the least amount 'page cannot be displayed' errors, but I still haven't been able to eliminate those errors, despite speed/tweak tests with dslreports.com that show I shouldn't have any problems with packet loss.  Thanks for your help!
John

One John to another,

I use XP Pro (SP3), didn't adjust anything.  I uses a Pluscom router, though.  I do not have your problems at all.  Just the darned rain.  Seems like it must be a problem in your set up.

If you have a direct link to the modem, I doubt any tweaks would improve the speed much.  I believe that for us the modem is effectively the other end of the link.   It has its own scheme of communicating with the satellite.

The modem (it is claimed) performs some compression/expansion functions,  so that a clever pre-fetch can be used to reduce the latency.  This page, for instance, has about 28 separate components, and although requests would overlap this would add up to a huge latency and a very tedious wait for the complete page.

At least, that's what I think.  Does someone out there know better?

Regards,  John

interesting.

if browse to the Modem during acquisition at 192.168.100.1 you can view and capture the event log...

but after it connects (took 1.5 hours this morning) you lose access to that ip and you seem to have an ip at the Italian uplink site -- going by the latency  average of 700ms.

why will the modem not release or renew the Ip issued by DCHP without going through a full power off reboot.

thats painfull at 1.5 hours....

my modem went through this process this morning.

the downlink connected quickly on 1554.840210Mhz but then couldnt connect on the uplink and looped back to start again ... over and over again

THU JAN 01 00:22:35 1970      RNG-RSP: 0 [ticks], 0 [Hz], 0.75 [dBm]
THU JAN 01 00:22:34 1970      RNG-RSP: -1 [ticks], 12473 [Hz], 0.75 [dBm]
THU JAN 01 00:22:33 1970      RNG-RSP: 1 [ticks], 25600 [Hz], 0.00 [dBm]
THU JAN 01 00:22:26 1970      RNG-RSP: -1 [ticks], 25600 [Hz], 0.00 [dBm]
THU JAN 01 00:22:23 1970      RNG-RSP: 111887 [ticks], 0 [Hz], 0.00 [dBm]
THU JAN 01 00:22:20 1970      US Scan: 1008.929993 [MHz], Channel 18
THU JAN 01 00:22:16 1970      DS NAPA: Success
THU JAN 01 00:22:15 1970      DS Acquire: 1554.840210 [MHz], 25.00 [Msps], 6.00 [dB], MR
THU JAN 01 00:22:10 1970      DS Scan: 1554.840210 [MHz]
THU JAN 01 00:22:06 1970      DS Scan: 1554.750000 [MHz]
THU JAN 01 00:21:59 1970      DS Scan: 1290.000000 [MHz]
THU JAN 01 00:21:53 1970      DS Scan: 1280.000000 [MHz]
THU JAN 01 00:21:46 1970      DS Scan: 1270.000000 [MHz]
THU JAN 01 00:21:39 1970      DS Scan: 1260.000000 [MHz]
THU JAN 01 00:21:32 1970      DS Scan: 1250.000000 [MHz]

Ian H

IanH-Powys wrote

Quote:

why will the modem not release or renew the Ip issued by DCHP without going through a full power off reboot. thats painfull at 1.5 hours....

This could be one of the problems the (ku) HUB is trying to solve.

The line below appears to show a receive quality once the correct wanted carrier has been found:

THU JAN 01 00:22:15 1970 DS Acquire: 1554.840210 [MHz], 25.00 [Msps], 6.00 [dB], MR

Tell your service provider the 6.00 [dB] and ask if this is normal.

The graph below shows what the hub can see about site signal levels.  For the green downstream (towards remote site) a figure around 9 dB looks normal for this example site, with extremes of 10.5 and 6.5 (clear sky and rain ?).  6 dB sounds rather low.
https://www.satsig.net/el-molino/ka-band-signal-levels-graph.gif

If your receive is poor due to mispointing your transmit will be far worse since the transmit beam is narrower than the receive beam.

Ask your service provider what your graph looks like and explanations regarding any on-going problems at the hub.

Best regards, Eric.

I have been reading some documentation that showed a new install  screen display with failure message saying the receive C/N was too low at 7 dB.

I would have though that above 7 dB and preferably 10 dB under clear sky conditions was reasonable for first set set up.

Best regards, Eric.