 |
| RGtx 2005-12-13 14:02:07 | I'm not sure if there is a problem developing, but todays results download: 20051213-115958 38 results sent to intheory.ath.cx has not yet appeared in the stats update (nine+ hrs since submission). The ftp server in question has been variously reported as either 'online' or 'host unreachable' throughout the day, mostly online. |
| RGtx 2005-12-14 07:33:39 | Stats updated correctly within the last three hours, so all is again well. |
| RGtx 2006-01-23 06:36:34 | Again, problems appearing with results sent to intheory.ath.cx. Last results sent in 40+ hrs ago but not appearing on stats page: 20060121-185312 39 results sent to intheory.ath.cx Am I alone in experiencing problems with this server? Should I edit out this server from the servers.csv file? |
| AvKyJJ 2006-01-23 08:47:10 | Hi ! I also have the same problem... 20060121-022040 45 results sent to intheory.ath.cx |
| RGtx 2006-01-25 12:30:47 | Results resubmitted: 20060125-201843 39 results sent to llrnet.infosharkz.com ... and accepted ... then points deducted, obviously regarded as duplicates yet not, in the first instance appearing in stats. |
| BOHICASETI 2006-01-25 21:17:14 | As far as stats not updating very fast it's usually server dependant I've found. This is the only Distributed Project that I know of that also uses a Distributed Server system. It's not a picture of fluid motion per se, rather a nice method of making sure there is redundant bandwidth for the masses. It's definitely not perfect, but it does lessen the bandwidth on Stephens server during peak hours and also gives a spot for uploads to happen while his system drops off the net for any reason. But as for the duplicate results, I've been watching this closely and have a couple of threads in the chat area reflecting it. After hours and hours of scrutinizing my manual uploading of results, I've determined that a good deal of the problem is somehow linked to the windows firewall and/or a patch dealing with it. Even if I disable it though I have found another "bug" if you will. It seems that even if I manually send in my results and I watch on my DU Meter (Network Traffic Graphical interface) the results being sent to that server, at the end of the transmission of my results being sent, the FTP server then attempts to upload a test file to me. If that creation of the test file is made it then deletes it and says that it's all happy cause the results have been sent successfully. BUT... if it cannot create that test file then it will consider the entire operation ( including the uploading of the results just seconds earlier ) aborted and will skip to the next server in the servers.scv file to retry the entire operation again. I'm not sure what causes this test file to fail or pass as I've seen the same server deny it one minute and then accept it the next with a different result.txt file. I get the same activity on 3 different computers, each with a different operating system (WinXP Pro, Win XP x64bit, Win2000). But in the end don't get too frustrated about results not showing up too quickly as some servers are a bit slow when it comes to syncronizing with Stephens server. But when it comes to the duplicates, just realize that it is almost %100 positive that the results were sent to 2 different servers for the reason described above. |
| K`Tetch 2006-01-26 18:11:16 |
From what i remember, distributed.net also uses such a system. Well, they use proxyservers, to hold and forward on, as well as email. Course, since they got baught by UD in 2000, and had almost everyone shipped to Austin, Texas, they've been able to really throw money at the project, equipment wise. Just a shame they don't bother throwing any time into their client/projects |
| BOHICASETI 2006-01-26 21:05:09 | Here is an example of a duplication in action. I hit CTRL+C to stop it cause I know that the results were already sent, but you can see that it was going to automatically go to the next FTP server in line to try again.
|
| Stephen Brooks 2006-01-30 04:53:21 | Yep, the weird testfile thing is something I put there to confirm uploads. I figured it was better to upload twice than to have the server drop the session and your results be lost because Muon1 would assume it was OK. |
| RGtx 2006-03-28 09:45:26 | Importing the sendlog file into a spreadsheet and summing the results sent,the total of 6471 is somewhat higher than that appearing on the stats page (6345), subtracting the last two results sent: 20060326-233701 36 results sent to muon.veneration.com.au 20060328-100740 43 results sent to muon1.superstring.org as neither has yet appeared on the stats page, still leaves a disparity of 47, presumed, missing results. Strange thing is my Muon1 client has apparently never returned a single file containing exactly 47 results. |
| RGtx 2006-03-31 00:49:28 | Tail-end of results.dat resubmitted, and the last two results, sent, now accepted correctly. |
| Stephen Brooks 2006-03-31 10:27:20 | Good. There was definitely something a little wrong over the 28/29 period. You'll also notice the samplefiles are refreshing again now. Windows FTP is now completely useless, I've replaced it by ncftpput in nearly all my scripts at work. |
| RGtx 2006-04-02 10:24:46 | Just when you thought it was safe........ Last result sent: 20060331-204056 51 results sent to muon.veneration.com.au still not appearing on stats, guess I shall have to resubmit. |
| Stephen Brooks 2006-04-05 05:25:22 | I can't access muon.veneration.com.au right now, removing it from the list temporarily. |
none)):
