All of mine go through the same firewall, all can connect to the internet, I just have 3 that will not talk to Seti properly, but will talk fine to Einstien.

Thats what doesn't make sense to me either, the two problem PC's have been connected to pirates and einstein and working fine till the last two days.

I used to get an occasional error 500 on one of them but that would pass by the next time it tried to contact the scheduler.

As well as these PCs working fine through the firewall with other projects i have 5 other PC's that go through the same firewall same projects but no errors at all. Just read about the firewall causing problems in another thread and changed the gateway on these PC's to bypass the firewall filters and now they're happy.

Something very odd is going on =/

---

changed the gateway on these PC's to bypass the firewall filters and now they're happy.

Something very odd is going on =/

Could those firewall filter rules be limiting the ports numbers allowed?

BOINC/Seti/LibcURL (something in there) uses a different port each time on the user end when it tries to upload. It appears to increment the port number for each upload attempt. My one system is now at port 4868 for its last upload. If there are firewall rules limiting the range of ports allowed, a specific machine could run up to that limit and then start failing. While the one next to it might still be using lower port numbers and work.

Would help to know if there are such port number limits in the firewall rules (now that you are working without the fire wall) and what port number a machine that started working is using for uploads (a quick TCP/IP trace of packets to/from 66.28.250.125 the upload server for Seti) would be useful to see if that is what is going on in your case (and other company firewalls).

I took a look, all of mine seem to be the same, including the byte count of the file.

I am sorry to have to ask, but leaving out details can slow the process down quite a bit. What exactly were the size of those files. And when viewed in Wordpad, did the XML look valid or was there garbage characters at the front or end of the file.

Your symptoms indicate that the files might be damaged or having missing parts to it. But no idea why it works on one and not the other system.

A corrupted, zero length or missing master_project.XML would sure cause a lot of problems trying to connect to that projects Scheduler, as it contains the URL for that projects scheduler!

For Seti, the master_setiathome.berkeley.edu.xml should be 69 bytes long, and contain the URL of <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> or else you are never going to get a response from the server. And with the current error messages, that would result in an ERROR 500. Or no response from te scheduler.

Exactly correct, Jack. master_setiathome.berkeley.edu.xml is exactly 69 bytes, <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> is the contents. This is getting fun. No wonder I can't find a job in this state....

---

I took a look, all of mine seem to be the same, including the byte count of the file.

I am sorry to have to ask, but leaving out details can slow the process down quite a bit. What exactly were the size of those files. And when viewed in Wordpad, did the XML look valid or was there garbage characters at the front or end of the file.

Your symptoms indicate that the files might be damaged or having missing parts to it. But no idea why it works on one and not the other system.

A corrupted, zero length or missing master_project.XML would sure cause a lot of problems trying to connect to that projects Scheduler, as it contains the URL for that projects scheduler!

For Seti, the master_setiathome.berkeley.edu.xml should be 69 bytes long, and contain the URL of <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> or else you are never going to get a response from the server. And with the current error messages, that would result in an ERROR 500. Or no response from te scheduler.

Exactly correct, Jack. master_setiathome.berkeley.edu.xml is exactly 69 bytes, <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> is the contents. This is getting fun. No wonder I can't find a job in this state....

I am now down 4 systems for Seti. That still leaves 3 that are processing work units. The last system that I just attached to Einstein had been without work for 2 days now. My most recent observation is that while trying to upload or download work units, my transfer speed is very slow. While concurrently downloading 2 work units from Seti, I get dropped and restarted frequently, and my aggregate download speed can be roughly 1.5k bits/sec. Downloading from Einstein, I get an aggregate speed of nearly 6k bits/sec. with the same 40k connection.

---

I took a look, all of mine seem to be the same, including the byte count of the file.

I am sorry to have to ask, but leaving out details can slow the process down quite a bit. What exactly were the size of those files. And when viewed in Wordpad, did the XML look valid or was there garbage characters at the front or end of the file.

