mod9, what he's saying is that the tech couldn't get the rosetta file either, using his laptop and JP's modem. The only thing left is the modem, the ISP, the backbone providers and Rosetta.

If it was a problem with the Rosetta server, then there should be more of us affected. And if it was a problem with Jean-Paul's modem, then he shouldn't be able to download a 10 meg file from Symantec.

I find it strange that the "tech" didn't run a tracert to the Rosetta server to identify where the possible problems are. When tracking down problems playing various online games, they'll usually give plenty of directions on finding out who is at fault.

---

I find it hard for the tech to say it's not the fault of the ISP, when he can't get the download to complete either. Seems pretty clear to me, that since there are not more people reporting such a problem that it IS the ISP. I mean there's only two PCs (I think?) that we've heard having such a problem, one is JP's and the other is JP's tech... and BOTH were using the same ISP! Coincidence??

JP, do you have any ISPs there that will give you a 30 day free trial? Perhaps you could try another ISP, or use a friends account or something just to see if you can prove there's something specific to that ISP's servers and routers.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

A user by the name of Finch also reported similar problems earlier in this thread here. It that thread he states:

I have nothing to contribute to a solution, but wanted to say you aren't the only one. There do not seem to be a significant number of people with this problem because I have never found much on this in forums, newsgroups, etc.
I have this problem with lhc and with rosetta. I can run einstein@home and world computing grid(which also uses rosetta) without problems.
I can download work units with no trouble. When I try to download the application file for these two projects it craps out at some point. Sometimes at 90+% through the transfer, sometimes as little as 20%.
I have tried to deal with this off and on for a year or more using different versions of boinc or newer versions of the application. I have never been able to solve it.
Running on xandros and dial-up.

Since this doesn't seem to be a common enough problem I think we are out of luck.
I am glad to see that you too have found some boinc projects that you can take part in.

I've kept JP going by emailing him the file, but the other small minority might just give up instead of working to use Rosetta. I wonder if Management couldn't contact JP via his listed email address and get JP's IP addy from him, so they could check the Apache logs to see where it's being dropped. JP might even use Ethereal and try to trace it himself, or atleast be able to send management the log.

JP might also try to borrow someone elses modem to rule his out as the culprit.

Just because JP's a member of an extremely small minority doesn't mean he shouldn't be allowed to participate, or that his concerns aren't valid.

tony

When I had the problems I was talking about with an online game - I was told to try a different ISP.. and to run Tracert (pingplotter would give even better information, since it can be run for hours and show network results over time.) to see where problems were happening. ACS worked fine with the game. GCI got all the way to Seattle, and there was a high rate of packet loss. I then had to call GCI's tech support, have them run a tracert from their network to the online game server - and they saw the same problem. Then they dealt with the corrupted router in Seattle that was causing the problem.

Assuming (often dangerous..) that the download site for the new rosetta updates is https://boinc.bakerlab.org (feel free to post the actual ip# and url for the client update site - and the site used by the automatic updates..) - I get this from running "tracert https://boinc.bakerlab.org >c:rosetta.txt" and then opening Rosetta.txt with a text editor.

Tracing route to https://boinc.bakerlab.org [66.150.161.133]

over a maximum of 30 hops:



1 52 ms 50 ms 51 ms 66-230-xxx-xxx-dsl-rb1.kdk.acsalaska.net [66.230.xxx.xxx] You might want to remove the first hop.. or mask out the ip# with xxx's like I've done.

2 52 ms 52 ms 51 ms fe1-0-104-cr1.kdk.acsalaska.net [209.193.35.105]

3 52 ms 51 ms 52 ms 209.193.6.17

4 692 ms 703 ms 683 ms 209.193.6.25

5 694 ms 680 ms 704 ms 209.193.6.26

6 699 ms 710 ms 706 ms ge6-2-gsr1.nwc.acsalaska.net [209.112.165.140]

7 723 ms 735 ms 740 ms s3-2-gsr1.sea.acsalaska.net [209.193.35.249]

8 715 ms 734 ms 742 ms sl-gw16-sea-2-4.sprintlink.net [144.228.93.21]

9 717 ms 707 ms 729 ms 144.232.6.163

10 733 ms 724 ms 747 ms sl-gw12-sea-1-0.sprintlink.net [144.232.6.122]

11 716 ms 733 ms 735 ms sl-internap-127-0.sprintlink.net [144.228.93.66]

