Suggestions for people having problems connecting to the servers


log in

Advanced search

Message boards : Number crunching : Suggestions for people having problems connecting to the servers

Previous · 1 · 2
Author Message
juan BFBProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 5316
Credit: 295,372,973
RAC: 473,699
Brazil
Message 1307565 - Posted: 19 Nov 2012, 0:50:50 UTC

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

Profile BilBg
Volunteer tester
Avatar
Send message
Joined: 27 May 07
Posts: 2695
Credit: 6,098,005
RAC: 4,869
Bulgaria
Message 1307569 - Posted: 19 Nov 2012, 1:16:32 UTC - in response to Message 1307565.
Last modified: 19 Nov 2012, 1:29:12 UTC


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!" :)

juan BFBProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 5316
Credit: 295,372,973
RAC: 473,699
Brazil
Message 1307573 - Posted: 19 Nov 2012, 1:26:17 UTC

Thanks for the info.
____________

Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8508
Credit: 50,001,860
RAC: 49,415
United Kingdom
Message 1307574 - Posted: 19 Nov 2012, 1:31:29 UTC

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.

Profile BilBg
Volunteer tester
Avatar
Send message
Joined: 27 May 07
Posts: 2695
Credit: 6,098,005
RAC: 4,869
Bulgaria
Message 1307591 - Posted: 19 Nov 2012, 2:01:47 UTC - in response to Message 1307561.


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!" :)

TPCBF
Send message
Joined: 18 May 99
Posts: 50
Credit: 1,069,165
RAC: 3,265
United States
Message 1307594 - Posted: 19 Nov 2012, 2:09:05 UTC - in response to Message 1307322.

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

TPCBF
Send message
Joined: 18 May 99
Posts: 50
Credit: 1,069,165
RAC: 3,265
United States
Message 1307595 - Posted: 19 Nov 2012, 2:14:37 UTC - in response to Message 1307330.

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

Profile BilBg
Volunteer tester
Avatar
Send message
Joined: 27 May 07
Posts: 2695
Credit: 6,098,005
RAC: 4,869
Bulgaria
Message 1307597 - Posted: 19 Nov 2012, 2:25:13 UTC - in response to Message 1307574.

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!" :)

juan BFBProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 5316
Credit: 295,372,973
RAC: 473,699
Brazil
Message 1307599 - Posted: 19 Nov 2012, 2:37:38 UTC

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

Horacio
Send message
Joined: 14 Jan 00
Posts: 536
Credit: 73,691,570
RAC: 76,581
Argentina
Message 1307601 - Posted: 19 Nov 2012, 2:45:59 UTC - in response to Message 1307599.

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
____________

juan BFBProject donor
Volunteer tester
Avatar
Send message
Joined: 16 Mar 07
Posts: 5316
Credit: 295,372,973
RAC: 473,699
Brazil
Message 1307602 - Posted: 19 Nov 2012, 2:48:27 UTC - in response to Message 1307601.

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.

____________

KZ3AB
Send message
Joined: 1 Mar 00
Posts: 6
Credit: 2,465,531
RAC: 1,078
United States
Message 1307605 - Posted: 19 Nov 2012, 3:10:00 UTC - in response to Message 1307602.

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?


____________

rob smithProject donor
Volunteer tester
Send message
Joined: 7 Mar 03
Posts: 8403
Credit: 56,939,671
RAC: 76,439
United Kingdom
Message 1307633 - Posted: 19 Nov 2012, 6:34:05 UTC

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?

Profile Bernie Vine
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 26 May 99
Posts: 6976
Credit: 26,460,121
RAC: 32,510
United Kingdom
Message 1307666 - Posted: 19 Nov 2012, 8:21:56 UTC

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


Today is life, the only life we're sure of. Make the most of today.

Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8508
Credit: 50,001,860
RAC: 49,415
United Kingdom
Message 1307694 - Posted: 19 Nov 2012, 11:54:26 UTC - in response to Message 1307597.

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.

Draconian
Volunteer tester
Send message
Joined: 16 Mar 03
Posts: 21
Credit: 1,809,058
RAC: 0
United States
Message 1307697 - Posted: 19 Nov 2012, 12:23:10 UTC - in response to Message 1307694.

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.
____________

Richard HaselgroveProject donor
Volunteer tester
Send message
Joined: 4 Jul 99
Posts: 8508
Credit: 50,001,860
RAC: 49,415
United Kingdom
Message 1307732 - Posted: 19 Nov 2012, 15:52:50 UTC

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.

Draconian
Volunteer tester
Send message
Joined: 16 Mar 03
Posts: 21
Credit: 1,809,058
RAC: 0
United States
Message 1308022 - Posted: 20 Nov 2012, 6:06:44 UTC - in response to Message 1307697.

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.
____________

Previous · 1 · 2

Message boards : Number crunching : Suggestions for people having problems connecting to the servers

Copyright © 2014 University of California