Your symptoms indicate that the files might be damaged or having missing parts to it. But no idea why it works on one and not the other system.

A corrupted, zero length or missing master_project.XML would sure cause a lot of problems trying to connect to that projects Scheduler, as it contains the URL for that projects scheduler!

For Seti, the master_setiathome.berkeley.edu.xml should be 69 bytes long, and contain the URL of <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> or else you are never going to get a response from the server. And with the current error messages, that would result in an ERROR 500. Or no response from te scheduler.

Exactly correct, Jack. master_setiathome.berkeley.edu.xml is exactly 69 bytes, <scheduler>http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi</scheduler> is the contents. This is getting fun. No wonder I can't find a job in this state....

I am now down 4 systems for Seti. That still leaves 3 that are processing work units. The last system that I just attached to Einstein had been without work for 2 days now. My most recent observation is that while trying to upload or download work units, my transfer speed is very slow. While concurrently downloading 2 work units from Seti, I get dropped and restarted frequently, and my aggregate download speed can be roughly 1.5k bits/sec. Downloading from Einstein, I get an aggregate speed of nearly 6k bits/sec. with the same 40k connection.

Here is the result from this afternoon.

1/23/2006 3:44:40 PM|SETI@home|Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
1/23/2006 3:44:40 PM|SETI@home|Message from server: Not sending work - last RPC too recent: 25 sec
1/23/2006 3:45:20 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.exe
1/23/2006 3:45:20 PM|SETI@home|Started download of better_banner.jpg
1/23/2006 3:45:27 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.exe: error 500
1/23/2006 3:45:27 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.exe
1/23/2006 3:45:27 PM|SETI@home|Temporarily failed download of better_banner.jpg: error 500
1/23/2006 3:45:27 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file better_banner.jpg
1/23/2006 3:45:27 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:45:27 PM|SETI@home|Started download of 25se04aa.16928.19344.253418.1.88
1/23/2006 3:45:30 PM|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
1/23/2006 3:45:30 PM|Einstein@Home|Reason: To fetch work
1/23/2006 3:45:30 PM|Einstein@Home|Requesting 161889 seconds of new work
1/23/2006 3:45:31 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.pdb: error 500
1/23/2006 3:45:31 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:45:31 PM|SETI@home|Temporarily failed download of 25se04aa.16928.19344.253418.1.88: error 500
1/23/2006 3:45:31 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file 25se04aa.16928.19344.253418.1.88
1/23/2006 3:45:50 PM|Einstein@Home|Scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi succeeded
1/23/2006 3:45:52 PM||request_reschedule_cpus: files downloaded
1/23/2006 3:45:52 PM||request_reschedule_cpus: files downloaded
1/23/2006 3:45:52 PM||request_reschedule_cpus: files downloaded
1/23/2006 3:45:52 PM||request_reschedule_cpus: files downloaded
1/23/2006 3:45:52 PM|Einstein@Home|Started download of z1_0121.5
1/23/2006 3:45:52 PM|Einstein@Home|Started download of skygrid_0130_z_T04.dat
1/23/2006 3:46:00 PM|Einstein@Home|Finished download of skygrid_0130_z_T04.dat
1/23/2006 3:46:02 PM|Einstein@Home|Throughput 2440 bytes/sec
1/23/2006 3:46:28 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.exe
1/23/2006 3:46:28 PM|SETI@home|Started download of better_banner.jpg
1/23/2006 3:46:38 PM|SETI@home|Temporarily failed download of better_banner.jpg: error 500
1/23/2006 3:46:38 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file better_banner.jpg
1/23/2006 3:46:38 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:46:41 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.pdb: error 500
1/23/2006 3:46:41 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:46:41 PM|SETI@home|Started download of 25se04aa.16928.19344.253418.1.88
1/23/2006 3:46:42 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.exe: error 500
1/23/2006 3:46:42 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.exe
1/23/2006 3:46:47 PM|SETI@home|Temporarily failed download of 25se04aa.16928.19344.253418.1.88: error 500
1/23/2006 3:46:47 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file 25se04aa.16928.19344.253418.1.88
1/23/2006 3:46:51 PM|Einstein@Home|Sending scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi
1/23/2006 3:46:51 PM|Einstein@Home|Reason: To fetch work
1/23/2006 3:46:51 PM|Einstein@Home|Requesting 2079 seconds of new work
1/23/2006 3:47:16 PM|Einstein@Home|Scheduler request to http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi succeeded
1/23/2006 3:47:38 PM|SETI@home|Started download of better_banner.jpg
1/23/2006 3:47:41 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:48:02 PM|SETI@home|Temporarily failed download of better_banner.jpg: error 500
1/23/2006 3:48:02 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file better_banner.jpg
1/23/2006 3:48:02 PM|SETI@home|Started download of 25se04aa.16928.19344.253418.1.88
1/23/2006 3:48:06 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.pdb: error 500
1/23/2006 3:48:06 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.pdb
1/23/2006 3:48:07 PM|SETI@home|Started download of setiathome_4.18_windows_intelx86.exe
1/23/2006 3:48:28 PM|SETI@home|Temporarily failed download of 25se04aa.16928.19344.253418.1.88: error 500
1/23/2006 3:48:28 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file 25se04aa.16928.19344.253418.1.88
1/23/2006 3:48:36 PM|SETI@home|Temporarily failed download of setiathome_4.18_windows_intelx86.exe: error 500
1/23/2006 3:48:36 PM|SETI@home|Backing off 1 minutes and 0 seconds on download of file setiathome_4.18_windows_intelx86.exe

