Do you know if the optimal setting for the ADSL-2 is 1500 or 1492?

---

Just do the test (gives result in 5-10 s)

My Router say: Line Mode: ADSL2+
and TCPOptimizer: "You can set your MTU to 1492"


You can do the same test manually using Ping (and then add 28 bytes overhead):

>Ping setiathome.berkeley.edu /f -l 1464

Pinging setiathome.berkeley.edu [128.32.18.150] with 1464 bytes of data:

Reply from 128.32.18.150: bytes=1464 time=244ms TTL=46
Reply from 128.32.18.150: bytes=1464 time=248ms TTL=46
Reply from 128.32.18.150: bytes=1464 time=245ms TTL=46
Reply from 128.32.18.150: bytes=1464 time=245ms TTL=46

Ping statistics for 128.32.18.150:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 244ms, Maximum = 248ms, Average = 245ms

>Ping setiathome.berkeley.edu /f -l 1465

Pinging setiathome.berkeley.edu [128.32.18.150] with 1465 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 128.32.18.150:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Thanks for the info.

---

When I tried running the optimiser on my ADSL 2 internet connection, the 'Largest MTU' test with all the pre-defined Speedtest URLs suggested 1492.

But when I put in a Berkeley server - I put in the .16 upload server, I couldn't get the test to complete on the scheduler address - the largest unfragmented MTU reported was 1476.

There is small bug in TCPOptimizer - one of the Advanced values:
NonBestEffortLimit=0

... is (appears to be) set in the program interface (after you choose Optimal for the first time)
but is not set/saved to the registry on [Apply]

Just run TCPOptimizer for second time, choose again Optimal and [Apply]

For all values you will see 'No Change' and only for one:

Value Name		Old value	New value	Default value	Path	
NonBestEffortLimit	n/a		0	 	20		HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched\NonBestEffortLimit	

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

I found very easy solution for my fastest machine, needed just two steps:

1. Set NNT for Seti@Home.
2. Alow new tasks for Rosetta@Home.

"Vom Regen in die Traufe..."

Rosetta has constantly it's own set of issues, most recently a large batch of bad WUs that caused graphic pop-ups (the screen saver part of the application) out of nowhere and no real remedy for issues like that...

S@H might not be perfect, and yes it is frustrating if there are issues like the recent database issue and it's fallout, but overall, S@H still has better communication and resolution of problems than R@H...

Ralf

What is the MTU that TCP Opti is recommending? I can set that on my router for all rigs. Currently at 1492.

That would be your WAN side MTU, indicating that you are on a PPPoE based DSL connection (default of 1500 - 8 byte PPPoE overhead).
And there is nothing you can change on that or you might make things even worse.

On your LAN, you are likely to have the Ethernet default of 1500bytes, and you can use JumnoFrames on your your LAN only if you have a Gigabit switch and ALL of your hosts support JumboFrames. Otherwise, you will have another gun pointed on your foot.

The issues that we all have are not client side, they are server side, and rather less a communication issue but a database one...

Ralf

When I tried running the optimiser on my ADSL 2 internet connection, the 'Largest MTU' test with all the pre-defined Speedtest URLs suggested 1492.

But when I put in a Berkeley server - I put in the .16 upload server, I couldn't get the test to complete on the scheduler address - the largest unfragmented MTU reported was 1476.

You are right - all the servers:
208.68.240.13
208.68.240.21
208.68.240.16
208.68.240.20

report the same:

Pinging [208.68.240.20] with 1500 bytes -> ..fragmented
Pinging [208.68.240.20] with 750 bytes ->bytes=750 time=232ms TTL=53
Pinging [208.68.240.20] with 1125 bytes ->bytes=1125 time=235ms TTL=53
Pinging [208.68.240.20] with 1312 bytes ->bytes=1312 time=237ms TTL=53
Pinging [208.68.240.20] with 1406 bytes ->bytes=1406 time=238ms TTL=53
Pinging [208.68.240.20] with 1453 bytes -> ..fragmented
Pinging [208.68.240.20] with 1429 bytes ->bytes=1429 time=238ms TTL=53
Pinging [208.68.240.20] with 1441 bytes ->bytes=1441 time=238ms TTL=53
Pinging [208.68.240.20] with 1447 bytes ->bytes=1447 time=236ms TTL=53
Pinging [208.68.240.20] with 1450 bytes -> ..fragmented
Pinging [208.68.240.20] with 1448 bytes ->bytes=1448 time=238ms TTL=53
Pinging [208.68.240.20] with 1449 bytes -> ..fragmented
The largest possible non-fragmented packet is 1448 (1476 - 28 ICMP & IP headers).
You can set your MTU to 1476