12 730 ms 717 ms 741 ms border5.ge5-1-bbnet1.sef.pnap.net [63.251.160.10]

13 720 ms 735 ms 741 ms redirectf.dnsix.com [66.150.161.133]
Trace complete.

What this tells us: There's 13 steps between me and Rosetta.. that in my case, the first three hops are on island, and the rest have gone over a satellite jump which will hopefully be eliminated by Oct of this year.. :)
If you have major problems with lost packets, you'll see astericks "*" instead of a time like my gawd-awful 741ms.

If the problem is being caused by packet loss, then Tracert or PingPlotter will show you where the problem lies.

---

Everyone keeps talking about this as if it has to be either something on the server end OR something on our end. People seem to forget that this is a very rare problem on our end as well. If it was an obvious problem on my end it would be causing me much more extensive nuisance. I don't think it is a heat issue. I have run this modem for 7 years, in 80+ F mid summer indoor temps downloading hundreds of megabytes of linux distro for 10-12 hours at a time. I'm skeptical as to it being some conscious limit my isp is engaging in. They have always been very hands off, just providing a connection and staying out of my way to let me use it(quite intensively and never a complaint from them. I in turn don't have any significant complaints about them). I have never seen evidence of aggressive controlling behavior in their network management, so I doubt they have been overly zealous in configuring something that is causing trouble.

I think it is more likely that there is some subtle interaction of factors at BOTH the server end and my isp that only rarely crops up.
If it was simply one OR the other I don't think the issue would be as rare at the server end, if it was a server problem, or as rare at my end, if it was an isp or system problem.

I pointed out a way to see if it was network "in between" - on one of the many routers/servers between the end user, and the Rosetta Server. One misconfigured router near Seattle spelled doom for my connection to a gaming server at least 5 years ago.
I later noticed that many of the Cisco routers used on the saming server's isp were running old versions of IOS that were susceptible to certain attacks - i.e. it was possible to get the affected routers to create enough traffic on the ISP to knock it off the internet. (The gaming server's ISP went bankrupt..)

---

I pointed out a way to see if it was network "in between" - on one of the many routers/servers between the end user, and the Rosetta Server.)

traceroute looks normal to me
every hop is like these, with 140-200ms.

13 uwbr-ads-01-te3-1.cac.washington.edu (209.124.176.23) 189.844 ms 189.994 ms 190.262 ms
14 acar-ads-02-vlan3998.cac.washington.edu (140.142.155.25) 189.711 ms 189.245 ms 210.032 ms
15 boinc.bakerlab.org (140.142.20.103) 199.897 ms !C 199.926 ms !C 199.968 ms !C


mtr run for 30 secs or so a few times during evening hours shows 2% loss on one hop and none on the other 14 hops, average 200 ms or less on all hops, worst 500ms.

Nothing looks troubling to me.

Granted this wasn't run near the time of my problem downloading, but I have had this problem over many months of trying at various times.

I find it hard for the tech to say it's not the fault of the ISP, when he can't get the download to complete either. Seems pretty clear to me, that since there are not more people reporting such a problem that it IS the ISP. I mean there's only two PCs (I think?) that we've heard having such a problem, one is JP's and the other is JP's tech... and BOTH were using the same ISP! Coincidence??

JP, do you have any ISPs there that will give you a 30 day free trial? Perhaps you could try another ISP, or use a friends account or something just to see if you can prove there's something specific to that ISP's servers and routers.

Yes i'll try that thanks

---

...JP might also try to borrow someone elses modem to rule his out as the culprit.

Just because JP's a member of an extremely small minority doesn't mean he shouldn't be allowed to participate, or that his concerns aren't valid.

tony

I don't believe anyone associated with the project has suggested that just because the problem is limited to two reports that these people will be abandoned. I have certainly not suggested that. AS I said the sys admin has looked that this and cannot find any problem on the server side. While not by any means a suggestion that these two people do not deserve help, it is significant that there are not more reports. The clear implication is that there is something not right on the remote end of the connection. IT could very well be that the e-mails are compressed in transmission and fall below some maximum file limit.

The fact that software from other projects that are using Rosetta software can be downloaded, is not significant. None of those project is using the current (and larger) Rosetta application. I will again draw attention to this thread to the sys admin, but I suspect that the modem or the ISP are the source of the issue. It could be that the modem overheats with a high sustained load and shuts off, it could be that the ISP has a limit the technician is not aware of. It could be a lot of things, but we will keep at it until we find the cause.