---

Leo, have you tried Dr. TCP??? follow the directions. Record current setting so you can return it to the same value. Try 576, 1372, 1472, and 1500. If the lower ones work let us know.

You can test it by doing a traceroute

Leo, have you tried Dr. TCP??? follow the directions. Record current setting so you can return it to the same value. Try 576, 1372, 1472, and 1500. If the lower ones work let us know.

You can test it by doing a traceroute

I did a tracert earlier today, using an IP address that began with a 66?. I didn't write it down, if you post which one to use, I will run them.

Dr TCP only wants to work with my ethernet connection, not my dialup one. I can run the settings manually, it will just take longer.

MTU 576

Pinging 66.28.250.125 with 32 bytes of data:

Request timed out.
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=411ms TTL=246
Reply from 66.28.250.125: bytes=32 time=265ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 265ms, Maximum = 411ms, Average = 316ms


Tracing route to 66.28.250.125 over a maximum of 30 hops

1 202 ms 218 ms 195 ms nas1.Rochester1.Level3.net [209.244.189.86]
2 307 ms 185 ms 175 ms ge-7-0-2.hsa2.Boston1.Level3.net [63.212.202.3]

3 299 ms 203 ms 183 ms ae-2-52.mp2.Boston1.Level3.net [4.68.100.33]
4 271 ms 189 ms 183 ms so-0-0-0.bbr1.NewYork1.Level3.net [64.159.4.182]

5 271 ms 183 ms 185 ms ae-11-55.car1.NewYork1.Level3.net [4.68.97.148]

6 283 ms 179 ms 191 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.4
6]
7 280 ms 186 ms 189 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.1
4]
8 319 ms 216 ms 216 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.
202]
9 399 ms 251 ms 251 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.2
09]
10 265 ms 267 ms 263 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.6
9]
11 405 ms 263 ms 263 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 419 ms 274 ms 259 ms 66.28.250.125



MTU 1372


Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

