Suggestions for people having problems connecting to the servers

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

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
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?
ID: 1307565 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
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!" :)
 
ID: 1307569 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
Message 1307573 - Posted: 19 Nov 2012, 1:26:17 UTC

Thanks for the info.
ID: 1307573 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14644
Credit: 200,643,578
RAC: 874
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.
ID: 1307574 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
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!" :)
 
ID: 1307591 · Report as offensive
TPCBF

Send message
Joined: 18 May 99
Posts: 54
Credit: 4,594,980
RAC: 0
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
ID: 1307594 · Report as offensive
TPCBF

Send message
Joined: 18 May 99
Posts: 54
Credit: 4,594,980
RAC: 0
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
ID: 1307595 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
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!" :)
 
ID: 1307597 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
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...
ID: 1307599 · Report as offensive
Horacio

Send message
Joined: 14 Jan 00
Posts: 536
Credit: 75,967,266
RAC: 0
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
ID: 1307601 · Report as offensive
juan BFP Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 16 Mar 07
Posts: 9786
Credit: 572,710,851
RAC: 3,799
Panama
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.

ID: 1307602 · Report as offensive
KZ3AB

Send message
Joined: 1 Mar 00
Posts: 6
Credit: 4,084,338
RAC: 0
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?


ID: 1307605 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 22149
Credit: 416,307,556
RAC: 380
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?
ID: 1307633 · Report as offensive
Profile Bernie Vine
Volunteer moderator
Volunteer tester
Avatar

Send message
Joined: 26 May 99
Posts: 9954
Credit: 103,452,613
RAC: 328
United Kingdom
Message 1307666 - Posted: 19 Nov 2012, 8:21:56 UTC

ID: 1307666 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14644
Credit: 200,643,578
RAC: 874
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.
ID: 1307694 · Report as offensive
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.
ID: 1307697 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14644
Credit: 200,643,578
RAC: 874
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.
ID: 1307732 · Report as offensive
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.
ID: 1308022 · Report as offensive
Previous · 1 · 2

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


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.