This is my trace to the BOINC network. Does this look ok to you? To me it dose so where is the prob?

1 0 0 0 66.98.244.1 gphou-66-98-244-1.ev1.net
2 0 1 0 66.98.241.16 gphou-66-98-241-16.ev1.net
3 4 1 1 66.98.240.14 gphou-66-98-240-14.ev1.net
4 1 1 1 129.250.11.141 ge-1-3-0.r02.hstntx01.us.bb.gin.ntt.net
5 52 52 52 129.250.2.1 p16-1-1-0.r21.plalca01.us.bb.gin.ntt.net
6 53 53 53 129.250.5.49 p64-0-0-0.r21.mlpsca01.us.bb.gin.ntt.net
7 70 70 70 129.250.4.22 p64-0-0-0.r20.sttlwa01.us.bb.gin.ntt.net
8 70 70 70 129.250.2.205 xe-3-1.r00.sttlwa01.us.bb.gin.ntt.net
9 70 70 70 129.250.10.193 ge-0.uw.sttlwa01.us.bb.gin.ntt.net
10 68 66 67 209.124.176.23 uwbr-ads-01-te3-1.cac.washington.edu
11 67 67 67 140.142.155.25 acar-ads-02-vlan3998.cac.washington.edu
12 67 66 66 140.142.20.103 boinc.bakerlab.org

---

I had a similar problem to this at work, although not with Rosetta. It turned out to be the MTU size and one of the hops to the USA which would for some reason truncate the packets. It only happenned on larger transfers. Traceroute and ping were all fine.

MTU is set in regedit under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersInterfaces
You will need to pick the current interface you are using and add a DWORD named MTU and set its value to 576 (dec) for a PPP connection or 1400 (dec) for a DSL

You will need to reboot after making the change. It is at least worth a try.

Ian

I had a similar problem to this at work, although not with Rosetta. It turned out to be the MTU size and one of the hops to the USA which would for some reason truncate the packets. It only happenned on larger transfers. Traceroute and ping were all fine.

MTU is set in regedit under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersInterfaces
You will need to pick the current interface you are using and add a DWORD named MTU and set its value to 576 (dec) for a PPP connection or 1400 (dec) for a DSL

You will need to reboot after making the change. It is at least worth a try.

Ian

I just did that an try to attach to QMC same thing i get all the files but not the .exe. The only thing left to do is to go to another ISP if i can get a mounth free if not i'm not going to pay $$$ just to crunch data an find out it's not the ISP but something else. -:)
Thanks for trying. Have a nice day.

---

I had a similar problem to this at work, although not with Rosetta. It turned out to be the MTU size... set its value to 576 (dec) for a PPP connection or 1400 (dec) for a DSL

mtu on this machine is 552.

I had a similar problem to this at work, although not with Rosetta. It turned out to be the MTU size... set its value to 576 (dec) for a PPP connection or 1400 (dec) for a DSL

mtu on this machine is 552.

I have it set at 1464 Thats as high as my ISP will let me go. Should i bring it down more?

---

JP....You've got mail

MOD9 anyone figure why these people can't complete downloads yet? Have they or are they looking into it?

tony

Gues what they've updated again. hihihi. Could u send me the new rosetta 5.22 plz.
Thanks again for all the help.
EMail j_paube at hotmail dot com.

JP
Have a nice day.

---

Gues what they've updated again. hihihi. Could u send me the new rosetta 5.22 plz.
Thanks again for all the help.
EMail xxxxxxxxxxxxxcom.

JP
Have a nice day.

You've got mail, again

[edit]you can remove your email addy, I have it on file[/edit]

Gues what they've updated again. hihihi. Could u send me the new rosetta 5.22 plz.
Thanks again for all the help.
EMail xxxxxxxxxxxxxcom.

JP
Have a nice day.

You've got mail, again

[edit]you can remove your email addy, I have it on file[/edit]

OK next time i wont have to put it in. Thatks Good thing i remember i old dos command hehehe later
JP.

---

I wanted to post a follow up to my situation. Since moving from xandros to ubuntu I don't have the problem I described. Whether this is something to do with the kernel version or with xandros itself I don't know. I have just tried rosetta again and have been able to complete downloads. I do note that I am still getting some timeout and 500 errors, but ultimately I am getting files. I do not have these timeout issues with worldgrid. I will see whether this persists or whether it appears to be unrelated to what was happening before, but it may be that there is still something going on and that the OS change has somehow lessened the severity of the problem.