1 190 ms 195 ms 189 ms nas3.Rochester1.Level3.net [209.244.43.203]
2 264 ms 181 ms 179 ms ge-7-0-1.hsa2.Boston1.Level3.net [63.212.200.3]
3 268 ms 171 ms 169 ms ae-2-52.mp2.Boston1.Level3.net [4.68.100.33]
4 282 ms 185 ms 187 ms ae-0-0.bbr2.NewYork1.Level3.net [64.159.1.42]
5 291 ms 189 ms 186 ms ae-21-54.car1.NewYork1.Level3.net [4.68.97.116]
6 251 ms 187 ms 191 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.42]
7 276 ms 184 ms 189 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 321 ms 228 ms 224 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
9 403 ms 248 ms 253 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
10 251 ms 255 ms 268 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 256 ms 269 ms 259 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 389 ms 257 ms 263 ms 66.28.250.125


Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=313ms TTL=246
Reply from 66.28.250.125: bytes=32 time=269ms TTL=246
Reply from 66.28.250.125: bytes=32 time=403ms TTL=246
Reply from 66.28.250.125: bytes=32 time=260ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 403ms, Average = 311ms

---

128.32.18.185 is setiathome.berkeley.edu (website)
128.32.18.173 is setiboinc.ssl.berkeley.edu (scheduling server)
66.28.250.125 is setiboincdata.ssl.berkeley.edu (UL/DL server)

Unless IP's have changed. you can use the DNS names instead

128.32.18.185 is setiathome.berkeley.edu (website)
128.32.18.173 is setiboinc.ssl.berkeley.edu (scheduling server)
66.28.250.125 is setiboincdata.ssl.berkeley.edu (UL/DL server)

Unless IP's have changed. you can use the DNS names instead

MTU 1472


Tracing route to 66.28.250.125 over a maximum of 30 hops

1 188 ms 186 ms 194 ms nas1.Rochester1.Level3.net [209.244.189.86]
2 234 ms 173 ms 179 ms ge-7-0-1.hsa2.Boston1.Level3.net [63.212.200.3]
3 309 ms 177 ms 169 ms ae-2-54.mp2.Boston1.Level3.net [4.68.100.97]
4 303 ms 199 ms 177 ms so-0-0-0.bbr1.NewYork1.Level3.net [64.159.4.182]
5 261 ms 193 ms 185 ms ae-11-53.car1.NewYork1.Level3.net [4.68.97.84]
6 290 ms 183 ms 183 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.42]
7 180 ms 197 ms 185 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 288 ms 218 ms 218 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.20
9 377 ms 253 ms 249 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209
10 253 ms 265 ms 263 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 407 ms 247 ms 259 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 254 ms 263 ms 265 ms 66.28.250.125


Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=280ms TTL=246
Reply from 66.28.250.125: bytes=32 time=406ms TTL=246
Reply from 66.28.250.125: bytes=32 time=262ms TTL=246
Reply from 66.28.250.125: bytes=32 time=402ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 262ms, Maximum = 406ms, Average = 337ms

Speedguide TCP optimizer results:
Pinging [66.28.250.125] with 40 bytes ->bytes=40 time=301ms TTL=246
Pinging [66.28.250.125] with 750 bytes ->bytes=750 time=268ms TTL=246
Pinging [66.28.250.125] with 1125 bytes ->bytes=1125 time=282ms TTL=246
Pinging [66.28.250.125] with 1312 bytes ->bytes=1312 time=288ms TTL=246
Pinging [66.28.250.125] with 1406 bytes ->bytes=1406 time=280ms TTL=246
Pinging [66.28.250.125] with 1453 bytes ->bytes=1453 time=283ms TTL=246
Pinging [66.28.250.125] with 1476 bytes -> ..fragmented
Pinging [66.28.250.125] with 1465 bytes ->bytes=1465 time=295ms TTL=246
Pinging [66.28.250.125] with 1470 bytes ->bytes=1470 time=279ms TTL=246
Pinging [66.28.250.125] with 1473 bytes -> ..fragmented
Pinging [66.28.250.125] with 1472 bytes ->bytes=1472 time=277ms TTL=246
The largest possible non-fragmented packet is 1472 (1500 - 28 ICMP & IP headers).
You can set your MTU to 1500

---

now the important question. Got work? or the same message? If the same message, what does the traceroute of the scheduling server say? setiboinc.ssl.berkeley.edu don't worry about Ping, it's just 32 bytes of data unless you instruct otherwise.

