Website unreachable
Message boards :
Server and website :
Website unreachable
Message board moderation
Previous · 1 · 2
| Author | Message |
|---|---|
|
Send message Joined: 28 Jul 12 Posts: 819 Credit: 1,591,285,971 RAC: 0 Level  Scientific publications   
|
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. |
 Retvari Zoltan Send message Joined: 20 Jan 09 Posts: 2380 Credit: 16,897,957,044 RAC: 0 Level  Scientific publications  
|
I receive "Website unreachable" messages lately. At first I thought that the increased traffic caused by the recent problems with the Windows app are behind this. But since the Windows app is working again (almost) normally, I still receive "Website unreachable" messages. I started to investigate by starting an elevated command prompt and pinging www.gpugrid.net continuously (e.g. ping www.gpugrid.net -t). I've made two observations: 1. while the ping runs in the background, I don't receive "Website unreachable" messages. 2. The ping statistics are the following: 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 = 83msI 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. |
|
Send message Joined: 9 Dec 08 Posts: 1006 Credit: 5,068,599 RAC: 0 Level  Scientific publications  |
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. Fixing global routing is definitely outside of our possibilities. :) The fact that changing DNS improves the situation is comforting though. Consider that firefox &c do their own caching of DNS entries. |
|
Retvari Zoltan Send message Joined: 20 Jan 09 Posts: 2380 Credit: 16,897,957,044 RAC: 0 Level Scientific publications
|
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 |
|
Send message Joined: 11 Jul 09 Posts: 1639 Credit: 10,159,968,649 RAC: 0 Level Scientific publications 
|
While I don't discount the possibility of DNS problems - it's worth checking - I think there are other problems to explore. I've just got this from my Chrome browser: 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. |
|
Send message Joined: 2 Jul 16 Posts: 339 Credit: 8,281,341,558 RAC: 792,572 Level  Scientific publications
|
Still location based and its a very old issue. EU is fine but across the pond we get timeouts. |
|
Send message Joined: 28 Jul 12 Posts: 819 Credit: 1,591,285,971 RAC: 0 Level Scientific publications
|
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. |
 Send message Joined: 13 Dec 17 Posts: 1424 Credit: 9,189,946,190 RAC: 8 Level Scientific publications
|
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. |
|
Send message Joined: 11 Jul 09 Posts: 1639 Credit: 10,159,968,649 RAC: 0 Level Scientific publications
|
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. |
|
Send message Joined: 13 Dec 17 Posts: 1424 Credit: 9,189,946,190 RAC: 8 Level Scientific publications
|
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. |
|
Send message Joined: 11 Jul 09 Posts: 1639 Credit: 10,159,968,649 RAC: 0 Level Scientific publications
|
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 |
|
Send message Joined: 28 Jul 12 Posts: 819 Credit: 1,591,285,971 RAC: 0 Level Scientific publications
|
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. |
 Send message Joined: 26 Feb 14 Posts: 211 Credit: 4,496,324,562 RAC: 0 Level  Scientific publications
|
Looks like the server has gone belly up. Unable to report completed task. Server status hasn't changed much over the last few hours  
|
|
Send message Joined: 8 May 18 Posts: 190 Credit: 104,426,808 RAC: 0 Level  Scientific publications
|
All is nominal here. Tullio |
|
Send message Joined: 1 Jan 15 Posts: 1171 Credit: 12,662,148,501 RAC: 1,014,572 Level Scientific publications
|
Unable to report completed task. I experienced that 2 days ago - but after about 3-4 hours, all was back to normal. |
©2026 Universitat Pompeu Fabra