Boinc version is the same as it was in my previous posts.

I'll try to remember to post a follow up after I have had time to see whether the timeout issues are persistent or not.

Tue 02 Jan 2007 10:04:04 AM CST|rosetta@home|Sending scheduler request to https://boinc.bakerlab.org/rosetta_cgi/cgi
Tue 02 Jan 2007 10:04:04 AM CST|rosetta@home|Reason: To fetch work
Tue 02 Jan 2007 10:04:04 AM CST|rosetta@home|Requesting 259200 seconds of new work
Tue 02 Jan 2007 10:04:14 AM CST|rosetta@home|Scheduler request to https://boinc.bakerlab.org/rosetta_cgi/cgi succeeded
Tue 02 Jan 2007 10:04:16 AM CST|rosetta@home|Started download of rosetta_5.43_i686-pc-linux-gnu
Tue 02 Jan 2007 10:04:16 AM CST|rosetta@home|Started download of hom003_s019_.fasta.gz
Tue 02 Jan 2007 10:04:18 AM CST|rosetta@home|Finished download of hom003_s019_.fasta.gz
Tue 02 Jan 2007 10:04:18 AM CST|rosetta@home|Throughput 192 bytes/sec
Tue 02 Jan 2007 10:04:18 AM CST|rosetta@home|Started download of hom003_s019_.psipred_ss2.gz
Tue 02 Jan 2007 10:04:22 AM CST|rosetta@home|Finished download of hom003_s019_.psipred_ss2.gz
Tue 02 Jan 2007 10:04:22 AM CST|rosetta@home|Throughput 311 bytes/sec
Tue 02 Jan 2007 10:04:22 AM CST|rosetta@home|Started download of boinc_hom003_aas019_03_05.200_v1_3.gz
Tue 02 Jan 2007 10:14:59 AM CST|rosetta@home|Finished download of boinc_hom003_aas019_03_05.200_v1_3.gz
Tue 02 Jan 2007 10:14:59 AM CST|rosetta@home|Throughput 1332 bytes/sec
Tue 02 Jan 2007 10:14:59 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 10:22:41 AM CST|rosetta@home|Temporarily failed download of boinc_hom003_aas019_09_05.200_v1_3.gz: error 500
Tue 02 Jan 2007 10:22:41 AM CST|rosetta@home|Started download of abrelax_description.txt
Tue 02 Jan 2007 10:22:46 AM CST|rosetta@home|Finished download of abrelax_description.txt
Tue 02 Jan 2007 10:22:46 AM CST|rosetta@home|Throughput 25 bytes/sec
Tue 02 Jan 2007 10:22:47 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 10:32:56 AM CST||Attempting to communicate with [srv4.bakerlab.org] timed out
Tue 02 Jan 2007 10:32:57 AM CST|rosetta@home|Temporarily failed download of boinc_hom003_aas019_09_05.200_v1_3.gz: timeout
Tue 02 Jan 2007 10:32:58 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 10:46:52 AM CST|rosetta@home|Temporarily failed download of boinc_hom003_aas019_09_05.200_v1_3.gz: error 500
Tue 02 Jan 2007 10:46:53 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 11:02:09 AM CST||Attempting to communicate with [srv4.bakerlab.org] timed out
Tue 02 Jan 2007 11:02:10 AM CST|rosetta@home|Temporarily failed download of boinc_hom003_aas019_09_05.200_v1_3.gz: timeout
Tue 02 Jan 2007 11:02:10 AM CST|rosetta@home|Backing off 1 minutes and 0 seconds on download of file boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 11:03:10 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 11:13:10 AM CST|rosetta@home|Temporarily failed download of boinc_hom003_aas019_09_05.200_v1_3.gz: error 500
Tue 02 Jan 2007 11:13:11 AM CST|rosetta@home|Started download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 11:17:22 AM CST|rosetta@home|Finished download of boinc_hom003_aas019_09_05.200_v1_3.gz
Tue 02 Jan 2007 11:17:22 AM CST|rosetta@home|Throughput 719 bytes/sec
Tue 02 Jan 2007 11:24:20 AM CST|rosetta@home|Finished download of rosetta_5.43_i686-pc-linux-gnu
Tue 02 Jan 2007 11:24:20 AM CST|rosetta@home|Throughput 2560 bytes/sec
Tue 02 Jan 2007 11:24:22 AM CST||request_reschedule_cpus: files downloaded