now the important question. Got work? or the same message? If the same message, what does the traceroute of the scheduling server say? setiboinc.ssl.berkeley.edu don't worry about Ping, it's just 32 bytes of data unless you instruct otherwise.

Unfortunately, just the same message.

---

so, you can get to the website (your here), you can traceroute to both the scheduling AND UL/DL servers successfully at an MTU of 1472, but you can't get work from seti. Is this right? Have you tried temporarily lowering the MTU to 576 so we can rule that out?

MTU 1500


Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=282ms TTL=246
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=274ms TTL=246
Reply from 66.28.250.125: bytes=32 time=286ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 273ms, Maximum = 286ms, Average = 278ms


Tracing route to 66.28.250.125 over a maximum of 30 hops

1 200 ms 185 ms 185 ms nas3.Rochester1.Level3.net [209.244.43.203]
2 217 ms 195 ms 187 ms ge-7-0-1.hsa2.Boston1.Level3.net [63.212.200.3]
3 237 ms 191 ms 178 ms ae-2-54.mp2.Boston1.Level3.net [4.68.100.97]
4 241 ms 189 ms * ae-0-0.bbr2.NewYork1.Level3.net [64.159.1.42]
5 194 ms 183 ms 183 ms ae-11-53.car1.NewYork1.Level3.net [4.68.97.84]
6 274 ms 187 ms 185 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.46]
7 177 ms 189 ms 183 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 275 ms 206 ms 217 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
9 347 ms 261 ms 258 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
10 249 ms 844 ms 257 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 255 ms 263 ms 263 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 347 ms 265 ms 268 ms 66.28.250.125

Again: (a second time)
Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

1 606 ms 827 ms 1730 ms nas3.Rochester1.Level3.net [209.244.43.203]
2 2639 ms 2612 ms * ge-7-0-2.hsa2.Boston1.Level3.net [63.212.202.3]
3 3818 ms 3938 ms 3443 ms ae-2-54.mp2.Boston1.Level3.net [4.68.100.97]
4 479 ms 2315 ms 3929 ms so-0-0-0.bbr1.NewYork1.Level3.net [64.159.4.182]
5 1793 ms 335 ms 176 ms ae-11-53.car1.NewYork1.Level3.net [4.68.97.84]
6 178 ms 208 ms 431 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.46]
7 183 ms 320 ms 187 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 230 ms 255 ms 224 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
9 572 ms 767 ms 675 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
10 1223 ms 1802 ms 1298 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 2101 ms 2294 ms 2306 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 3480 ms 1746 ms 2892 ms 66.28.250.125

One last time:
Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

1 176 ms 185 ms 187 ms nas3.Rochester1.Level3.net [209.244.43.203]
2 304 ms 177 ms 191 ms ge-7-0-1.hsa2.Boston1.Level3.net [63.212.200.3]
3 222 ms 189 ms 175 ms ae-2-54.mp2.Boston1.Level3.net [4.68.100.97]
4 210 ms 183 ms 173 ms so-0-0-0.bbr1.NewYork1.Level3.net [64.159.4.182]
5 214 ms 181 ms 183 ms ae-11-53.car1.NewYork1.Level3.net [4.68.97.84]
6 321 ms 185 ms 173 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.46]
7 313 ms 191 ms 187 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 219 ms 228 ms 224 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
9 265 ms 261 ms 249 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
10 248 ms 250 ms 249 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 410 ms 256 ms 253 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 263 ms 257 ms 259 ms 66.28.250.125

This is the MTU I have used for at least a year. When I changed the MTU in each post, I also tried to update from Seti. It sees the server, but errors out at about 7 seconds. This is on the systems that won't update without the 500 error persistantly. I still get an occasional 500 or I/O error on the rest of my systems, but that goes away after a couple of attempts, and the downloads/uploads are successful.
These are the results that I posted earlier, they were in a lower post;