Looks possible they have some misconfiguration?

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Just Running now, AP-spliters are out, even with 1500 there are no loose packages...

---

Just Running now, AP-spliters are out, even with 1500 there are no loose packages...

Yeah, but... the scheduller is out also...
18/11/2012 23:41:23(*)| SETI@home | Message from server: Project is temporarily shut down for maintenance

(*) a couple minutes before this post

---

Just Running now, AP-spliters are out, even with 1500 there are no loose packages...

Yeah, but... the scheduller is out also...
18/11/2012 23:41:23(*)| SETI@home | Message from server: Project is temporarily shut down for maintenance

(*) a couple minutes before this post

Yes but we are just ping the location IP.

---

Just Running now, AP-spliters are out, even with 1500 there are no loose packages...

Yeah, but... the scheduller is out also...
18/11/2012 23:41:23(*)| SETI@home | Message from server: Project is temporarily shut down for maintenance

(*) a couple minutes before this post

Yes but we are just ping the location IP.

Huh?

---

Beig able to ping a location only means there is an route from your PC to that location, not that the computer at the remote end is doing anything useful. The splitters have been taken down, once the split pool has emptied the only data that will be available for distribution will be re-sends.
We are in for a lean time.
We may get more news on Monday, but my guess is they will be doing some serious thinking, so don't hold your breath.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Please note Erics thread http://setiathome.berkeley.edu/forum_thread.php?id=70080&postid=1307567

---

When I tried running the optimiser on my ADSL 2 internet connection, the 'Largest MTU' test with all the pre-defined Speedtest URLs suggested 1492.

But when I put in a Berkeley server - I put in the .16 upload server, I couldn't get the test to complete on the scheduler address - the largest unfragmented MTU reported was 1476.

You are right - all the servers:
208.68.240.13
208.68.240.21
208.68.240.16
208.68.240.20

report the same:

Pinging [208.68.240.20] with 1500 bytes -> ..fragmented
Pinging [208.68.240.20] with 750 bytes ->bytes=750 time=232ms TTL=53
Pinging [208.68.240.20] with 1125 bytes ->bytes=1125 time=235ms TTL=53
Pinging [208.68.240.20] with 1312 bytes ->bytes=1312 time=237ms TTL=53
Pinging [208.68.240.20] with 1406 bytes ->bytes=1406 time=238ms TTL=53
Pinging [208.68.240.20] with 1453 bytes -> ..fragmented
Pinging [208.68.240.20] with 1429 bytes ->bytes=1429 time=238ms TTL=53
Pinging [208.68.240.20] with 1441 bytes ->bytes=1441 time=238ms TTL=53
Pinging [208.68.240.20] with 1447 bytes ->bytes=1447 time=236ms TTL=53
Pinging [208.68.240.20] with 1450 bytes -> ..fragmented
Pinging [208.68.240.20] with 1448 bytes ->bytes=1448 time=238ms TTL=53
Pinging [208.68.240.20] with 1449 bytes -> ..fragmented
The largest possible non-fragmented packet is 1448 (1476 - 28 ICMP & IP headers).
You can set your MTU to 1476

Looks possible they have some misconfiguration?

I'm wondering if this (partly) explains the proxy mystery ("why do they help so much...?"). The SETI servers are running Linux, the guys in the lab will be using Linux tools to monitor and tweak them, and I'm guessing the majority of public proxies are run on Linux - and perhaps with conservative networking settings to help with bad internet connections. Maybe making the final hop Linux-Linux helps?

I'm also wondering whether the tunneling connection between HE/PAIX adds extra payload beyond the 28-byte allowed for ICMP & IP. The fragmentation may be happening on that link, rather than in the SETI servers themselves.

When I tried running the optimiser on my ADSL 2 internet connection, the 'Largest MTU' test with all the pre-defined Speedtest URLs suggested 1492.

But when I put in a Berkeley server - I put in the .16 upload server, I couldn't get the test to complete on the scheduler address - the largest unfragmented MTU reported was 1476.

You are right - all the servers:
208.68.240.13
208.68.240.21
208.68.240.16
208.68.240.20

report the same:

Pinging [208.68.240.20] with 1500 bytes -> ..fragmented
Pinging [208.68.240.20] with 750 bytes ->bytes=750 time=232ms TTL=53
Pinging [208.68.240.20] with 1125 bytes ->bytes=1125 time=235ms TTL=53
Pinging [208.68.240.20] with 1312 bytes ->bytes=1312 time=237ms TTL=53
Pinging [208.68.240.20] with 1406 bytes ->bytes=1406 time=238ms TTL=53
Pinging [208.68.240.20] with 1453 bytes -> ..fragmented
Pinging [208.68.240.20] with 1429 bytes ->bytes=1429 time=238ms TTL=53
Pinging [208.68.240.20] with 1441 bytes ->bytes=1441 time=238ms TTL=53
Pinging [208.68.240.20] with 1447 bytes ->bytes=1447 time=236ms TTL=53
Pinging [208.68.240.20] with 1450 bytes -> ..fragmented
Pinging [208.68.240.20] with 1448 bytes ->bytes=1448 time=238ms TTL=53
Pinging [208.68.240.20] with 1449 bytes -> ..fragmented
The largest possible non-fragmented packet is 1448 (1476 - 28 ICMP & IP headers).
You can set your MTU to 1476

Looks possible they have some misconfiguration?

I'm wondering if this (partly) explains the proxy mystery ("why do they help so much...?"). The SETI servers are running Linux, the guys in the lab will be using Linux tools to monitor and tweak them, and I'm guessing the majority of public proxies are run on Linux - and perhaps with conservative networking settings to help with bad internet connections. Maybe making the final hop Linux-Linux helps?

I'm also wondering whether the tunneling connection between HE/PAIX adds extra payload beyond the 28-byte allowed for ICMP & IP. The fragmentation may be happening on that link, rather than in the SETI servers themselves.

Possibly ECN - Explicit Congestion Notification. The default value in Windows 7 is disabled - use the TCP Optimizer and it sets it to default. Project is down now - I'll know for sure once it comes up and I can Wireshark the data. Not sure of how the other OS's handle congestion - but know from seeing other threads that MACS seem to have no trouble - but - that is expected - they run the same TCP/IP as LINUX.

---

It looks as if the basic MTU setting under Windows 7 can be changed on the fly from an administrative command prompt with

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1476 store=persistent

without needing a reboot. Check that your computer uses the default name of "Local Area Connection" for your internet connection - I suspect that may not be true for WiFi or USB modem/dongle connections.

When I tried running the optimiser on my ADSL 2 internet connection, the 'Largest MTU' test with all the pre-defined Speedtest URLs suggested 1492.

But when I put in a Berkeley server - I put in the .16 upload server, I couldn't get the test to complete on the scheduler address - the largest unfragmented MTU reported was 1476.

You are right - all the servers:
208.68.240.13
208.68.240.21
208.68.240.16
208.68.240.20

report the same:

Pinging [208.68.240.20] with 1500 bytes -> ..fragmented
Pinging [208.68.240.20] with 750 bytes ->bytes=750 time=232ms TTL=53
Pinging [208.68.240.20] with 1125 bytes ->bytes=1125 time=235ms TTL=53
Pinging [208.68.240.20] with 1312 bytes ->bytes=1312 time=237ms TTL=53
Pinging [208.68.240.20] with 1406 bytes ->bytes=1406 time=238ms TTL=53
Pinging [208.68.240.20] with 1453 bytes -> ..fragmented
Pinging [208.68.240.20] with 1429 bytes ->bytes=1429 time=238ms TTL=53
Pinging [208.68.240.20] with 1441 bytes ->bytes=1441 time=238ms TTL=53
Pinging [208.68.240.20] with 1447 bytes ->bytes=1447 time=236ms TTL=53
Pinging [208.68.240.20] with 1450 bytes -> ..fragmented
Pinging [208.68.240.20] with 1448 bytes ->bytes=1448 time=238ms TTL=53
Pinging [208.68.240.20] with 1449 bytes -> ..fragmented
The largest possible non-fragmented packet is 1448 (1476 - 28 ICMP & IP headers).
You can set your MTU to 1476

Looks possible they have some misconfiguration?

I'm wondering if this (partly) explains the proxy mystery ("why do they help so much...?"). The SETI servers are running Linux, the guys in the lab will be using Linux tools to monitor and tweak them, and I'm guessing the majority of public proxies are run on Linux - and perhaps with conservative networking settings to help with bad internet connections. Maybe making the final hop Linux-Linux helps?

I'm also wondering whether the tunneling connection between HE/PAIX adds extra payload beyond the 28-byte allowed for ICMP & IP. The fragmentation may be happening on that link, rather than in the SETI servers themselves.

Possibly ECN - Explicit Congestion Notification. The default value in Windows 7 is disabled - use the TCP Optimizer and it sets it to default. Project is down now - I'll know for sure once it comes up and I can Wireshark the data. Not sure of how the other OS's handle congestion - but know from seeing other threads that MACS seem to have no trouble - but - that is expected - they run the same TCP/IP as LINUX.

--UPDATE -- Don't know if it is what was done while the server was down - or setting ECN to default - however, system is now working without a proxy. Maybe not perfectly (I am at work and cannot get log) however, it is getting work which was not happening before.

---