Message boards : Server and website : Website unreachable
Author | Message |
---|---|
The connection has timed out | |
ID: 49955 | Rating: 0 | rate: / Reply Quote | |
Not an official response, but from another volunteer: I haven't had any issues. Maybe it's locally, with your ISP or a larger routing issue? | |
ID: 49956 | Rating: 0 | rate: / Reply Quote | |
Not an official response, but from another volunteer: I haven't had any issues. Maybe it's locally, with your ISP or a larger routing issue? Thanks. I was wondering why there were not more complaints. I don't have problems with other projects, but there must be something about this route. It has been bad for a long time, and getting worse. (Possibly a change in DNS servers will help.) | |
ID: 49957 | Rating: 0 | rate: / Reply Quote | |
I've been getting this problem for a while now myself. 1st or 2nd attempt for connection to GPUGrid.net time out. Then the next attempt gets through. If I make a task download request on one system, then invariably the next system to make a request gets a very long request cycle or times out. | |
ID: 49959 | Rating: 0 | rate: / Reply Quote | |
That is it. But my own ISP's DNS servers have been known to be unreliable in the past, so I have now set the OpenDNS servers in my router: | |
ID: 49960 | Rating: 0 | rate: / Reply Quote | |
My experience is like Keith's. I have up to five computers attached to GPUGrid, all on the same home LAN and connected via a single router - so all sharing the same public IP address. | |
ID: 49961 | Rating: 0 | rate: / Reply Quote | |
That is it. But my own ISP's DNS servers have been known to be unreliable in the past, so I have now set the OpenDNS servers in my router: You can try google's public DNS servers too: Primary: 8.8.8.8
Secondary: 8.8.4.4 Or Cloudflare's: Primary: 1.1.1.1
Secondary: 1.0.0.1 - OR - Windows users can put GPUGrid's IP address to the the hosts file of the OS, in this way the OS don't have to ask the DNS servers for GPUGrid's IP address. (however you have to change it manually if the IP address changes) Press Windows key + R Type, or copy and paste the following: notepad c:\windows\system32\drivers\etc\hosts insert the following line at the end of the file: 84.89.134.145 www.gpugrid.net save and exit from notepad Probably there's a similar workaround for Linux. BTW from the description of the error I suspect that this is not a DNS issue, rather session limit / bandwidth problem. | |
ID: 49962 | Rating: 0 | rate: / Reply Quote | |
I get this too in the US. Using a proxy server located in the EU immediately solves the timeouts. Turn off the VPN and timeouts again. It's absolutely location based. Watching upload speeds go down and down then spike back up then drop and drop in a continuous loop says there are network issues somewhere crossing the pond. | |
ID: 49963 | Rating: 0 | rate: / Reply Quote | |
If it was a DNS problem, you would see entries like | |
ID: 49964 | Rating: 0 | rate: / Reply Quote | |
If it was a DNS problem, you would see entries like I haven't seen that, but I wasn't looking for it when I had the failures, and have rebooted since, so that log is gone (maybe saved?). But since switching to OpenDNS, website access has been much faster and more reliable. But I still got one failure, so I created a hosts file entry as Zoltan suggested. It seems to have eliminated the problem entirely. Previously, I could not connect twice in succession, but had to wait a couple of minutes between attempts. EDIT: The problems that I have noticed are only on my Windows7 64-bit machine where I access the website with Firefox. I do the crunching (both CPU and GPU) on dedicated Ubuntu machines that I access over the LAN, and haven't noticed any hung transfers there in BoincTasks. Maybe any problems there are just hidden, I don't know. But it could be a Windows issue? EDIT2: The BoincTask logs for my Ubuntu machines are still available after several days, since I don't reboot them often, and I don't see any DNS or other problems there, for whatever that is worth. In fact, it may just be a Firefox timing issue of some sort. | |
ID: 49965 | Rating: 0 | rate: / Reply Quote | |
Next time it happens, I'll do some digging in the event logs. That probably won't be until we get a Windows GPU workflow running again - I've set 'no new work' except for one test probe for the time being. | |
ID: 49966 | Rating: 0 | rate: / Reply Quote | |
If it was a DNS problem, you would see entries like Its not FF as the website hangs for me too with Chrome. And the variable upload speeds I see are from Ubuntu. | |
ID: 49967 | Rating: 0 | rate: / Reply Quote | |
My symptoms are exactly as Richard described. I have mostly Linux machines with one Windows 10 machine. I have the problem on all machines so not OS specific. | |
ID: 49971 | Rating: 0 | rate: / Reply Quote | |
It could be one of the negative side effects of discarding net neutrality. | |
ID: 49972 | Rating: 0 | rate: / Reply Quote | |
It could be one of the negative side effects of discarding net neutrality. Some ISP would have to be monitoring you pretty carefully to distinguish between the first and second attempt. And I am not sure what they would gain. I have 50 Mbps down/10 Mbps up for a flat rate. I don't think they care what it is. At least they haven't tried to charge me more for the second attempt to GPUGrid. Chances are, the problem is more at the project end, but I don't know if you are seeing it in Europe? | |
ID: 49975 | Rating: 0 | rate: / Reply Quote | |
... but I don't know if you are seeing it in Europe? I now have tried to open various GPUGRID pages one after the other, in a sequence of a few seconds - no problem here (in Austria) ... | |
ID: 49977 | Rating: 0 | rate: / Reply Quote | |
no problem here (in Austria) ... I wonder if there is more than one problem? Since fixing the DNS issue, I can open multiple web pages here without a problem that I see. There may be something slow in getting across the Atlantic though that does not appear in Europe. | |
ID: 49979 | Rating: 0 | rate: / Reply Quote | |
I suggest you to use http://speedtest.net and choose a server in Barcelona to test your connection speed (at different times of a day).It could be one of the negative side effects of discarding net neutrality. I don't think they care what it is. At least they haven't tried to charge me more for the second attempt to GPUGrid.That's what a flat rate is about. But if they prioritize traffic from Netflix, or Amazon or whatever content provider which pays for them, traffic of other parties will suffer. International / Intercontinental data traffic costs a lot (for your ISP), because to build the data lines on the bottom of the ocean have cost a lot, also they have limited transfer speed (compared to the number of computers connected through these lines); so your ISP do care about to where their customers connect in the world (called traffic shaping and QoS Quality of Service). Chances are, the problem is more at the project end, but I don't know if you are seeing it in Europe?Rarely, but it's because we're closer (geographically; also IT wise: there are less IT equipment connecting GPUGrid's server and my computers than computers on other continents). | |
ID: 49980 | Rating: 0 | rate: / Reply Quote | |
Speedtest from Barcelona is no problem, about the same as the U.S. | |
ID: 49981 | Rating: 0 | rate: / Reply Quote | |
Speedtest from Barcelona is no problem, about the same as the U.S.That is good news, while it makes the original issue really strange. However it could be a misconfigured router, which we can't figure out. Net neutrality really is not it.Ok, that was only one of many possibilities. It could be any large traffic (on any router in between) which hinders others (for example torrent traffic drastically increases when a new episode of a popular series is released on torrent sites). I am not enough of a network expert to suggest beyond that.Neither am I, and even if one of us would be, it couldn't be figured out without analyzing router traffic logs which is available only for the ISP staff. (I am resisting the temptation to say that it is a GDPR check, but probably won't be able to for long.)GDPR (beside being a pain in the arse for European companies too) is about handling personal data, not about handling (shaping) data traffic. If the issue would be based on GDPR, it would cause problems with your connection with CERN too. | |
ID: 49982 | Rating: 0 | rate: / Reply Quote | |
GDPR (beside being a pain in the arse for European companies too) is about handling personal data, not about handling (shaping) data traffic. Humor does not always make it across the pond. PS - I did not have a speed problem, but a connectivity issue of some sort. So there might be another factor at work for some people. Also, it appears that some people monitor their upload/downloads much better than I do, and may be catching problems that I don't see. I only saw the obvious problem of not reaching the website, but that is now fixed. | |
ID: 49983 | Rating: 0 | rate: / Reply Quote | |
I receive "Website unreachable" messages lately. Ping statistics for 84.89.134.145:
Packets: Sent = 1273, Received = 1255, Lost = 18 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 82ms, Maximum = 136ms, Average = 83ms I have no idea what could cause this, but those who have such access problems should try to run ping in the background and test the accessibility of the GPUGrid website. | |
ID: 50132 | Rating: 0 | rate: / Reply Quote | |
Thanks for the data. My speculation is that there already is some preferential routing for well-known high-traffic websites, while gpugrid is not a "well known" one and is throttled. | |
ID: 50133 | Rating: 0 | rate: / Reply Quote | |
I let ping run for all night, the statistics show the same: Ping statistics for 84.89.134.145:
Packets: Sent = 28889, Received = 28544, Lost = 345 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 82ms, Maximum = 174ms, Average = 85ms | |
ID: 50134 | Rating: 0 | rate: / Reply Quote | |
While I don't discount the possibility of DNS problems - it's worth checking - I think there are other problems to explore. This site can’t be reached That was opening a page shortly (less than a minute) after a different machine on my network had reported a completed task. There is no evidence of a timing problem on the reporting machine: 29/07/2018 10:37:11 | GPUGRID | Finished upload of e24s22_e15s67p0f28-PABLO_2IDP_P01106_2_ASNP21P_IDP-0-1-RND3729_0_1 I don't think the browser error message indicates a DNS problem in this case, but I do think it's related to the other machine reporting. | |
ID: 50135 | Rating: 0 | rate: / Reply Quote | |
Still location based and its a very old issue. EU is fine but across the pond we get timeouts. | |
ID: 50137 | Rating: 0 | rate: / Reply Quote | |
Still location based and its a very old issue. EU is fine but across the pond we get timeouts. I don't have the short timeouts that I was getting originally, the DNS change fixed that. But I occasionally get long timeouts (after 30 seconds), so something is happening somewhere. | |
ID: 50138 | Rating: 0 | rate: / Reply Quote | |
While I don't discount the possibility of DNS problems - it's worth checking - I think there are other problems to explore. This is the same kind of behavior that I observe. It's almost as if the GPUGrid.net database locks the userid for a short period of time after the first machine reports or accesses that hosts database. The next host that tries to contact the site either to report or access its stats gets the timeout. | |
ID: 50143 | Rating: 0 | rate: / Reply Quote | |
This is the same kind of behavior that I observe. It's almost as if the GPUGrid.net database locks the userid for a short period of time after the first machine reports or accesses that hosts database. The next host that tries to contact the site either to report or access its stats gets the timeout. Something like that, except it won't be the database: the problem is 'failure to connect', and the UserID can't be exchanged until there's a connection to communicate over. It seems to be happier today: 30/07/2018 07:51:19 | GPUGRID | [sched_op] Starting scheduler request I'll keep my eyes open as we settle back to normal running, but Apache would be blocking IP addresses, if anything. | |
ID: 50145 | Rating: 0 | rate: / Reply Quote | |
This is the same kind of behavior that I observe. It's almost as if the GPUGrid.net database locks the userid for a short period of time after the first machine reports or accesses that hosts database. The next host that tries to contact the site either to report or access its stats gets the timeout. Thanks for the comms protocol explanation Richard. I have to agree. The site is much more amenable today. I just hit the servers for work round robin on three machines within 20 seconds of each other and they all got work immediately with no problems contacting the server. The fourth machine also connected but the RTS buffer had been run dry by that time. | |
ID: 50161 | Rating: 0 | rate: / Reply Quote | |
OK, I finally got a BOINC log for the failed connections. As usual, I updated two machines on my network in quick succession, and this is the log from the second. 01/08/2018 07:50:54 | GPUGRID | update requested by user It's not clear to me - I'll investigate later - why it tried to get notices from the project on both port 80 (http) and port 443 (https). And having a ps3grid.net still in there can't be helping either. I'm out all day, but I'll have a delve this evening. Again as usual, the automatic retry a couple of minutes later got through without problems: 01/08/2018 07:53:37 | GPUGRID | Requesting new tasks for NVIDIA GPU and Intel GPU | |
ID: 50185 | Rating: 0 | rate: / Reply Quote | |
When I click on too many GPUGrid links in quick succession, I get a Firefox timeout after 20 seconds. It is almost repeatable, but not entirely consistent. | |
ID: 50230 | Rating: 0 | rate: / Reply Quote | |
Looks like the server has gone belly up. Unable to report completed task. Server status hasn't changed much over the last few hours | |
ID: 50366 | Rating: 0 | rate: / Reply Quote | |
All is nominal here. | |
ID: 50367 | Rating: 0 | rate: / Reply Quote | |
Unable to report completed task. I experienced that 2 days ago - but after about 3-4 hours, all was back to normal. | |
ID: 50368 | Rating: 0 | rate: / Reply Quote | |
Message boards : Server and website : Website unreachable