"I did a tracert earlier today, using an IP address that began with a 66?. I didn't write it down, if you post which one to use, I will run them.

Dr TCP only wants to work with my ethernet connection, not my dialup one. I can run the settings manually, it will just take longer.

MTU 576

Pinging 66.28.250.125 with 32 bytes of data:

Request timed out.
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=411ms TTL=246
Reply from 66.28.250.125: bytes=32 time=265ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 265ms, Maximum = 411ms, Average = 316ms


Tracing route to 66.28.250.125 over a maximum of 30 hops

1 202 ms 218 ms 195 ms nas1.Rochester1.Level3.net [209.244.189.86]
2 307 ms 185 ms 175 ms ge-7-0-2.hsa2.Boston1.Level3.net [63.212.202.3]

3 299 ms 203 ms 183 ms ae-2-52.mp2.Boston1.Level3.net [4.68.100.33]
4 271 ms 189 ms 183 ms so-0-0-0.bbr1.NewYork1.Level3.net [64.159.4.182]

5 271 ms 183 ms 185 ms ae-11-55.car1.NewYork1.Level3.net [4.68.97.148]

6 283 ms 179 ms 191 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.4
6]
7 280 ms 186 ms 189 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.1
4]
8 319 ms 216 ms 216 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.
202]
9 399 ms 251 ms 251 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.2
09]
10 265 ms 267 ms 263 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.6
9]
11 405 ms 263 ms 263 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 419 ms 274 ms 259 ms 66.28.250.125



MTU 1372


Tracing route to setiboincdata.ssl.berkeley.edu [66.28.250.125]
over a maximum of 30 hops:

1 190 ms 195 ms 189 ms nas3.Rochester1.Level3.net [209.244.43.203]
2 264 ms 181 ms 179 ms ge-7-0-1.hsa2.Boston1.Level3.net [63.212.200.3]
3 268 ms 171 ms 169 ms ae-2-52.mp2.Boston1.Level3.net [4.68.100.33]
4 282 ms 185 ms 187 ms ae-0-0.bbr2.NewYork1.Level3.net [64.159.1.42]
5 291 ms 189 ms 186 ms ae-21-54.car1.NewYork1.Level3.net [4.68.97.116]
6 251 ms 187 ms 191 ms cogent-level3-ge.NewYork1.Level3.net [4.68.111.42]
7 276 ms 184 ms 189 ms p15-0.core02.jfk02.atlas.cogentco.com [66.28.4.14]
8 321 ms 228 ms 224 ms p12-0.core01.mci01.atlas.cogentco.com [154.54.3.202]
9 403 ms 248 ms 253 ms p10-0.core02.sfo01.atlas.cogentco.com [66.28.4.209]
10 251 ms 255 ms 268 ms p15-0.core01.sfo01.atlas.cogentco.com [66.28.4.69]
11 256 ms 269 ms 259 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
12 389 ms 257 ms 263 ms 66.28.250.125


Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=313ms TTL=246
Reply from 66.28.250.125: bytes=32 time=269ms TTL=246
Reply from 66.28.250.125: bytes=32 time=403ms TTL=246
Reply from 66.28.250.125: bytes=32 time=260ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 403ms, Average = 311ms "

---

Those ping times don't look very good. Very long if those are from his DSL connection. They might be part of the problem, when combined with system delays in the server systems.

Most of his problem seems to be between his system and the ISP's HeadEnd modem. Some ISP's HeadEnd modems can be real slow to respond to pings, but should pass request through quickly. His is not passing commands through quickly as seen by the slow response in the Tracert of the second router. So it is not clear if this is a system problem of his, a router problem, network problem or modem problem, or just a slow HeadEnd modem.

Try pinging your router (should be under 10ms) and your modem if it responds. Should be the following addresses by default. Also try pinging each of your systems by IP address and tell us what the time= is. Should be under 10ms.

ping 192.168.1.1

ping 192.168.100.1

ping 192.168.1.101
ping 192.168.1.102 etc.

If pings of your router, other systems and modem are over 11ms then there is a problem on your end somewhere. If those are OK, then you sure are getting slow response problems going to you ISP. This assumes those are the ping times of you going through your DSL and not a slow dialup connection.

I am thinking that with real long lag times like you are seeing (almost 1/2 second) that the LibcURL software is timing it out for some reason. Something to look into. If I can find the time, I will look into this a little more, but I hope some of the Internet experts will jump in here and see if this is really a problem. (I seldom see ping times of over 120ms.)

Try the pings of the 66.28.250.125 from each of your systems, and look at the average times. See if those times are longer for the ones with connection problems, and post back what the average time is for each of the systems.

I have seen cases where a failing network card or router would cause long ping times from some or all systems connected. Also, see if you can verify that all of your systems are connected at 100Mbps and not running at 10Mbps. Check in their network properties for the NIC setup and make sure it shows AUTO speed/duplex setup and not set to half duplex and/or 10Mbps. But any of those types of problems should not cause a problem it each system was connected directly to the modem and connected to Berkeley.

Leo, what I meant was can you get work from seti at 576, I figured you'd be able to traceroute at 576 since you can at higher levels.

Leo, what I meant was can you get work from seti at 576, I figured you'd be able to traceroute at 576 since you can at higher levels.

No, it doesn't make a difference what the MTU is set to, the systems that won't download workunits fail equally as well at any MTU setting. The ones that do receive workunits, do so with the same disregard.

---

MTU 1500

Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=282ms TTL=246
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=274ms TTL=246
Reply from 66.28.250.125: bytes=32 time=286ms TTL=246

<snipp>

MTU 576

Pinging 66.28.250.125 with 32 bytes of data:

Request timed out.
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=411ms TTL=246
Reply from 66.28.250.125: bytes=32 time=265ms TTL=246

<snipp>

MTU 1372

Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=313ms TTL=246
Reply from 66.28.250.125: bytes=32 time=269ms TTL=246
Reply from 66.28.250.125: bytes=32 time=403ms TTL=246
Reply from 66.28.250.125: bytes=32 time=260ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 403ms, Average = 311ms "

Hi Guys,

I couldn't help notice, but if you ping some site using its default options (ping <ip address>) it will always work, because it uses a 32 byte data packet. And you don't need to change the MTU parameter in the TCP/IP protocol to look for a problem in the MTU size. Just use the "-l" option, like this:

ping setiboincdata.ssl.berkeley.edu -f -l 1472

The "-f" switch will tell ping to set the "Don't fragment" bit, while the "-l 1472" will set the packe size to 1472 bytes.

About the tracert command, I think it is not affected by the MTU size, but I could be wrong.

One last though: when testing changes in the MTU size, you must reboot Windows in order to reinitialize the parameters for the TCP/IP, otherwise it will keep using the MTU size of the last boot.

Btw, you might want to take a look at this Microsoft article and at this thread. Maybe some of what is described is usefull to you.

Regards,
Wander

---

Those ping times don't look very good. Very long if those are from his DSL connection. They might be part of the problem, when combined with system delays in the server systems.

Most of his problem seems to be between his system and the ISP's HeadEnd modem. Some ISP's HeadEnd modems can be real slow to respond to pings, but should pass request through quickly. His is not passing commands through quickly as seen by the slow response in the Tracert of the second router. So it is not clear if this is a system problem of his, a router problem, network problem or modem problem, or just a slow HeadEnd modem.

Try pinging your router (should be under 10ms) and your modem if it responds. Should be the following addresses by default. Also try pinging each of your systems by IP address and tell us what the time= is. Should be under 10ms.

ping 192.168.1.1

ping 192.168.100.1

ping 192.168.1.101
ping 192.168.1.102 etc.

If pings of your router, other systems and modem are over 11ms then there is a problem on your end somewhere. If those are OK, then you sure are getting slow response problems going to you ISP. This assumes those are the ping times of you going through your DSL and not a slow dialup connection.

I am thinking that with real long lag times like you are seeing (almost 1/2 second) that the LibcURL software is timing it out for some reason. Something to look into. If I can find the time, I will look into this a little more, but I hope some of the Internet experts will jump in here and see if this is really a problem. (I seldom see ping times of over 120ms.)

Try the pings of the 66.28.250.125 from each of your systems, and look at the average times. See if those times are longer for the ones with connection problems, and post back what the average time is for each of the systems.

I have seen cases where a failing network card or router would cause long ping times from some or all systems connected. Also, see if you can verify that all of your systems are connected at 100Mbps and not running at 10Mbps. Check in their network properties for the NIC setup and make sure it shows AUTO speed/duplex setup and not set to half duplex and/or 10Mbps. But any of those types of problems should not cause a problem it each system was connected directly to the modem and connected to Berkeley.

Jack, I am on dialup. None of the routers from here to Berkeley are under my control. The systems in my house are on a 100mb switch, (all network adapters are set to 100/auto/full duplex)and a DLink DI-624 wireless router / switch. I can only use the switch function, no broadband here. I use the wireless network to keep the cable mess from causing a marital meltdown, and can communicate to 3 machines in another building 40' away from my house. Worst system - 300-500ms. ping. This is through 3 walls, one of which is metal. It downloads from Einstein ok, just not Seti. Same for the one on my wired portion. 0ms ping, Einstein ok, just not Seti. All the systems used to work, they just seem to be dropping out.

---

MTU 1500

Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=282ms TTL=246
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=274ms TTL=246
Reply from 66.28.250.125: bytes=32 time=286ms TTL=246

<snipp>

MTU 576

Pinging 66.28.250.125 with 32 bytes of data:

Request timed out.
Reply from 66.28.250.125: bytes=32 time=273ms TTL=246
Reply from 66.28.250.125: bytes=32 time=411ms TTL=246
Reply from 66.28.250.125: bytes=32 time=265ms TTL=246

<snipp>

MTU 1372

Pinging 66.28.250.125 with 32 bytes of data:

Reply from 66.28.250.125: bytes=32 time=313ms TTL=246
Reply from 66.28.250.125: bytes=32 time=269ms TTL=246
Reply from 66.28.250.125: bytes=32 time=403ms TTL=246
Reply from 66.28.250.125: bytes=32 time=260ms TTL=246

Ping statistics for 66.28.250.125:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 260ms, Maximum = 403ms, Average = 311ms "

Hi Guys,

I couldn't help notice, but if you ping some site using its default options (ping <ip address>) it will always work, because it uses a 32 byte data packet. And you don't need to change the MTU parameter in the TCP/IP protocol to look for a problem in the MTU size. Just use the "-l" option, like this:

ping setiboincdata.ssl.berkeley.edu -f -l 1472

The "-f" switch will tell ping to set the "Don't fragment" bit, while the "-l 1472" will set the packe size to 1472 bytes.

About the tracert command, I think it is not affected by the MTU size, but I could be wrong.

One last though: when testing changes in the MTU size, you must reboot Windows in order to reinitialize the parameters for the TCP/IP, otherwise it will keep using the MTU size of the last boot.

Btw, you might want to take a look at this Microsoft article and at this thread. Maybe some of what is described is usefull to you.

Regards,
Wander

Hi Wander,
Yes, that was sort of what I lamented when I started this part out tonight. Make a change, document what was done, reboot. Start up the apps. Check and test. Make more changes, try again. Then you show me the shortcut. Maybe someone could put together a master troubleshooting page. That would have saved me some time. But I had to try to get updates on the systems that haven't been able to since the last outage, and that took some time also. Maybe this thing will get popped open soon, and I can finish out of Einstein, and back to Seti.

---

Jack, one of the problems we saw earlier with a handful of people was pretty much just like Leos' problem. Could traceroute with seti or other projects, could get work from other projects, just not seti. Adjusting the MTU size worked for some. There's a theory about fragmentation and the berkeley server. I felt it worth giving it a shot.